path: root/ed/c202c2c1b8800dd12f3cfe7f6947063a77720f

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DDA94F99
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 07:57:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ACAE149
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 07:57:10 +0000 (UTC)
Received: from localhost ([::1]:40246 helo=server47.web-hosting.com)
	by server47.web-hosting.com with esmtpa (Exim 4.85)
	(envelope-from <jl2012@xbt.hk>)
	id 1ZXPOP-00257P-RY; Thu, 03 Sep 2015 03:57:09 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=_f22692d174c8b182acef4bf5ba1b6ed0"
Date: Thu, 03 Sep 2015 03:57:09 -0400
From: jl2012@xbt.hk
To: Jeff Garzik <jgarzik@gmail.com>
In-Reply-To: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
Message-ID: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
	jl2012@xbt.hk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 07:57:12 -0000

--=_f22692d174c8b182acef4bf5ba1b6ed0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

 

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 acceptance by the
economic majority, not miner support. 95% is an overkill and may
probably never accomplished. I strongly prefer a 80% threshold rather
than 95%.

 	* 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/010690.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
block size is increased only when most miners agree, which sounds ok to
me. 

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 acquire 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. 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
when the (100-x)-percentile is smaller than the current size. The
overall effect 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_hardfork_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):

 	* Replace static 1M block size hard limit with a floating limit
("hardLimit").

	* 

hardLimit floats within the range 1-32M, inclusive.

	* 

Initial value of hardLimit is 1M, preserving current system.
 	* Changing hardLimit is accomplished by encoding a proposed value
within a block's coinbase scriptSig.

 	* Votes refer to a byte value, encoded within the pattern "/BVd+/"
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
more than one match with with pattern, the first match is counted.
 	* 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.
 	* A new hardLimit is calculated at each difficult adjustment period
(2016 blocks), and applies to the next 2016 blocks.
 	* Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile and 80th
percentile.
 	* New hardLimit is the median of the followings:

 	* min(current hardLimit * 1.2, 20-percentile)
 	* max(current hardLimit / 1.2, 80-percentile)
 	* current hardLimit

 	* version 4 block: the coinbase of a version 4 block must match this
pattern: "/BVd+/"
 	* 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)
 	* 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750
of last 1000)
 	* Block version number is calculated after masking out high 16 bits
(final bit count TBD by versionBits outcome).

Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> 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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri=
f'>
<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 "invalid version 4 blocks"</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 "attack" the original =
fork. This makes sure that unupgraded client will only see the new fork.</l=
i>
<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've pointed out, using 20-percentile rather than median creates an =
incentive to 51% attack the uncooperative minority. https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2015-August/010690.html</li>
</ul>
<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">Hav=
ing 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 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;"></s=
pan>However, using 20-percentile as threshold to DECREASE the block size co=
uld 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 acquire 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=
=2E That'd be really ugly.</p>
<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">For=
 technical and ethical reasons, I believe the thresholds for increase and d=
ecrease must be symmetrical: increase the block size when the x-percentile =
is bigger than the current size, decrease the block size when the (100-x)-p=
ercentile is smaller than the current size. The overall effect is: the bloc=
k size remains unchanged unless 80% of miners agree to.</span></p>
<ul>
<li>Please consider the use of "hardfork bit" to signify the hardfork:</li>
</ul>
<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">htt=
ps://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bi=
t_jl2012_at_xbthk_jul_23_2015/</span></p>
<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">htt=
ps://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki</span></p>
<ul>
<li>Or, alternatively, please combine the hardfork with a softfork. I'm rew=
riting the specification as follow (changes underlined):</li>
</ul>
<ol>
<li>Replace static 1M block size hard limit with a floating limit ("hardLim=
it").</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 accomplish=
ed by encoding a proposed value within a block's coinbase scriptSig.</span>=
</li>
<ol>
<li><span style=3D"white-space: pre-wrap;">Votes refer to a byte value, enc=
oded within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 =
byte hardLimit. </span><span style=3D"white-space: pre-wrap; text-decoratio=
n: underline;">If there is more than one match with with pattern, the first=
 match is counted.</span></li>
<li><span style=3D"white-space: pre-wrap;">Absent/invalid votes and votes b=
elow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap =
(32M) are counted as 32M votes.</span></li>
<li><span style=3D"white-space: pre-wrap;">A new hardLimit is calculated at=
 each difficult adjustment period (2016 blocks), and applies to the next 20=
16 blocks.</span></li>
<li><span style=3D"white-space: pre-wrap;">Calculate hardLimit by examining=
 the coinbase scriptSig votes of the previous 12,000 blocks, </span><span s=
tyle=3D"white-space: pre-wrap; text-decoration: underline;">and taking the =
20th percentile and 80th percentile.</span></li>
<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">New =
hardLimit is the median of the followings:</span></li>
<ol>
<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">m</s=
pan><span style=3D"text-decoration: underline; white-space: pre-wrap;">in(c=
urrent hardLimit * 1.2, 20-percentile)</span></li>
<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">max(=
current hardLimit / 1.2, 80-percentile)</span></li>
<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">curr=
ent hardLimit</span></li>
</ol></ol>
<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac=
e: pre-wrap; text-decoration: underline;">version 4 block: the coinbase of =
a version 4 block must match this pattern: "/BV\d+/"</span></li>
<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac=
e: pre-wrap; text-decoration: underline;">70%</span><span style=3D"white-sp=
ace: pre-wrap;"> rule:</span><span style=3D"white-space: pre-wrap; text-dec=
oration: underline;"> If 8,400</span><span style=3D"white-space: pre-wrap;"=
> of the last 12,000 blocks are version 4 or greater, reject invalid versio=
n 4 blocks. (testnet4: 501 of last 1000)</span></li>
<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac=
e: pre-wrap; text-decoration: underline;">80%</span><span style=3D"white-sp=
ace: pre-wrap;"> rule ("Point of no return"): If </span><span style=3D"whit=
e-space: pre-wrap; text-decoration: underline;">9,600</span><span style=3D"=
white-space: pre-wrap;"> of the last 12,000 blocks are version 4 or greater=
, reject 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 calculat=
ed after masking out high 16 bits (final bit count TBD by versionBits outco=
me).</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; https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
&gt;=20
&gt; Emphasis on "initial"  This is a starting point for the usual 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] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
&gt;=20
&gt; _______________________________________________
&gt; bitcoin-dev mailing list
&gt; bitcoin-dev@lists.linuxfoundation.org
&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
</pre>
</body></html>

--=_f22692d174c8b182acef4bf5ba1b6ed0--