BUIP055: (passed) Increase the Block Size Limit at a Fixed Block Height

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
BUIP055: Increase the Block Size Limit at a Fixed Block Height

Proposer: Peter Rizun
Submitted: 2017-05-10


Abstract

This BUIP proposes to add functionality to automatically increase a node's block size limit at a specified block height. The default settings correspond to an 2 MB limit at block #494,784.

Motivation

Due to the 1 MB block size limit enforced by many mining and non-mining nodes, miners can no longer respond to increasing demand for Bitcoin transactions by increasing the supply of block space. This has resulted in a sharp increase in transaction fees and has made transaction confirmation times unreliable.

To alleviate this condition, node operators and miners must increase the maximum size of blocks their nodes accept. The deployment of BUIP001 gave both groups the ability to increase their nodes' block size limits without restarting the client or recompiling executables from source code.

With the benefit of hindsight, it has become clear that BUIP001 was a success with operators of non-mining nodes: the median block size limit enforced by non-mining nodes running Bitcoin Unlimited is now 16 MB.

However, BUIP001 has been less successful with miners: the median block size limit enforced by miners running Bitcoin Unlimited is still 1 MB, despite the fact that a majority of the network hash power wants to mine larger blocks. Empirical evidence suggests that miners are typically unwilling to act independently, instead favoring to increase their nodes' block size limits in unison with the other miners.

What is needed then is a simple coordination scheme to permit miners to increase their nodes’ block size limits in lock step. The specification described in this proposal is one such coordination scheme.

Specification

Block size limit

If a node operator elects to use BUIP055, three variables must be defined: current_limit, new_limit and activation_height, where

current_limit [default=[FONT=Courier New]1000000[/FONT]] is the block size limit presently enforced, measured in bytes,​

new_limit [default=[FONT=Courier New]2000000[/FONT]] is the new block size limit, measured in bytes, and​

activation_height [default=[FONT=Courier New]494784[/FONT]] is the block number when the new limit applies,​

with the requirement [1] that

new_limit >= current_limit > 0.​

The maximum block size (max_block_size) for a given block is then calculated using the following logic:

if(BUIP055)
{

max_block_size =
(block_height < activation_height) ? current_limit : new_limit;
}
else
{

...other logic
}

Signature operations and transaction size

The maximum signature operations for a given block and the maximum transaction size are consistent with BUIP040 and BIP100:

max_block_sigops = 20000*((this_block_size-1)/1000000 + 1)

max_tx_size = 1000000

where this_block_size is the size of the block being checked (and of course this_block_size <= max_block_size).

Coinbase and user-agent signalling

Building on the format specified in BUIP005, the relevant variables are signalled in the coinbase transaction as

"/EB<current_limit_MB>/EB<new_limit_MB>@<activation_height>/..."

and in the user-agent string as

"<user-agent>(EB<current_limit_MB>;EB<new_limit_MB>@<activation_height>...)/"

For example, using the default settings (and assuming AD is not signalled), the following strings would be included in the coinbase transaction and the user-agent string, respectively:

"/EB1/EB2@494784/"

"BitcoinUnlimited:1.1.0(EB1;EB2@494784)

Note that the current and new block size limits are signalled in units of megabytes. Refer to BUIP005 for further information.

Re-org protection

Re-org protection shall be implemented to prevent the big-block chain from re-organizing back to the small block chain, should the small-block chain temporarily become longer. This will be accomplished by adding a temporary protocol rule for nodes that elect to use BUIP055, which requires the size of the block at the activation_height to have a size greater than the current_limit:

min_block_size = (block_height==activation_height) ? current_limit+1 : 0;

Once the network upgrade is complete and the small-block chain is extinguished (or no longer a threat of catching up), this temporary rule can be removed.

It is important to note that the block production code must also be extended to ensure that a block greater than the current limit is actually produced by mining nodes at the activation height.

Rationale for Re-org Protection

The probability (P) that the big-block chain re-orgs back to the small-block chain is given by

P = (q/p)^2

where p is the fraction of the hash power mining the big-block chain and q is the fraction of the hash power remaining on the small block chain [2]. With 75% of the hash power supporting larger blocks, the probability of a re-org is 11%. An unlucky re-org would result in the loss of all block rewards mined on the big-block chain, and a possible loss of momentum for the network upgrade. Communication with miners indicates that they want protection to mitigate this risk, given the current level of contention in the Bitcoin community.


Deployment


Miners can begin signalling for an increase to 2 MB at block #494,784 immediately, or modify the defaults to propose a different limit or activation height. If a sufficient fraction of the network hash power supports a given proposal, no further action is required: the network's block size limit will be automatically increased at the agreed-upon block height. If sufficient support is not obtained, then miners could modify their proposals (e.g., by pushing the activation date further into the future or by proposing a different block size limit) and try again.

Backwards compatibility

If a block larger than 1,000,000 bytes is mined into the most-work chain, nodes that continue to enforce the legacy block size limit will not recognize it as valid and ignore it. If the minority chain has non-negligible hashing power, the blockchain will bifurcate at that point.

[1] Reindexing the chain could fail if the block size limit were repeatedly decreased without keeping track of prior block size limits.

[2] https://medium.com/@tl121/an-analytic-model-of-the-performance-of-a-forked-bitcoin-blockchain-with-two-block-size-limits-5642ab0325dc
 
Last edited:

SanchoPanza

Member
Mar 29, 2017
47
65
Any chance that you would submit this also as a BIP?

Also, I am wondering if the problem in hashpower is truly one of needing more sophisticated on-chain coordination. I think they want an upgrade to be swift, decisive and as troublefree as possible.

Have you considered coordination via BIP135 with an activation threshold like 80%, potentially with tailored tallying window and grace period (grace could be made longer than 1 month?)

This is of course a separate idea from this BUIP, but I wonder if you considered that?

P.S. I think there is also nothing that prevents a deployment from being offered on multiple versionbits with different activation thresholds.
 
Last edited:
  • Like
Reactions: bluemoon

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
I'd be happy to submit it as a BIP. The trouble is that many of my emails to the bitcoin-dev list are moderated (i.e., they are not relayed) so it is difficult to defend my position. Furthermore, I highly doubt this would be assigned a BIP number even if I was allowed to freely discuss it over there.
 

bitsko

Active Member
Aug 31, 2015
730
1,532
Perhaps someone could ask luke-jr about this?

iirc he is involved in the BIP process?
 
  • Like
Reactions: bluemoon

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
This BUIP proposes to add functionality to automatically increase a node's block size limit at a specified block height. The default settings correspond to an 8 MB limit at block #488,888 (~18 October 2017).
satoshi said:
if (blocknumber > 115000) maxblocksize = largerlimit
o_O;):)

I love this and support it - @Peter R please submit it as a BIP it is important to see how the incumbent governing model functions in relation to BU's federated governing model.

If bitcoin is governed by incentives and not an authority Core should include this as they insist no one is obliged to adopt it. It would be irresponsible to insist on enforcing the limit through centralized control.

P.s. I happened to make a 1BTC bet it wouldn't happen in 2017 it's a bet I am happy to lose.
 
Last edited:

torusJKL

Active Member
Nov 30, 2016
497
1,156
I have heard users saying that if they knew how much the block size increase would be they could get behind it.
Although this BUIP addresses this only partially because the power to increase the size is still with the miners, it gives the miners a way to communicate their intentions better.

I wonder if 8MB is a good default value.
We need to break out of the current mindset and proof that a hard fork is doable and safe.
Thus the question if a default value of e.g. 4MB would be more likely to get broad support of miners and pool operators.

P.S. why block #488,888? is it because it has almost only the number 8 in it, or is there more behind it?
 

jbreher

Active Member
Dec 31, 2015
166
526
Will the mod of operation (i.e. The BUIP055 variable in your pseudocode) be a user settable parameter accessible in the GUI? Would the 'other logic' be today's BU EC algorithm?
 
  • Like
Reactions: Norway and AdrianX

Roy Badami

Active Member
Dec 27, 2015
140
203
ACK.

I'm agnostic as to defaults; miners and economically significant full nodes can and will make their own decisions as to whether to enable or disable this.
 

Emil Oldenburg

New Member
Nov 28, 2016
4
23
Blockheight 488,888 would about half into the difficulty adjustment period, which would affect the potential difficulty decrease if not all miners follow. However, the current state of the mining market would give huge financial penalties to any mining pool/hasher not following the majority, so that risk is probably low.
 
  • Like
Reactions: freetrader

Jihan

New Member
Mar 3, 2016
10
93
Recently there is rumor that Bitmain will support this BUIP. And Peter has pinged me in Slack. So I decided to give some comments on this BUIP.

First of all, hard fork is not purely technical but also political. The censorship, troll army like Dragonsden and privately paid news reporters are direct evidence that the hard fork is political. And the obsession with letting RPi be able to run full node is also another kind of politic. Any decision about a hard fork will need to consider both. Here I will not comment on the political side of this proposal but just the technical side.

This is a hard fork, which is a kind of changing in the consensus rules. Bitcoin protocol consensus rule changing has evolved a lot and has its best practice by now. In the early days, Satoshi N. was God. He could introduce consensus rule change arbitrarily. 1MB block size limited was introduced by adding the code without anyone else knowing about it, and today we are still in this trouble. Later, the community used coinbase voting. Gavin's and Luke's two different scheme of multi-sig were voted by coinbase. The most recently process of changing consensus is BIP9. It is the most reliable way to introduce a consensus rule change. So we would better to use such kind of process rather than going back to coinbase signalling methods.

BIP135 is an improvement of BIP9, which eliminated the 95% magical number. However, it is lack of reviewing and testing. I believe it worth the community the effort. After the BIP135 is mature, we can use BIP135 to introduce consensus rule change.

Flag day activation is dangerous. Human cannot predict the future. Human changes their minds constantly. Once such code released, miners may avoid running it at all, because miners are not sure about the readiness of other players.

We should use BIP9/135 to determine the forking block height. The signalling and the activation are both pre-coded and there is a higher confidence of the trustworthy of the signalling and the activation.

There is still re-org risk in such BUIP055. Bitcoin Unlimited follows the longest PoW accumulated chain. So if the big block chain happen first because majority of the hashing power support it, and then there will be two chains. (I will not comment whether it is good or bad to have two Bitcoin chains, or which chain is the better Bitcoin.) And if the small block chain is more profitable to mine due to either reducing in difficulty or higher exchange rate, and then there might be a risk that small block chain will have higher PoW accumulated, then BU will have to have to have a very large re-org. (Sorry, I have to add a political points here: the existence of such possibility will bring pressure on the exchange rate of the big block Bitcoin. If BU uses some very arbitrary methods to invalidate certain block, it will be very ugly.)

Since it is a very significant consensus rule change which has been debated for 4 years, we can add another consensus rule at and ONLY at the forking height, the size of the block HAS TO be bigger than 1,000,000 Byte. It is a very simple and straight forward way to protect re-org.

Conclusion: Bitmain has not decided to support this BUIP or not, but we have give some comments based on technical merits. We should use BIP9/BIP135 to signal and decide the forking height, and we should add a rule that at and only at the forking block, the size of that block HAS TO be larger than 1MB to prevent re-org. The technical comments should not be seen as an offer of supporting such BUIP.


Edit on May 12th, 2017

What if there is not enough transaction in the mempool and bigger than 1MB block cannot be built?

Yes, there is such probability. And the getblocktemplate will just find it cannot generate a valid block. Then we should just wait, until there is enough tx. It has been four years and we can afford to wait a few minutes, even 1 hour. And there is already a very good profitable transaction you can put into the block. "Save the chain".
 
Last edited:

jonny1000

Active Member
Nov 11, 2015
380
101
Jihan said:
There is still re-org risk in such BUIP055. Bitcoin Unlimited follows the longest PoW accumulated chain. So if the big block chain happen first because majority of the hashing power support it, and then there will be two chains. (I will not comment whether it is good or bad to have two Bitcoin chains, or which chain is the better Bitcoin.) And if the small block chain is more profitable to mine due to either reducing in difficulty or higher exchange rate, and then there might be a risk that small block chain will have higher PoW accumulated, then BU will have to have to have a very large re-org. (Sorry, I have to add a political points here: the existence of such possibility will bring pressure on the exchange rate of the big block Bitcoin. If BU uses some very arbitrary methods to invalidate certain block, it will be very ugly.)

Since it is a very significant consensus rule change which has been debated for 4 years, we can add another consensus rule at and ONLY at the forking height, the size of the block HAS TO be bigger than 1,000,000 Byte. It is a very simple and straight forward way to protect re-org.
Wow!! This is just amazing. I totally agree with you here. I have been making this point over and over again on this forum, almost driving myself completely nuts. I am so pleased you guys have finally taken this message on board.

Do you understand now that the reason many people opposed Bitcoin Classic is because it did not do this and people did not want to support the losing side? Do you think the community could now come together again if we all agree this BU/XT/Classic activation method for a hardfork is a losing, dangerous and bad strategy? That is what the argument was about, everyone wants larger blocks, it is just that some people want to make sure it is done in a safe way and the larger block chain wins. Lets finally stop this fighting and increase the blocksize in a safe way. Why not even go completely nuts with safety and make it ridiculously safe? Core developers like Johnson Lau have been researching even more clever technologies to make hardforks even safer.

This view is totally different to the BU philosophy, will you please remove the BU flag from your blocks? This would be seen as a huge sign of goodwill and can lead to the community uniting again.

Jihan said:
We should use BIP9/135 to determine the forking block height.
BIP9/135 are for softforks. They do not seem to have any relevance for hardforks. Are you saying you only want to increase the blocksize limit via a softfork now? Will you support BIP9 to activate SegWit?

I think we may still need to do a hardfork to increase the blocksize limit even more later. We can use the "at the forking height, the size of the block HAS TO be bigger" rule then.
 
Last edited:

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
@jonny1000

> This view is totally different to the BU philosophy, will you please remove the BU flag from your blocks?

He should not. BU is compatible with many different potential hard forks. With BIP100 for example, which you should have been fighting for in the censored sub, after you celebrated it. But you didn't.

> This would be seen as a huge sign of goodwill and can lead to the community uniting again.

LOL. Yes. A leading agitator of BSCore just signalled such goodwill:


We don't need the goodwill of those destroyers. We need to end this artificial mariage. Libertarians cannot stay married with them or 'unify' with those totalitarian traitors.
And we espacially don't need your goodwill; the goodwill of someone who falsely accuses us of having called you ' a pervert'.

 
Last edited:

SanchoPanza

Member
Mar 29, 2017
47
65
@jonny1000 :

BIP9 itself is specified to only apply to soft-forks. You can verify it by reading the specification.

BIP135 lifts that restriction explicitly. There was never a good reason for applying such a limitation in my opinion, except perhaps that some people thought soft-forks were a good way to exclusively enhance Bitcoin. If you wish to discuss the details of BIP135, I suggest we move that conversation to the BIP135 discussion thread on this forum, or create a new thread for it.
 
  • Like
Reactions: Zarathustra

jonny1000

Active Member
Nov 11, 2015
380
101
who falsely accuses us of having called you ' a pervert'.
The fact that all the upgraded miners also regard the old rules as valid and will build on top of them, while the non upgraded miners will only mine on the chain with the existing rules. This gives the existing rules a huge asymmetric advantage
"To repeat my self again, which I know is very frustrating to you guys. Once you realize the community will not let you have a narrow victory, you will win."

You can repeat your perverted consensus as much as you want. We are not stupid, and we don't have the desire to collaborate with the N.Korea Gang. That's your business, but not our's.
Here you are calling me perverted, ironically for making the exact point Jihan just made.
[doublepost=1494602413][/doublepost]
BIP135 lifts that restriction explicitly. There was never a good reason for applying such a limitation in my opinion, except perhaps that some people thought soft-forks were a good way to exclusively enhance Bitcoin. If you wish to discuss the details, I suggest we move that conversation to the BIP135 discussion thread on this forum.
Ok. So you mean the author of BIP135 intends it to apply to hardforks, while the author of BIP9 didnt? There is no technical reason?
 
Last edited: