path: root/ee/6fc6dadf864c8262ef3ae6530d4cf1a3b29627

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1169C1119
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 14:35:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
	[209.85.212.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8BB9210B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 14:35:57 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so10544742wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 Sep 2015 07:35:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+0M7vWOVxf6EH0RdLZ1Yse0mvkF+odoV9xfQ9OicJ+8=;
	b=xmTNjRjr/eWpM0sqYX8+nDbergj37zIoStcmdKjTxheXsdp0FYEjm/WbTRxm8FATie
	aytkUrovQXx0Ilw8gMEtfX1owS1Ft6MLSaCmExbM2S6yGZF6LS6Nm/gALZcLXDHDVMtN
	mVBFEJsNI+zdbODGaH4K4jhYETGEdZ3v4puLqzpnA20FM9rxa3N/EaqgGvMp6RTiA2Hj
	SikZuXQzdUx1UqHu3DccamGGlvWpJX8B+yl/uiGAvSM+NxTpe2oFfiakJB5Iewn96Una
	WwdEkUOZwlX001t9ij+KApR6BiHqpjoRNfERAx3Aw2qlde5nPpsXAg/1cswT6dKA2XBq
	gL5Q==
MIME-Version: 1.0
X-Received: by 10.195.18.5 with SMTP id gi5mr54820904wjd.0.1441290956202; Thu,
	03 Sep 2015 07:35:56 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:35:56 -0700 (PDT)
In-Reply-To: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
	<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
Date: Thu, 3 Sep 2015 10:35:56 -0400
Message-ID: <CADm_WcYZ3mDzRrRax5j+RmjhV9xQd3_NuV-hPVOBh2p+HpxbQQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a11c282147667dc051ed8b383
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 specification
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 14:35:59 -0000

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

Thanks - several good suggestions, including some in common.  Will comment
& revise today.

Currently in "collecting" mode, to avoid duplicative comments in multiple
locales.



On Thu, Sep 3, 2015 at 3:57 AM, <jl2012@xbt.hk> wrote:

> Some comments:
>
>
>    - The 75% rule is meaningless here. Since this is a pure relaxation of
>    rules, there is no such thing as "invalid version 4 blocks"
>
>
>    -
>
>    The implication threshold is unclear. Is it 95% or 80%?
>
>    - Softfork requires a very high threshold (95%) to "attack" the
>       original fork. This makes sure that unupgraded client will only see=
 the new
>       fork.
>       - In the case of hardfork, however, the new fork is unable to
>       attack the original fork, and unupgraded client will never see the =
new
>       fork. The initiation of a hardfork should be based on its acceptanc=
e by the
>       economic majority, not miner support. 95% is an overkill and may pr=
obably
>       never accomplished. I strongly prefer a 80% threshold rather than 9=
5%.
>
>
>    - As I've pointed out, using 20-percentile rather than median creates
>    an incentive to 51% attack the uncooperative minority.
>    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01=
0690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the blo=
ck
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size coul=
d
> be very dangerous. Consider that the block size has been stable at 8MB fo=
r
> a few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the w=
ay
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase
> and decrease must be symmetrical: increase the block size when the
> x-percentile is bigger than the current size, decrease the block size whe=
n
> the (100-x)-percentile is smaller than the current size. The overall effe=
ct
> is: the block size remains unchanged unless 80% of miners agree to.
>
>    - Please consider the use of "hardfork bit" to signify the hardfork:
>
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo=
rk_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
>    - Or, alternatively, please combine the hardfork with a softfork. I'm
>    rewriting the specification as follow (changes underlined):
>
>
>    1. Replace static 1M block size hard limit with a floating limit
>    ("hardLimit").
>    2.
>
>    hardLimit floats within the range 1-32M, inclusive.
>
>    3.
>
>    Initial value of hardLimit is 1M, preserving current system.
>
>    4. Changing hardLimit is accomplished by encoding a proposed value
>    within a block's coinbase scriptSig.
>       1. Votes refer to a byte value, encoded within the pattern
>       "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. =
If
>       there is more than one match with with pattern, the first match is =
counted.
>       2. Absent/invalid votes and votes below minimum cap (1M) are
>       counted as 1M votes. Votes above the maximum cap (32M) are counted =
as 32M
>       votes.
>       3. A new hardLimit is calculated at each difficult adjustment
>       period (2016 blocks), and applies to the next 2016 blocks.
>       4. Calculate hardLimit by examining the coinbase scriptSig votes of
>       the previous 12,000 blocks, and taking the 20th percentile and 80th
>       percentile.
>       5. New hardLimit is the median of the followings:
>          1. min(current hardLimit * 1.2, 20-percentile)
>          2. max(current hardLimit / 1.2, 80-percentile)
>          3. current hardLimit
>       5. version 4 block: the coinbase of a version 4 block must match
>    this pattern: "/BV\d+/"
>    6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
>    greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
>    7. 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
>    are version 4 or greater, reject all version <=3D 3 blocks. (testnet4:=
 750 of
>    last 1000)
>    8. Block version number is calculated after masking out high 16 bits
>    (final bit count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=B0=
:
> > BIP 100 initial public draft:
> > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
> >
> > Emphasis on "initial"  This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This
> > Way.
> >
> >
> >
> > Links:
> > ------
> > [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Thanks - several good suggestions, including some in commo=
n.=C2=A0 Will comment &amp; revise today.<div><br></div><div>Currently in &=
quot;collecting&quot; mode, to avoid duplicative comments in multiple local=
es.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Thu, Sep 3, 2015 at 3:57 AM,  <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">jl2012@xbt.hk</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"><u></u>
<div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<pre>Some comments:</pre>
<ul>
<li>The 75% rule is meaningless here. Since this is a pure relaxation of ru=
les, there is no such thing as &quot;invalid version 4 blocks&quot;</li>
</ul>
<ul>
<li>
<pre>The implication threshold is unclear. Is it 95% or 80%?</pre>
</li>
<ul>
<li>Softfork requires a very high threshold (95%) to &quot;attack&quot; the=
 original fork. This makes sure that unupgraded client will only see the ne=
w fork.</li>
<li>In the case of hardfork, however, the new fork is unable to attack the =
original fork, and unupgraded client will never see the new fork. The initi=
ation of a hardfork should be based on its acceptance by the economic major=
ity, not miner support. 95% is an overkill and may probably never accomplis=
hed. I strongly prefer a 80% threshold rather than 95%.</li>
</ul>
</ul>
<ul>
<li>As I&#39;ve pointed out, using 20-percentile rather than median creates=
 an incentive to 51% attack the uncooperative minority. <a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-August/010690.html</a></li>
</ul>
<p style=3D"padding-left:30px"><span style=3D"white-space:pre-wrap">Having =
said that, I don&#39;t have a strong feeling about the use of 20-percentile=
 as threshold to increase the block size. That means the block size is incr=
eased only when most miners agree, which sounds ok to me.</span></p>
<p style=3D"padding-left:30px"><span style=3D"white-space:pre-wrap"></span>=
However, using 20-percentile as threshold to DECREASE the block size could =
be very dangerous. Consider that the block size has been stable at 8MB for =
a few years. Everyone are happy with that. An attacker would just need to a=
cquire 21% of mining power to break the status quo and send us all the way =
to 1MB. The only way to stop such attempt is to 51% attack the attacker. Th=
at&#39;d be really ugly.</p>
<p style=3D"padding-left:30px"><span style=3D"white-space:pre-wrap">For tec=
hnical and ethical reasons, I believe the thresholds for increase and decre=
ase must be symmetrical: increase the block size when the x-percentile is b=
igger than the current size, decrease the block size when the (100-x)-perce=
ntile is smaller than the current size. The overall effect is: the block si=
ze remains unchanged unless 80% of miners agree to.</span></p>
<ul>
<li>Please consider the use of &quot;hardfork bit&quot; to signify the hard=
fork:</li>
</ul>
<p style=3D"padding-left:30px"><span style=3D"white-space:pre-wrap"><a href=
=3D"https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hard=
fork_bit_jl2012_at_xbthk_jul_23_2015/" target=3D"_blank">https://www.reddit=
.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbt=
hk_jul_23_2015/</a></span></p>
<p style=3D"padding-left:30px"><span style=3D"white-space:pre-wrap"><a href=
=3D"https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki" targe=
t=3D"_blank">https://github.com/jl2012/bips/blob/master/hardforkbit.mediawi=
ki</a></span></p>
<ul>
<li>Or, alternatively, please combine the hardfork with a softfork. I&#39;m=
 rewriting the specification as follow (changes underlined):</li>
</ul>
<ol>
<li>Replace static 1M block size hard limit with a floating limit (&quot;ha=
rdLimit&quot;).</li>
<li>
<pre>hardLimit floats within the range 1-32M, inclusive.</pre>
</li>
<li>
<pre>Initial value of hardLimit is 1M, preserving current system.</pre>
</li>
<li><span style=3D"white-space:pre-wrap">Changing hardLimit is accomplished=
 by encoding a proposed value within a block&#39;s coinbase scriptSig.</spa=
n></li>
<ol>
<li><span style=3D"white-space:pre-wrap">Votes refer to a byte value, encod=
ed within the pattern &quot;/BV\d+/&quot; Example: /BV8000000/ votes for 8,=
000,000 byte hardLimit. </span><span style=3D"white-space:pre-wrap;text-dec=
oration:underline">If there is more than one match with with pattern, the f=
irst match is counted.</span></li>
<li><span style=3D"white-space:pre-wrap">Absent/invalid votes and votes bel=
ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3=
2M) are counted as 32M votes.</span></li>
<li><span style=3D"white-space:pre-wrap">A new hardLimit is calculated at e=
ach difficult adjustment period (2016 blocks), and applies to the next 2016=
 blocks.</span></li>
<li><span style=3D"white-space:pre-wrap">Calculate hardLimit by examining t=
he coinbase scriptSig votes of the previous 12,000 blocks, </span><span sty=
le=3D"white-space:pre-wrap;text-decoration:underline">and taking the 20th p=
ercentile and 80th percentile.</span></li>
<li><span style=3D"text-decoration:underline;white-space:pre-wrap">New hard=
Limit is the median of the followings:</span></li>
<ol>
<li><span style=3D"text-decoration:underline;white-space:pre-wrap">m</span>=
<span style=3D"text-decoration:underline;white-space:pre-wrap">in(current h=
ardLimit * 1.2, 20-percentile)</span></li>
<li><span style=3D"text-decoration:underline;white-space:pre-wrap">max(curr=
ent hardLimit / 1.2, 80-percentile)</span></li>
<li><span style=3D"text-decoration:underline;white-space:pre-wrap">current =
hardLimit</span></li>
</ol></ol>
<li><span style=3D"white-space:pre-wrap"></span><span style=3D"white-space:=
pre-wrap;text-decoration:underline">version 4 block: the coinbase of a vers=
ion 4 block must match this pattern: &quot;/BV\d+/&quot;</span></li>
<li><span style=3D"white-space:pre-wrap"></span><span style=3D"white-space:=
pre-wrap;text-decoration:underline">70%</span><span style=3D"white-space:pr=
e-wrap"> rule:</span><span style=3D"white-space:pre-wrap;text-decoration:un=
derline"> If 8,400</span><span style=3D"white-space:pre-wrap"> of the last =
12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (t=
estnet4: 501 of last 1000)</span></li>
<li><span style=3D"white-space:pre-wrap"></span><span style=3D"white-space:=
pre-wrap;text-decoration:underline">80%</span><span style=3D"white-space:pr=
e-wrap"> rule (&quot;Point of no return&quot;): If </span><span style=3D"wh=
ite-space:pre-wrap;text-decoration:underline">9,600</span><span style=3D"wh=
ite-space:pre-wrap"> of the last 12,000 blocks are version 4 or greater, re=
ject all version &lt;=3D 3 blocks. (testnet4: 750 of last 1000)</span></li>
<li><span style=3D"white-space:pre-wrap">Block version number is calculated=
 after masking out high 16 bits (final bit count TBD by versionBits outcome=
).</span></li>
</ol>
<pre>Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=
=B0:
&gt; BIP 100 initial public draft:
&gt; <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0100.medi=
awiki" target=3D"_blank">https://github.com/jgarzik/bip100/blob/master/bip-=
0100.mediawiki</a> [1]
&gt;=20
&gt; Emphasis on &quot;initial&quot;  This is a starting point for the usua=
l open
&gt; source feedback/iteration cycle, not an endpoint that Must Be This
&gt; Way.
&gt;=20
&gt;=20
&gt;=20
&gt; Links:
&gt; ------
&gt; [1] <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0100.=
mediawiki" target=3D"_blank">https://github.com/jgarzik/bip100/blob/master/=
bip-0100.mediawiki</a><span class=3D"">
&gt;=20
&gt; _______________________________________________
&gt; bitcoin-dev mailing list
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/b=
itcoin-dev</a>
</span></pre>
</div>
</blockquote></div><br></div>

--001a11c282147667dc051ed8b383--