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 19:34:29 -0700 [thread overview]
Message-ID: <CACq0ZD41uSuLibsSCLfgbhT2qrryZuZvE1oUBfLgYnWpr3WBWw@mail.gmail.com> (raw)
In-Reply-To: <CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]
> 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.
It occurs to me that this would allow for a relatively small percentage of
miners to stop the upgrade if the flag date turns out to be poorly chosen
and a large number of non-mining nodes haven't upgraded yet. Would be a
nice safety fallback.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 6:31 PM, Aaron Voisine <voisine@gmail•com> wrote:
> > 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: 5134 bytes --]
next prev parent reply other threads:[~2015-05-14 2:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 16:28 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
2015-05-14 2:34 ` Aaron Voisine [this message]
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=CACq0ZD41uSuLibsSCLfgbhT2qrryZuZvE1oUBfLgYnWpr3WBWw@mail.gmail.com \
--to=voisine@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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