Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.181 as permitted sender)
	client-ip=209.85.220.181; envelope-from=voisine@gmail.com;
	helo=mail-qk0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
	<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
	<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
	<CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
	<CACq0ZD4_zxhm=qWrP+Nr+fQER4s2R8i7qRjX4HsBWN46uOP2MA@mail.gmail.com>
	<CAPg+sBjxXe0spytGsP1BUzNZhJFDYu_yacdhTy5F+O-X8EG7NQ@mail.gmail.com>
	<CACq0ZD7qF0oEYHfQFxLMn3OOD=ibVAfE-U5YURLrtmWVMzDpgQ@mail.gmail.com>
	<CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@mail.gmail.com>
	<CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
Date: Wed, 13 May 2015 19:34:29 -0700
Message-ID: <CACq0ZD41uSuLibsSCLfgbhT2qrryZuZvE1oUBfLgYnWpr3WBWw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a114780b821833d05160191e2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Precedence: list

--001a114780b821833d05160191e2
Content-Type: text/plain; charset=UTF-8

> 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
>>
>>
>

--001a114780b821833d05160191e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:13px">I concede the poi=
nt. Perhaps a flag date based on previous observation of network upgrade ra=
tes with a conservative additional margin in addition to supermajority of m=
ining power.</span><div><span style=3D"font-size:13px"><br></span></div><di=
v>It occurs to me that this would allow for a relatively small percentage o=
f miners to stop the upgrade if the flag date turns out to be poorly chosen=
 and a large number of non-mining nodes haven&#39;t upgraded yet. Would be =
a nice safety fallback.</div></div><div class=3D"gmail_extra"><br clear=3D"=
all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"=
ltr"><div><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http=
://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></div></div>=
</div></div></div>
<br><div class=3D"gmail_quote">On Wed, May 13, 2015 at 6:31 PM, Aaron Voisi=
ne <span dir=3D"ltr">&lt;<a href=3D"mailto:voisine@gmail.com" target=3D"_bl=
ank">voisine@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><span class=3D"">&gt;=C2=A0<span style=3D"font-size:13=
px">by people and businesses deciding to not use on-chain settlement.</span=
><div><span style=3D"font-size:13px"><br></span></div></span><div>I complet=
ely agree. Increasing fees will cause people voluntary economize on blocksp=
ace by finding alternatives, i.e. not bitcoin. A fee however is a known, up=
front 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=C2=A0the adoption as a store-of-value.=
 The lower the adoption as store-of-value, the lower the price, and the low=
er the value of bitcoin to the world.</div><span class=3D""><div><span styl=
e=3D"font-size:13px"><br></span></div><div><span style=3D"font-size:13px">&=
gt;=C2=A0</span><span style=3D"font-size:13px">That only measures miner ado=
ption, which is the least relevant.</span></div><div><span style=3D"font-si=
ze:13px"><br></span></div></span><div>I concede the point. Perhaps a flag d=
ate based on previous observation of network upgrade rates with a conservat=
ive additional margin in addition to supermajority of mining power.</div></=
div><div class=3D"gmail_extra"><span class=3D""><br clear=3D"all"><div><div=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aaron Voisine</div><div>co=
-founder and CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">br=
eadwallet.com</a></div></div></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Wed, May 13=
, 2015 at 6:19 PM, Pieter Wuille <span dir=3D"ltr">&lt;<a href=3D"mailto:pi=
eter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wed=
, May 13, 2015 at 6:13 PM, Aaron Voisine <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>&gt;</span>=
 wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Conservative is a relati=
ve term. Dropping transactions in a way that is unpredictable to the sender=
 sounds incredibly drastic to me. I&#39;m suggesting increasing the blocksi=
ze, drastic as it is, is the more conservative choice.</div></blockquote><d=
iv><br></div></span><div>Transactions are already being dropped, in a more =
indirect way: by people and businesses deciding to not use on-chain settlem=
ent. That is very sad, but it&#39;s completely inevitable that there is spa=
ce for some use cases and not for others (at whatever block size). It&#39;s=
 only a &quot;things don&#39;t fit anymore&quot; when you see on-chain tran=
sactions 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 do=
es not fundamentally add more use cases - only more growth space for people=
 already invested in being able to do things on-chain while externalizing t=
he costs to others.<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"gmail_extra">I would recommend that the fork take effect whe=
n some specific large supermajority of the pervious 1000 blocks indicate th=
ey have upgraded, as a safer alternative to a simple flag date, but I&#39;m=
 sure I wouldn&#39;t have to point out that option to people here.</div></b=
lockquote><div><br></div></span><div>That only measures miner adoption, whi=
ch is the least relevant. The question is whether people using full nodes w=
ill upgrade. If they do, then miners are forced to upgrade too, or become i=
rrelevant. If they don&#39;t, the upgrade is risky with or without miner ad=
option.<span><font color=3D"#888888"><br><br>-- <br></font></span></div><sp=
an><font color=3D"#888888"><div>Pieter<br><br></div></font></span></div></d=
iv></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--001a114780b821833d05160191e2--