BIP 102: update to match implementation #262

jgarzik commented at 4:26 AM on December 18, 2015: contributor

Contains latest ISM changes.

BIP 102: update to match implementation 097983d256

in bip-0102.mediawiki:None in 097983d256 outdated

  23 |  
  24 | -# Maximum block size permitted to be valid is 1MB.
  25 | -# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support.
  26 | +# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
  27 |  # Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
  28 | +# Each 10-minute segment thereafter increases MAX_BLOCK_SIZE by 20 bytes.

MarcoFalke commented at 8:02 AM on December 18, 2015:

People referring to BIP 102 have "bump to 2 MB once" in mind. I guess this needs a new BIP number?

btcdrak commented at 9:16 AM on December 18, 2015: contributor

Strong NAK. This is a fundamental change to a long standing BIP proposal. BIP102 is titled "Block size increase to 2MB", and this PR changes it to a never ending blocksize increase. Allowing such a radical change would be confusing to people who has already backed BIP102. There should be a separate BIP proposal.

The change to the deployment methodology alone is fine.

luke-jr commented at 11:22 AM on December 18, 2015: member

This is still Draft, so technically @jgarzik should be able to make any changes he wants, but I agree with the general sentiment here and strongly encourage not changing the BIP in such a very significant manner considering real-world use of the "BIP 102" concept in discussion.

luke-jr added the label Proposed BIP modification on Dec 18, 2015

btcdrak commented at 11:42 AM on December 18, 2015: contributor

The difficulty is that "BIP102" has been is already widely understood as a flat 2MB increase and has had a concrete PR open for several months. This change is a bit like tacking on defence spending onto a well oiled healthcare bill.

jameshilliard commented at 11:54 AM on December 18, 2015: contributor

NACK major changes like this should use a different BIP number, this will cause major confusion in regards to statements people have made in support of a particular proposal or against a proposal. For example the BIP100 tagging by miners was in support of the original draft proposal but NOT the subsequent changes made afterwards which made significant modifications to the cap decrease threshold in addition to the removal of the 32MB ceiling. I think non-trivial changes to draft BIP's should not be allowed without creating a new BIP number even if the proposal has not been officially submitted to this repo in order to ensure that people's statements in support of a particular proposal are not ambiguous.

BIP 102: remove dynamic adjustment 32112987af

jgarzik commented at 1:09 PM on December 18, 2015: contributor

Updated back to fixed one-time bump.

BIP 102: 95% update req 5cdae758f3

in bip-0102.mediawiki:None in 32112987af outdated

  23 |  
  24 | -# Maximum block size permitted to be valid is 1MB.
  25 | -# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support.
  26 | +# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
  27 |  # Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
  28 | +# Trigger:  (1) Block time 00:00:00 on flag day, AND (2) 75% of the last 1,000 blocks have signaled support.

jameshilliard commented at 1:17 PM on December 18, 2015:

Shouldn't this be 95%?

btcdrak commented at 1:39 PM on December 18, 2015:

Agreed, 95%

jgarzik commented at 1:40 PM on December 18, 2015:

Updated

jgarzik commented at 1:44 PM on December 18, 2015: contributor

Update to 95%

luke-jr commented at 6:12 PM on January 8, 2016: member

@jgarzik I assume you will merge this yourself when ready?

luke-jr assigned jgarzik on Jan 8, 2016

luke-jr commented at 10:22 PM on January 18, 2016: member

Does anyone (especially @jgarzik ) object to BIP 102 turning into "Bitcoin Classic"'s hardfork proposal? In particular, they seem to want miner voting and add some new limits (to prevent DoS attacks; generally agreed to be necessary for size increases). I need to evaluate whether a new BIP would be redundant with BIP 102, or whether it would be best as a modification to it. @jgarzik In addition to the above, would you be okay with considering an additional Champion/Author working on Classic (if applicable - I don't know how involved you are with their project)?

jgarzik referenced this in commit db1f646035 on Jan 19, 2016

jgarzik merged this on Jan 19, 2016

jgarzik closed this on Jan 19, 2016

jgarzik commented at 7:25 AM on January 19, 2016: contributor

BIP 102 is not suddenly morphed into a tracking BIP for whatever Bitcoin Classic does. That just creates additional confusion and a moving target.

We can assign a new BIP number to whatever Bitcoin Classic does.

luke-jr referenced this in commit 2aa9f971af on Jan 20, 2018