BIP100 updated - By Jeff Garzik and Tom Harding

[HostFat]

BIP100: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
Reddit discussion: https://np.reddit.com/r/btc/comments/5yvc58/tom_harding_weve_worked_with_jgarzik_to_update

Code:

==Abstract==

Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting.

==Motivation==

Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers.  Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide.  Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for the blocks they create.

A simple deterministic system is specified, whereby a 75% mining supermajority may activate a change to the maximum block size each 2016 blocks.  Each change is limited to a 5% increase from the previous block size hard limit, or a decrease of similar magnitude.  Among adopting nodes, there will be no disagreement on the evolution of the maximum block size.

The system is compatible with emergent consensus, but whereas under that system a miner may choose to accept any size block, a miner following BIP100 observes the 75% supermajority rule, and the 5% change limit rule.  Excessive-block values signaled by emergent consensus blocks are considered in the calculation of the BIP100 block size hard limit, and the BIP100 calculated maximum block size is signaled as an excessive-block value for the benefit of all observers.

==Specification==

===Dynamic Maximum Block Size===
# Initial value of <code>hardLimit</code> is 1000000 bytes, preserving current system.
# Changing <code>hardLimit</code> is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.<br /><br />
## Vote encoding
### A vote is represented as a positive megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br />
### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored.
### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below.
### A valid megabyte value is represented by consecutive base-ten digits.
### If no BIP100 pattern is matched, the first matching emergent consensus pattern <code>/EB[0-9]+/</code>, if any, is accepted as the megabyte vote.<br /><br />
## Maximum block size recalculation
### A <code>new hardLimit</code> is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks.
### Absent/invalid votes are counted as votes for the <code>current hardLimit</code>.
### The votes of the previous 2016 blocks are sorted by megabyte vote.
### Raising <code>hardLimit</code><br /><br />
#### The <code>raise value</code> is defined as the vote of the 1512th highest block, converted to bytes.
#### If the resultant <code>raise value</code> is greater than (<code>current hardLimit</code> * 1.05) rounded down to the nearest byte, it is set to that value.
#### If the resultant <code>raise value</code> is greater than <code>current hardLimit</code>, the <code>raise value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
### Lowering <code>hardlimit</code><br /><br />
#### The <code>lower value</code> is defined as the vote of the 1512th lowest block, converted to bytes.
#### If the resultant <code>lower value</code> is less than (<code>current hardLimit</code> / 1.05) rounded down to the nearest byte, it is set to that value.
#### If the resultant <code>lower value</code> is less than <code>current hardLimit</code>, the <code>lower value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
### Otherwise, <code>new hardLimit</code> remains the same as <code>current hardLimit</code>.

===Signature Hashing Operations Limits===
# The per-block signature hashing operations limit is scaled to (<code>hardLimit</code> rounded up to nearest megabyte)/50.
# A maximum serialized transaction size of 1000000 bytes is imposed.

===Publication of <code>hardLimit</code>===
# For the benefit of emergent consensus nodes, <code>hardLimit</code> is published.  Example: a complete coinbase string might read <br /><br /><code>/BIP100/B8/EB2.123456/</code><br /><br /> which indicates a vote for 8M maximum block size, and an enforced <code>hardLimit</code> of 2.123456 megabytes for the block containing the coinbase string.

==Deployment==

This BIP is presumed deployed and activated as of block height 449568 by implementing nodes on the bitcoin mainnet. It has no effect until a raise value different from 1M is observed, which requires at least 1512 of 2016 blocks to vote differently from 1M.

==Backward compatibility==

The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block.

[1714228140]

1714228140

[Quickseller]

What happens if some miners want to lower the limit and some want to raise the limit? I am not sure the formula in the proposal would work.

[HostFat]

This BIP still require the 75% of hashing power, so by following this rule, it is harder to change, in both directions, but it is still possible.
If there isn't 75% of the hashing power voting a direction, the block size will just remain the same. (even the current 1MB limit)

EDIT:
And it can only change by the 5% (upper or lower) of the size of the previous limit, after 2016 blocks with at least 75% of vote.

[AliceWonderMiscreations]

I like this, it avoids radical changes and allows easy reversal if a change ends up going too far.

[HostFat]

New BIP100 code for Bitcoin Core 0.12
https://github.com/bitcoinxt/bitcoin/pull/1

[Carlton Banks]

why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services

[-ck]

For core version 0.12... why? Presumably to predate all segwit code and be compatible with BU? Since it's a hard fork proposal independent of segwit there is nothing that would prevent this from being made for core 0.14. BIP100 was the most popular choice amongst mining pools when it was first proposed. Don't be surprised if it makes a surprising comeback now. If this was coded up for core instead of BU without any other changes it would be very popular very quickly...

[HostFat]

For core version 0.12... why?

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

[kano]

why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services

Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit /sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

[Carlton Banks]

If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts


And you know you're wrong, don't you

[franky1]

why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services

Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit /sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

any dynamic is acceptable to BU, and with for instance. the 5% every 2week max growth. it will take a few years before affecting xt.. so the only one it does affect at activation is core.
(funnily enough a few people have manually taken core and already put in a 2mb+ in their limits to cover any network change and they all run fine on the network)

all core need to do is actually give in and add just the few minimal changes. or be a**hats and orphan&ban the majority if they want to dig their heels in and oppose it.(creating their own altcoin)

i would actually prefer core to have some extra RPC commands or a GUI options tab where users can while LIVE. change settings.
that way users are now slaves to devs digging their heels in by refusing to change something

[kano]

If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts


And you know you're wrong, don't you

LOL you removed the relevant text
To be expected - your trolling fails.

...
If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

[AngryDwarf]

For core version 0.12... why?

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.

[-ck]

For core version 0.12... why?

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.

That doesn't make sense for the former reason; the latter (integration with other codebases forked off earlier) does. There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code. The problem is everyone's rushing to get on top of each other with new proposals and choosing the shortest cuts possible. Oh well stick around long enough and *someone* will probably create a BIP100 for current core...

[AngryDwarf]

There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code.

If segwit does not get activated, then the segwit code should be removed. Sounds like a horrible and potentially dangerous maintenance issue to have unused code lying around.
So then the question is, regarding the non segwit performance improvements in 0.13 and 0.14, is it easier to remove the segwit code, or implement the performance improvements to a pre-segwit version? I suppose only those that are really familiar with the code will know, and it might be a combination of doing both depending on the area of code that needs to be modified.

[bitsolutions]

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

Core 0.12 should not be used for mining, there are known DoS vectors that were patched later on.

Keep in mind this isn't the original BIP100 proposal, this is hacked up version that's IMO significantly more risky.

[Xester]

This idea of BIP100 is actually a good one. By using this kind of strategy we would no longer be choosing Segwit or Bitcoin Unlimited but we can solve the mining problems in the natural way. The problem lies on getting a 75% consensus from the miners, there are greedy people who are complicating things so that they can have control over bitcoin production and mining. If we just follow this path then there will be no problems and there is no need to complicate things.

[bitsolutions]

The problem lies on getting a 75% consensus from the miners

75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.

[kano]

The problem lies on getting a 75% consensus from the miners

75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.

At least get your info correct.

The 75% he is referring to is if BIP100 was ALREADY activated.
The 75% is required, once BIP100 is activated, to adjust the block size up or down via coinbase voting, to be in the 1MB to 32MB range, with only a small adjustment each time.

Segwit has no such option, it's a "side effect" block size increase, if you use certain addresses.
So all SegWit does in reference to the block size, is give a new, non-adjustable, 'possible' larger block size.

[bitsolutions]

The 75% he is referring to is if BIP100 was ALREADY activated.

I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.