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

Discussion in 'Bitcoin Unlimited' started by Peter R, May 10, 2017.

  1. Peter R

    Peter R
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 28, 2015
    Messages:
    1,199
    Likes:
    4,547
    reddit:
    Peter__R
    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=1000000] is the block size limit presently enforced, measured in bytes,​

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

    activation_height [default=494784] 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-analyt...chain-with-two-block-size-limits-5642ab0325dc
     
    #1 Peter R, May 10, 2017
    Last edited: Oct 6, 2017
    Norway, lunar, 79b79aa8 and 13 others like this.
  2. SanchoPanza

    SanchoPanza
    Expand Collapse
    Member

    Joined:
    Mar 29, 2017
    Messages:
    39
    Likes:
    49
    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.
     
    #2 SanchoPanza, May 10, 2017
    Last edited: May 10, 2017
    bluemoon likes this.
  3. Peter R

    Peter R
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 28, 2015
    Messages:
    1,199
    Likes:
    4,547
    reddit:
    Peter__R
    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.
     
    Norway, HostFat, lunar and 4 others like this.
  4. bitsko

    bitsko
    Expand Collapse
    Active Member

    Joined:
    Aug 31, 2015
    Messages:
    117
    Likes:
    347
    reddit:
    bitsko
    Perhaps someone could ask luke-jr about this?

    iirc he is involved in the BIP process?
     
    bluemoon likes this.
  5. lunar

    lunar
    Expand Collapse
    Active Member

    Joined:
    Aug 28, 2015
    Messages:
    649
    Likes:
    2,671
    freetrader and bluemoon like this.
  6. AdrianX

    AdrianX
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 28, 2015
    Messages:
    1,379
    Likes:
    3,769
    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.
     
    #6 AdrianX, May 10, 2017
    Last edited: May 10, 2017
  7. hodl

    hodl
    Expand Collapse
    New Member

    Joined:
    Feb 13, 2017
    Messages:
    4
    Likes:
    15
    this sounds good to me.

    when and where do we vote?
     
    Norway, freetrader, lunar and 3 others like this.
  8. torusJKL

    torusJKL
    Expand Collapse
    Member

    Joined:
    Nov 30, 2016
    Messages:
    81
    Likes:
    173
    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?
     
    AdrianX, lunar and Zarathustra like this.
  9. Zarathustra

    Zarathustra
    Expand Collapse
    Active Member

    Joined:
    Aug 28, 2015
    Messages:
    564
    Likes:
    1,661
    I'm not unhappy that the dipshits and their idol are blocking segwit by refusing a litecoin-like non-full block agreement.

    Hodl!
     
    AdrianX likes this.
  10. jbreher

    jbreher
    Expand Collapse
    Active Member

    Joined:
    Dec 31, 2015
    Messages:
    150
    Likes:
    473
    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?
     
    Norway and AdrianX like this.
  11. Peter R

    Peter R
    Expand Collapse
    Well-Known Member

    Joined:
    Aug 28, 2015
    Messages:
    1,199
    Likes:
    4,547
    reddit:
    Peter__R
    @jbreher: yes. I would also propose that it be "off" by default.
     
    Norway and AdrianX like this.
  12. Roy Badami

    Roy Badami
    Expand Collapse
    Member

    Joined:
    Dec 27, 2015
    Messages:
    92
    Likes:
    117
    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.
     
  13. Emil Oldenburg

    Emil Oldenburg
    Expand Collapse
    New Member

    Joined:
    Nov 28, 2016
    Messages:
    2
    Likes:
    19
    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.
     
    freetrader likes this.
  14. Jihan

    Jihan
    Expand Collapse
    New Member

    Joined:
    Mar 3, 2016
    Messages:
    9
    Likes:
    87
    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".
     
    #14 Jihan, May 12, 2017
    Last edited: May 12, 2017
    Norway, bluemoon, 79b79aa8 and 7 others like this.
  15. jonny1000

    jonny1000
    Expand Collapse
    Active Member

    Joined:
    Nov 11, 2015
    Messages:
    379
    Likes:
    100
    reddit:
    jonny1000
    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.

    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.
     
    #15 jonny1000, May 12, 2017
    Last edited: May 12, 2017
  16. SanchoPanza

    SanchoPanza
    Expand Collapse
    Member

    Joined:
    Mar 29, 2017
    Messages:
    39
    Likes:
    49
    Zarathustra likes this.
  17. Zarathustra

    Zarathustra
    Expand Collapse
    Active Member

    Joined:
    Aug 28, 2015
    Messages:
    564
    Likes:
    1,661
    @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'.

     
    #17 Zarathustra, May 12, 2017
    Last edited: May 12, 2017
    79b79aa8, bitsko, solex and 1 other person like this.
  18. jonny1000

    jonny1000
    Expand Collapse
    Active Member

    Joined:
    Nov 11, 2015
    Messages:
    379
    Likes:
    100
    reddit:
    jonny1000
  19. SanchoPanza

    SanchoPanza
    Expand Collapse
    Member

    Joined:
    Mar 29, 2017
    Messages:
    39
    Likes:
    49
    @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.
     
    Zarathustra likes this.
  20. jonny1000

    jonny1000
    Expand Collapse
    Active Member

    Joined:
    Nov 11, 2015
    Messages:
    379
    Likes:
    100
    reddit:
    jonny1000
    Here you are calling me perverted, ironically for making the exact point Jihan just made.
    --- Double Post Merged, May 12, 2017 ---
    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?
     
    #20 jonny1000, May 12, 2017
    Last edited: May 12, 2017