MIME-Version: 1.0
In-Reply-To: <CABm2gDoyzLErwA0g624A2aPUqSi3gXTgcmC7TTTUNDKyecDpuA@mail.gmail.com>
References: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>
	<CABm2gDqJgPM1KRRSR3wSEhQ77Oq6P_VVvHwc3Yt4qnkAr7d2nA@mail.gmail.com>
	<CADm_WcYFmvu+_OXjm53DHV_q2m8z7Q9zd7QaTrs-uqfiK62CAQ@mail.gmail.com>
	<CABm2gDoyzLErwA0g624A2aPUqSi3gXTgcmC7TTTUNDKyecDpuA@mail.gmail.com>
Date: Fri, 18 Dec 2015 15:15:54 -0500
Message-ID: <CADm_Wcah3V7yxCpt97rK89_0GY8HZm6xbCg0yqjKRWak7crt5Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113abfae814966052731ce89
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The increase of max block size should be
 determined by block height instead of block time
Precedence: list

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

My preference is height activation + one step per block (i.e. also
height).  Height seems KISS.

AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.

However I would like to hear from others about possible attacks with the
various approaches, before diverging from the default community approach of
switch-based-on-time.






On Fri, Dec 18, 2015 at 3:10 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

> Well, if it's not going to be height, I think median time of the previous
> block is better than the time of the current one, and would also solve Ch=
un
> Wang's concerns.
> But as said I prefer to use heights that correspond to diff recalculation
> (because that's the window that bip9 will use for the later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:
>
>> From a code standpoint, based off height is easy.
>>
>> My first internal version triggered on block 406,800 (~May 5), and each
>> block increased by 20 bytes thereafter.
>>
>> It was changed to time, because time was the standard used in years past
>> for other changes; MTP flag day is more stable than block height.
>>
>> It is preferred to have a single flag trigger (height or time), rather
>> than the more complex trigger-on-time, increment-on-height, but any
>> combination of those will work.
>>
>> Easy to change code back to height-based...
>>
>>
>>
>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Tim=C3=B3n <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I agree that nHeight is the simplest option and is my preference.
>>> Another option is to use the median time from the previous block (thus
>>> you know whether or not the next block should start the miner confirmat=
ion
>>> or not). In fact, if we're going to use bip9  for 95% miner upgrade
>>> confirmation, it would be nice to always pick a difficulty retarget blo=
ck
>>> (ie block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).
>>> Actually I would always have an initial height in bip9, for softforks
>>> too.
>>> I would also use the sign bit as the "hardfork bit" that gets activated
>>> for the next diff interval after 95% is reached and a hardfork becomes
>>> active (that way even SPV nodes will notice when a softfork  or hardfor=
k
>>> happens and also be able to tell which one is it).
>>> I should update bip99 with all this. And if the 2 mb bump is
>>> uncontroversial, maybe I can add that to the timewarp fix and th recove=
ry
>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem t=
o
>>> follow bip99's recommendations and doesn't want to give 6 full months a=
s
>>> the pre activation grace period).
>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>>> time that determine the max block size. From from pool's point of
>>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>>> For developers, it is also easier to implement if max block size is a
>>>> function of block height instead of time. Block height is also much
>>>> more simple and elegant than time.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>

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

<div dir=3D"ltr">My preference is height activation + one step per block (i=
.e. also height).=C2=A0 Height seems KISS.<div><br></div><div>AFAICT most o=
f the attacks would occur around the already-heavily-watched flag day activ=
ation event, in a height based environment, a useful attribute.</div><div><=
br></div><div><div>However I would like to hear from others about possible =
attacks with the various approaches, before diverging from the default comm=
unity approach of switch-based-on-time.</div></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Fri, Dec 18, 2015 at 3:10 PM, Jo=
rge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtimon.cc" ta=
rget=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><p dir=3D"ltr">Well, if it&#39;s not going to be height, I th=
ink median time of the previous block is better than the time of the curren=
t one, and would also solve Chun Wang&#39;s concerns.<br>
But as said I prefer to use heights that correspond to diff recalculation (=
because that&#39;s the window that bip9 will use for the later 95% confirma=
tion anyway).</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On Dec 18, 2015 9:02 PM, &quot;Jeff Garzik&quot;=
 &lt;<a href=3D"mailto:jgarzik@gmail.com" target=3D"_blank">jgarzik@gmail.c=
om</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">From a code standpoint, based off height is easy.<div><br></=
div><div>My first internal version triggered on block 406,800 (~May 5), and=
 each block increased by 20 bytes thereafter.</div><div><br></div><div>It w=
as changed to time, because time was the standard used in years past for ot=
her changes; MTP flag day is more stable than block height.</div><div><br><=
/div><div>It is preferred to have a single flag trigger (height or time), r=
ather than the more complex trigger-on-time, increment-on-height, but any c=
ombination of those will work.</div><div><br></div><div>Easy to change code=
 back to height-based...</div><div><br></div><div><br></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 18, 2015 at 2:=
52 PM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">I agree that nHeight is the simplest option and is my preference.<=
br>
Another option is to use the median time from the previous block (thus you =
know whether or not the next block should start the miner confirmation or n=
ot). In fact, if we&#39;re going to use bip9=C2=A0 for 95% miner upgrade co=
nfirmation, it would be nice to always pick a difficulty retarget block (ie=
 block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).<br>
Actually I would always have an initial height in bip9, for softforks too.<=
br>
I would also use the sign bit as the &quot;hardfork bit&quot; that gets act=
ivated for the next diff interval after 95% is reached and a hardfork becom=
es active (that way even SPV nodes will notice when a softfork=C2=A0 or har=
dfork happens and also be able to tell which one is it).<br>
I should update bip99 with all this. And if the 2 mb bump is uncontroversia=
l, maybe I can add that to the timewarp fix and th recovery of the other 2 =
bits in block.nVersion (given that bip102 doesn&#39;t seem to follow bip99&=
#39;s recommendations and doesn&#39;t want to give 6 full months as the pre=
 activation grace period).</p><div><div>
<div class=3D"gmail_quote">On Dec 18, 2015 8:17 PM, &quot;Chun Wang via bit=
coin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In many BIPs we have se=
en, include the latest BIP202, it is the block<br>
time that determine the max block size. From from pool&#39;s point of<br>
view, it cannot issue a job with a fixed ntime due to the existence of<br>
ntime roll. It is hard to issue a job with the max block size unknown.<br>
For developers, it is also easier to implement if max block size is a<br>
function of block height instead of time. Block height is also much<br>
more simple and elegant than time.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>

--001a113abfae814966052731ce89--