BIP 100 specification
20 messages, 3 to 4 Sep 2015. Started by Jeff Garzik.
Jeff Garzik (4), Btc Drak (4), Dave Scotese (2), Johnson Lau (2), Peter Todd (2), Simon Liu (2), Tier Nolan, Jorge Timón, +2 more
BIP 100 initial public draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
Emphasis on "initial" This is a starting point for the usual open source feedback/iteration cycle, not an endpoint that Must Be This Way.
I suggest revising these items for clarity (and I'm guessing on the first one)
Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile.
A new hardLimit may not increase or decrease by more than 1.2x beyond
the prior hardLimit.
to:
The new hardLimit is calculated by sorting the coinbase scriptSig votes
of the last 12,000 blocks from lowest to highest and using the vote of the
2400th block.
If the vote of the 2400th block is a change of less than 20%, use it as
the new hardLimit. Otherwise, change the hardLimit to be closer to that
vote, to either 120% or 80% of the current hardLimit.
I don't understand #5, 75% rule. Shouldn't invalid version 4 blocks always be rejected?
notplato
On Wed, Sep 2, 2015 at 8:33 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (14 lines)
> BIP 100 initial public draft: > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > Emphasis on "initial" This is a starting point for the usual open source > feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
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://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 寫到:
Quoted text (17 lines)
> 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
We should avoid discussing actual hard fork/softfork deployment methodologies when discussing blocksize proposals because deployment is a separate issue. As a recent case in point, look at how BIP65 (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. That lead to a focused discussion of the functionality and relatively quick inclusion.
Deployment really is a separate issue than the mechanics of how BIP100 will function after activation.
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (104 lines)
> 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 "/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. > 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: > "/BV\d+/" > 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (7 lines)
> > 1. > > hardLimit floats within the range 1-32M, inclusive. > > >
Does the 32MB limit actually still exist anywhere in the code? In effect, it is re-instating a legacy limitation.
The message size limit is to minimize the storage required per peer. If a 32MB block size is required, then each network input buffer must be at least 32MB. This makes it harder for a node to support a large number of peers.
There is no reason why a single message is used for each block. Using the merkleblock message (or a different dedicated message), it would be possible to send messages which only contain part of a block and have a limited maximum size.
This would allow receiving parts of a block from multiple sources.
This is a separate issue but should be considered if moving past 32MB block sizes (or maybe as a later protocol change).
Quoted text (8 lines)
> > 1. 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. > > Is there a need for byte resolution? Using MB resolution would use up
much fewer bytes in the coinbase.
Even with the +/- 20% rule, miners could vote for the nearest MB. Once the block size exceeds 5MB, then there is enough resolution anyway.
Quoted text (4 lines)
> 1. 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. > >
I think abstains should count for the status quo. Votes which are out of range should be clamped.
Having said that, if core supports the change, then most miners will probably vote one way or another.
Quoted text (4 lines)
> New hardLimit is the median of the followings: > min(current hardLimit * 1.2, 20-percentile) > max(current hardLimit / 1.2, 80-percentile) > current hardLimit
I think this is unclear, though mathematically exact.
Sort the votes for the last 12,000 blocks from lowest to highest.
Blocks which don't have a vote are considered a vote for the status quo.
Votes are limited to +/- 20% of the current value. Votes that are out of range are considered to vote for the nearest in range value.
The raise value is defined as the vote for the 2400th highest block (20th percentile). The lower value is defined as the vote for the 9600th highest block (80th percentile).
If the raise value is higher than the status quo, then the new limit is set to the raise value. If the lower value is lower than the status quo, then the new limit is set to the lower value. Otherwise, the size limit is unchanged.
A discussion of rolling out BIP 100 will not be avoided :)
It is a hard fork; it would be silly to elide discussion of these key issues.
I don't get the community's recent interest in avoiding certain topics.
On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail•com> wrote:
Quoted text (135 lines)
> We should avoid discussing actual hard fork/softfork deployment > methodologies when discussing blocksize proposals because deployment > is a separate issue. As a recent case in point, look at how BIP65 > (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. > That lead to a focused discussion of the functionality and relatively > quick inclusion. > > Deployment really is a separate issue than the mechanics of how BIP100 > will function after activation. > > On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> 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 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 "/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. > > 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: > > "/BV\d+/" > > 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 > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >
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:
Quoted text (110 lines)
> 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): > > > 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 <= 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 於 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 > >
On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
Quoted text (6 lines)
> A discussion of rolling out BIP 100 will not be avoided :) > > It is a hard fork; it would be silly to elide discussion of these key > issues. > > I don't get the community's recent interest in avoiding certain topics.
It's not a matter of avoiding the subject, it's a whole separate discussion and in the interests of efficient discussion, it is best done separately. There's a whole BIP dedicated to the discussion of consensus forks which you should probably give some input in also, BIP99 [1]
Once we come to an agreement and can say "here's what we're doing about blocksize, it will be X, or we'll raise by this algo", then we can discuss the best way to implement the hard fork.
[1] https://github.com/bitcoin/bips/pull/181
Quoted text (142 lines)
> > > > On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail•com> wrote: >> >> We should avoid discussing actual hard fork/softfork deployment >> methodologies when discussing blocksize proposals because deployment >> is a separate issue. As a recent case in point, look at how BIP65 >> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. >> That lead to a focused discussion of the functionality and relatively >> quick inclusion. >> >> Deployment really is a separate issue than the mechanics of how BIP100 >> will function after activation. >> >> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation•org> 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 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 "/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. >> > 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: >> > "/BV\d+/" >> > 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 >> > >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > >
On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (20 lines)
> > On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik@gmail•com> wrote: > > A discussion of rolling out BIP 100 will not be avoided :) > > > > It is a hard fork; it would be silly to elide discussion of these key > > issues. > > > > I don't get the community's recent interest in avoiding certain topics. > > It's not a matter of avoiding the subject, it's a whole separate > discussion and in the interests of efficient discussion, it is best > done separately. There's a whole BIP dedicated to the discussion of > consensus forks which you should probably give some input in also, > BIP99 [1] > > Once we come to an agreement and can say "here's what we're doing > about blocksize, it will be X, or we'll raise by this algo", then we > can discuss the best way to implement the hard fork. > > [1] https://github.com/bitcoin/bips/pull/181
In fact, that discussion can happen in parallel. But it is more efficient to do so in one place instead of in each of the 5+ hardfork proposals (bip99 itself has a hardfork proposal with its code ready).
1. I think there is no need to have resolution at byte level, while resolution at MB level is not enough. kB would be a better choice.
2. In my specification a v4 block without a vote is invalid, so there is no need to consider absent or invalid votes
3. We should allow miners to explicitly vote for the status quo, so they don't need to change the coinbase vote every time the size is changed. They may indicate it by /BV/ in the coinbase, and we should look for the first "/BVd*/" instead of "/BVd+/"
4. Alternatively, miners may vote in different styles: /BV1234567/, /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
Quoted text (82 lines)
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > >> * >> >> hardLimit floats within the range 1-32M, inclusive. > > Does the 32MB limit actually still exist anywhere in the code? In > effect, it is re-instating a legacy limitation. > > The message size limit is to minimize the storage required per peer. > If a 32MB block size is required, then each network input buffer must > be at least 32MB. This makes it harder for a node to support a large > number of peers. > > There is no reason why a single message is used for each block. Using > the merkleblock message (or a different dedicated message), it would > be possible to send messages which only contain part of a block and > have a limited maximum size. > > This would allow receiving parts of a block from multiple sources. > > This is a separate issue but should be considered if moving past 32MB > block sizes (or maybe as a later protocol change). > >> * 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. > > Is there a need for byte resolution? Using MB resolution would use up > much fewer bytes in the coinbase. > > Even with the +/- 20% rule, miners could vote for the nearest MB. > Once the block size exceeds 5MB, then there is enough resolution > anyway. > >> * 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. > > I think abstains should count for the status quo. Votes which are out > of range should be clamped. > > Having said that, if core supports the change, then most miners will > probably vote one way or another. > >> New hardLimit is the median of the followings: >> min(current hardLimit * 1.2, 20-percentile) >> max(current hardLimit / 1.2, 80-percentile) >> current hardLimit > > I think this is unclear, though mathematically exact. > > Sort the votes for the last 12,000 blocks from lowest to highest. > > Blocks which don't have a vote are considered a vote for the status > quo. > > Votes are limited to +/- 20% of the current value. Votes that are out > of range are considered to vote for the nearest in range value. > > The raise value is defined as the vote for the 2400th highest block > (20th percentile). > > The lower value is defined as the vote for the 9600th highest block > (80th percentile). > > If the raise value is higher than the status quo, then the new limit > is set to the raise value. > > If the lower value is lower than the status quo, then the new limit is > set to the lower value. > > Otherwise, the size limit is unchanged. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Take a look at the latest update:
- swiped Tier Nolan verbiage, which I agree was usefully more clear - added 'M' suffix and removed 'V' from coinbase scriptSig
On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (111 lines)
> 1. I think there is no need to have resolution at byte level, while > resolution at MB level is not enough. kB would be a better choice. > > 2. In my specification a v4 block without a vote is invalid, so there is > no need to consider absent or invalid votes > > 3. We should allow miners to explicitly vote for the status quo, so they > don't need to change the coinbase vote every time the size is changed. They > may indicate it by /BV/ in the coinbase, and we should look for the first > "/BVd*/" instead of "/BVd+/" > > 4. Alternatively, miners may vote in different styles: /BV1234567/, > /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, > the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" > > Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到: > >> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation•org> wrote: >> >> * >>> >>> hardLimit floats within the range 1-32M, inclusive. >>> >> >> Does the 32MB limit actually still exist anywhere in the code? In >> effect, it is re-instating a legacy limitation. >> >> The message size limit is to minimize the storage required per peer. >> If a 32MB block size is required, then each network input buffer must >> be at least 32MB. This makes it harder for a node to support a large >> number of peers. >> >> There is no reason why a single message is used for each block. Using >> the merkleblock message (or a different dedicated message), it would >> be possible to send messages which only contain part of a block and >> have a limited maximum size. >> >> This would allow receiving parts of a block from multiple sources. >> >> This is a separate issue but should be considered if moving past 32MB >> block sizes (or maybe as a later protocol change). >> >> * 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. >>> >> >> Is there a need for byte resolution? Using MB resolution would use up >> much fewer bytes in the coinbase. >> >> Even with the +/- 20% rule, miners could vote for the nearest MB. >> Once the block size exceeds 5MB, then there is enough resolution >> anyway. >> >> * 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. >>> >> >> I think abstains should count for the status quo. Votes which are out >> of range should be clamped. >> >> Having said that, if core supports the change, then most miners will >> probably vote one way or another. >> >> New hardLimit is the median of the followings: >>> min(current hardLimit * 1.2, 20-percentile) >>> max(current hardLimit / 1.2, 80-percentile) >>> current hardLimit >>> >> >> I think this is unclear, though mathematically exact. >> >> Sort the votes for the last 12,000 blocks from lowest to highest. >> >> Blocks which don't have a vote are considered a vote for the status >> quo. >> >> Votes are limited to +/- 20% of the current value. Votes that are out >> of range are considered to vote for the nearest in range value. >> >> The raise value is defined as the vote for the 2400th highest block >> (20th percentile). >> >> The lower value is defined as the vote for the 9600th highest block >> (80th percentile). >> >> If the raise value is higher than the status quo, then the new limit >> is set to the raise value. >> >> If the lower value is lower than the status quo, then the new limit is >> set to the lower value. >> >> Otherwise, the size limit is unchanged. >> >> _______________________________________________ >> 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 >
Just use a 4-byte unsigned integer where the integer is the size in bytes. It's concise and less complex (and less complex to implement). There's no need for human readable strings here.
On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (127 lines)
> Take a look at the latest update: > > - swiped Tier Nolan verbiage, which I agree was usefully more clear > - added 'M' suffix and removed 'V' from coinbase scriptSig > > > On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: >> >> 1. I think there is no need to have resolution at byte level, while >> resolution at MB level is not enough. kB would be a better choice. >> >> 2. In my specification a v4 block without a vote is invalid, so there is >> no need to consider absent or invalid votes >> >> 3. We should allow miners to explicitly vote for the status quo, so they >> don't need to change the coinbase vote every time the size is changed. They >> may indicate it by /BV/ in the coinbase, and we should look for the first >> "/BVd*/" instead of "/BVd+/" >> >> 4. Alternatively, miners may vote in different styles: /BV1234567/, >> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, >> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" >> >> Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到: >>> >>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >>> <bitcoin-dev@lists•linuxfoundation•org> wrote: >>> >>>> * >>>> >>>> hardLimit floats within the range 1-32M, inclusive. >>> >>> >>> Does the 32MB limit actually still exist anywhere in the code? In >>> effect, it is re-instating a legacy limitation. >>> >>> The message size limit is to minimize the storage required per peer. >>> If a 32MB block size is required, then each network input buffer must >>> be at least 32MB. This makes it harder for a node to support a large >>> number of peers. >>> >>> There is no reason why a single message is used for each block. Using >>> the merkleblock message (or a different dedicated message), it would >>> be possible to send messages which only contain part of a block and >>> have a limited maximum size. >>> >>> This would allow receiving parts of a block from multiple sources. >>> >>> This is a separate issue but should be considered if moving past 32MB >>> block sizes (or maybe as a later protocol change). >>> >>>> * 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. >>> >>> >>> Is there a need for byte resolution? Using MB resolution would use up >>> much fewer bytes in the coinbase. >>> >>> Even with the +/- 20% rule, miners could vote for the nearest MB. >>> Once the block size exceeds 5MB, then there is enough resolution >>> anyway. >>> >>>> * 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. >>> >>> >>> I think abstains should count for the status quo. Votes which are out >>> of range should be clamped. >>> >>> Having said that, if core supports the change, then most miners will >>> probably vote one way or another. >>> >>>> New hardLimit is the median of the followings: >>>> min(current hardLimit * 1.2, 20-percentile) >>>> max(current hardLimit / 1.2, 80-percentile) >>>> current hardLimit >>> >>> >>> I think this is unclear, though mathematically exact. >>> >>> Sort the votes for the last 12,000 blocks from lowest to highest. >>> >>> Blocks which don't have a vote are considered a vote for the status >>> quo. >>> >>> Votes are limited to +/- 20% of the current value. Votes that are out >>> of range are considered to vote for the nearest in range value. >>> >>> The raise value is defined as the vote for the 2400th highest block >>> (20th percentile). >>> >>> The lower value is defined as the vote for the 9600th highest block >>> (80th percentile). >>> >>> If the raise value is higher than the status quo, then the new limit >>> is set to the raise value. >>> >>> If the lower value is lower than the status quo, then the new limit is >>> set to the lower value. >>> >>> Otherwise, the size limit is unchanged. >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote:
Quoted text (3 lines)
> Just use a 4-byte unsigned integer where the integer is the size in > bytes. It's concise and less complex (and less complex to implement). > There's no need for human readable strings here.
Solid NACK on making string parsers part of the consensus critical codebase. (WTF‽)
Hi Jeff,
Thoughts on this part of the proposal:
"Absent/invalid votes are counted as votes for the current hardLimit. Out of range votes are counted as the nearest in-range value."
1. Why should an absent vote be considered a vote for the status quo? A non-voter should have zero impact on the result.
2. Why should out of range votes be counted? They're an invalid vote, a spoiled ballot as such, and thus it would be better if they were discarded.
Regards, Simon
On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
Quoted text (14 lines)
> BIP 100 initial public > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > Emphasis on "initial" This is a starting point for the usual open > source feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
I agree with Simon's sentiments for question #1, and was actually going to pose the same question. Non-votes seem like they may poison the well mathematically, and counting them anyway seems to encourage a lack of participation at a time when miners really need to be very much involved. Since we're handing them even more control over the ecosystem with this BIP, it would be nice to ensure they (all miners) seriously consider their impact and role on a regular basis.
I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may be a great reason that I can't think of, but it's eluding me... LOL)
That said, I don't see any issue with counting votes from outside of the range as the maximum/minimum accordingly (Simon's question #2). In fact, such votes would be very interesting (worthy of further discussion) if they begin to lean heavily in either direction.
V/r, Oliver On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (37 lines)
> Hi Jeff, > > Thoughts on this part of the proposal: > > "Absent/invalid votes are counted as votes for the current hardLimit. > Out of range votes are counted as the nearest in-range value." > > 1. Why should an absent vote be considered a vote for the status quo? A > non-voter should have zero impact on the result. > > 2. Why should out of range votes be counted? They're an invalid vote, a > spoiled ballot as such, and thus it would be better if they were discarded. > > Regards, > Simon > > > On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote: > > BIP 100 initial public > > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > > > Emphasis on "initial" This is a starting point for the usual open > > source feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > > > > > > > _______________________________________________ > > 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 >
I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot people round it, so I like the K spec best. I also see value in having human readable data. The spec should nail down these details.
On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrote:
Quoted text (5 lines)
> I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and > 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean > 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot people > round it, so I like the K spec best. I also see value in having human > readable data. The spec should nail down these details.
The IEC standard is to use the prefix MiB for 2^20 bytes:
The 32Mb limit is here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
It's to keep the message size small enough that messages can be serialized in memory.
Jeff if you decide to lift the 32MB limit (you really should, unless your plan is to potentially hard force another Blocksize discussion again which might be okay). I suggest having the 32MB ceiling auto-raise according to a exponential factor (1.5?) starting 1 year from now.
Basically hard limit ceiling 2016-2017: 32 MB Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
The factor could be 2 like BIP-101 but I imagine you will want to be more conservative. The delay time could also be longer if you think it will take longer to fix the message size issue across all implementations.
On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (86 lines)
> > > On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> >> 1. >> >> hardLimit floats within the range 1-32M, inclusive. >> >> >> > Does the 32MB limit actually still exist anywhere in the code? In effect, > it is re-instating a legacy limitation. > > The message size limit is to minimize the storage required per peer. If a > 32MB block size is required, then each network input buffer must be at > least 32MB. This makes it harder for a node to support a large number of > peers. > > There is no reason why a single message is used for each block. Using the > merkleblock message (or a different dedicated message), it would be > possible to send messages which only contain part of a block and have a > limited maximum size. > > This would allow receiving parts of a block from multiple sources. > > This is a separate issue but should be considered if moving past 32MB > block sizes (or maybe as a later protocol change). > > >> >> 1. 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. >> >> Is there a need for byte resolution? Using MB resolution would use up > much fewer bytes in the coinbase. > > Even with the +/- 20% rule, miners could vote for the nearest MB. Once > the block size exceeds 5MB, then there is enough resolution anyway. > > >> 1. 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. >> >> > I think abstains should count for the status quo. Votes which are out of > range should be clamped. > > Having said that, if core supports the change, then most miners will > probably vote one way or another. > > > New hardLimit is the median of the followings: > > min(current hardLimit * 1.2, 20-percentile) > > max(current hardLimit / 1.2, 80-percentile) > > current hardLimit > > I think this is unclear, though mathematically exact. > > Sort the votes for the last 12,000 blocks from lowest to highest. > > Blocks which don't have a vote are considered a vote for the status quo. > > Votes are limited to +/- 20% of the current value. Votes that are out of > range are considered to vote for the nearest in range value. > > The raise value is defined as the vote for the 2400th highest block (20th > percentile). > The lower value is defined as the vote for the 9600th highest block (80th > percentile). > > If the raise value is higher than the status quo, then the new limit is > set to the raise value. > If the lower value is lower than the status quo, then the new limit is set > to the lower value. > Otherwise, the size limit is unchanged. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Maybe grab some code from BIP101 ? It permits block messages > 2MB, while retaining the current limit of 2 MB imposed on other network messages. The 32 MB limit was patched a few months ago.
Links to code:
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
Quoted text (18 lines)
> The 32Mb limit is > here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25 > > It's to keep the message size small enough that messages can be > serialized in memory. > > Jeff if you decide to lift the 32MB limit (you really should, unless > your plan is to potentially hard force another Blocksize discussion > again which might be okay). I suggest having the 32MB ceiling auto-raise > according to a exponential factor (1.5?) starting 1 year from now. > > Basically hard limit ceiling 2016-2017: 32 MB > Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB > > The factor could be 2 like BIP-101 but I imagine you will want to be > more conservative. The delay time could also be longer if you think it > will take longer to fix the message size issue across all implementations. >
If you read between the lines of what was recently changed and why (reducing to 2MB), it seems reasonable to assume BIP101's allowance opens up some of the attack vector again.
On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (33 lines)
> Maybe grab some code from BIP101 ? It permits block messages > 2MB, > while retaining the current limit of 2 MB imposed on other network > messages. The 32 MB limit was patched a few months ago. > > Links to code: > > https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/ > > > > On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote: >> The 32Mb limit is >> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25 >> >> It's to keep the message size small enough that messages can be >> serialized in memory. >> >> Jeff if you decide to lift the 32MB limit (you really should, unless >> your plan is to potentially hard force another Blocksize discussion >> again which might be okay). I suggest having the 32MB ceiling auto-raise >> according to a exponential factor (1.5?) starting 1 year from now. >> >> Basically hard limit ceiling 2016-2017: 32 MB >> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB >> >> The factor could be 2 like BIP-101 but I imagine you will want to be >> more conservative. The delay time could also be longer if you think it >> will take longer to fix the message size issue across all implementations. >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev