From: Aaron Voisine <voisine@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Wed, 13 May 2015 18:31:56 -0700 [thread overview]
Message-ID: <CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]
> by people and businesses deciding to not use on-chain settlement.
I completely agree. Increasing fees will cause people voluntary economize
on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a
known, upfront cost... unpredictable transaction failure in most cases will
be a far higher, unacceptable cost to the user than the actual fee. The
higher the costs of using the system, the lower the adoption as a
store-of-value. The lower the adoption as store-of-value, the lower the
price, and the lower the value of bitcoin to the world.
> That only measures miner adoption, which is the least relevant.
I concede the point. Perhaps a flag date based on previous observation of
network upgrade rates with a conservative additional margin in addition to
supermajority of mining power.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine@gmail.com> wrote:
>
>> Conservative is a relative term. Dropping transactions in a way that is
>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
>> increasing the blocksize, drastic as it is, is the more conservative choice.
>>
>
> Transactions are already being dropped, in a more indirect way: by people
> and businesses deciding to not use on-chain settlement. That is very sad,
> but it's completely inevitable that there is space for some use cases and
> not for others (at whatever block size). It's only a "things don't fit
> anymore" when you see on-chain transactions as the only means for doing
> payments, and that is already not the case. Increasing the block size
> allows for more utility on-chain, but it does not fundamentally add more
> use cases - only more growth space for people already invested in being
> able to do things on-chain while externalizing the costs to others.
>
>
>> I would recommend that the fork take effect when some specific large
>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
>> safer alternative to a simple flag date, but I'm sure I wouldn't have to
>> point out that option to people here.
>>
>
> That only measures miner adoption, which is the least relevant. The
> question is whether people using full nodes will upgrade. If they do, then
> miners are forced to upgrade too, or become irrelevant. If they don't, the
> upgrade is risky with or without miner adoption.
>
> --
> Pieter
>
>
[-- Attachment #2: Type: text/html, Size: 3972 bytes --]
next prev parent reply other threads:[~2015-05-14 1:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 16:28 [Bitcoin-development] Long-term mining incentives Thomas Voegtlin
2015-05-11 16:52 ` insecurity
2015-05-11 17:29 ` Gavin Andresen
2015-05-12 12:35 ` Thomas Voegtlin
[not found] ` <CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
[not found] ` <555210AF.3090705@electrum.org>
2015-05-12 16:10 ` Gavin Andresen
2015-05-12 16:21 ` Dave Hudson
2015-05-12 21:24 ` Pedro Worcel
2015-05-12 23:48 ` Adam Back
2015-05-13 15:41 ` Gavin Andresen
2015-05-13 20:05 ` Pedro Worcel
2015-05-13 9:49 ` Thomas Voegtlin
2015-05-13 10:14 ` Tier Nolan
2015-05-13 10:31 ` Alex Mizrahi
2015-05-13 11:29 ` Tier Nolan
2015-05-13 12:26 ` Alex Mizrahi
2015-05-13 13:24 ` Gavin
2015-05-13 13:28 ` Tier Nolan
2015-05-13 14:26 ` Alex Mizrahi
2015-05-13 23:46 ` Jorge Timón
2015-05-14 0:11 ` Jorge Timón
2015-05-14 0:48 ` Aaron Voisine
2015-05-14 0:58 ` Pieter Wuille
2015-05-14 1:13 ` Aaron Voisine
2015-05-14 1:19 ` Pieter Wuille
2015-05-14 1:31 ` Aaron Voisine [this message]
2015-05-14 2:34 ` Aaron Voisine
2015-05-16 20:35 ` Owen Gunden
2015-05-16 22:18 ` Tom Harding
2015-05-17 1:08 ` Aaron Voisine
2015-05-14 0:44 ` Melvin Carvalho
2015-05-25 18:31 ` Mike Hearn
2015-05-26 18:47 ` Thomas Voegtlin
2015-05-27 21:59 ` Mike Hearn
2015-05-27 22:22 ` Gregory Maxwell
2015-05-28 10:30 ` Mike Hearn
2015-05-13 17:49 Damian Gomez
2015-05-18 2:29 Michael Jensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com' \
--to=voisine@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=pieter.wuille@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox