Author: Btc Drak 2015-09-03 11:20:08
Published on: 2015-09-03T11:20:08+00:00
The deployment method is a separate issue from blocksize proposals such as BIP100, and should be avoided when discussing these proposals. The recent case of BIP65 (CHECKLOCKTIMEVERIFY) demonstrated how avoiding the issue of deployment led to focused discussion and relatively quick inclusion. Deployment is not related to the mechanics of how BIP100 will function after activation. A bitcoin-dev member commented on the 75% rule, stating that since the rule is a pure relaxation of rules, there is no such thing as "invalid version 4 blocks." The implication threshold for BIP100 was also unclear, with the member advocating for an 80% threshold rather than the current 95%, which is considered to be an overkill. Using 20-percentile as a threshold for increasing the block size sounds reasonable, but using it to decrease the block size could be dangerous as it creates an incentive to 51% attack the uncooperative minority. The member suggests that the thresholds for increase and decrease must be symmetrical and that a hardfork bit can be used to signify the hardfork. Alternatively, the hardfork can be combined with a softfork. The member also provides a rewritten specification that replaces the static 1M block size hard limit with a floating limit ("hardLimit"). The new hardLimit is calculated by examining the coinbase scriptSig votes of the previous 12,000 blocks, taking the 20th percentile and 80th percentile, and calculating the median of the min(current hardLimit * 1.2, 20-percentile), max(current hardLimit / 1.2, 80-percentile), and current hardLimit. Finally, the member provides a link to the initial public draft of BIP100 by Jeff Garzik.
Updated on: 2023-06-10T21:56:15.112930+00:00