<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='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 rules, 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.</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 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%.</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.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html</li>
</ul>
<p style="padding-left: 30px;"><span style="white-space: pre-wrap;">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.</span></p>
<p style="padding-left: 30px;"><span style="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 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.</p>
<p style="padding-left: 30px;"><span style="white-space: pre-wrap;">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.</span></p>
<ul>
<li>Please consider the use of "hardfork bit" to signify the hardfork:</li>
</ul>
<p style="padding-left: 30px;"><span style="white-space: pre-wrap;">https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/</span></p>
<p style="padding-left: 30px;"><span style="white-space: pre-wrap;">https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki</span></p>
<ul>
<li>Or, alternatively, please combine the hardfork with a softfork. I'm rewriting the specification as follow (changes underlined):</li>
</ul>
<ol>
<li>Replace static 1M block size hard limit with a floating limit ("hardLimit").</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="white-space: pre-wrap;">Changing hardLimit is accomplished by encoding a proposed value within a block's coinbase scriptSig.</span></li>
<ol>
<li><span style="white-space: pre-wrap;">Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. </span><span style="white-space: pre-wrap; text-decoration: underline;">If there is more than one match with with pattern, the first match is counted.</span></li>
<li><span style="white-space: pre-wrap;">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.</span></li>
<li><span style="white-space: pre-wrap;">A new hardLimit is calculated at each difficult adjustment period (2016 blocks), and applies to the next 2016 blocks.</span></li>
<li><span style="white-space: pre-wrap;">Calculate hardLimit by examining the coinbase scriptSig votes of the previous 12,000 blocks, </span><span style="white-space: pre-wrap; text-decoration: underline;">and taking the 20th percentile and 80th percentile.</span></li>
<li><span style="text-decoration: underline; white-space: pre-wrap;">New hardLimit is the median of the followings:</span></li>
<ol>
<li><span style="text-decoration: underline; white-space: pre-wrap;">m</span><span style="text-decoration: underline; white-space: pre-wrap;">in(current hardLimit * 1.2, 20-percentile)</span></li>
<li><span style="text-decoration: underline; white-space: pre-wrap;">max(current hardLimit / 1.2, 80-percentile)</span></li>
<li><span style="text-decoration: underline; white-space: pre-wrap;">current hardLimit</span></li>
</ol></ol>
<li><span style="white-space: pre-wrap;"></span><span style="white-space: 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="white-space: pre-wrap;"></span><span style="white-space: pre-wrap; text-decoration: underline;">70%</span><span style="white-space: pre-wrap;"> rule:</span><span style="white-space: pre-wrap; text-decoration: underline;"> If 8,400</span><span style="white-space: pre-wrap;"> of the last 12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)</span></li>
<li><span style="white-space: pre-wrap;"></span><span style="white-space: pre-wrap; text-decoration: underline;">80%</span><span style="white-space: pre-wrap;"> rule ("Point of no return"): If </span><span style="white-space: pre-wrap; text-decoration: underline;">9,600</span><span style="white-space: pre-wrap;"> of the last 12,000 blocks are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last 1000)</span></li>
<li><span style="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 於 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
</pre>
</body></html>