BIP99: Motivation and deployment of consensus rule changes #181

pull jtimon wants to merge 3 commits into bitcoin:master from jtimon:bip-forks changing 1 files +336 −0
  1. jtimon commented at 11:11 AM on August 19, 2015: contributor

    This BIP attempts to classify all possible scenarios for consensus rule changes (soft/hard forks) as well as recommending a deployment path for each of them.

    It also contains code proposing a first uncontroversial hardfork that conclusively fixes the timewarp attack: https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11

    The recommended activation conditions for uncontroversial hardforks are still being discussed in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

    More general discussion about the BIP can still continue in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html

  2. Add BIP99 for consensus rule changes deployment 9a81f01a3d
  3. fix 32bb5cdeab
  4. kanzure commented at 11:24 PM on August 19, 2015: contributor

    When there are two or more simultaneous hard-fork chains, transactions that are intended for only one chain may end up on both chains, especially if the transaction does not have inputs that are tainted by only-one-side coinbase transaction outputs. However, the effects of this may be mitigated if everyone was using some sort of opcode that could restrict the transaction to a blockchain where the history included some particular blockhash.... but then there's a payment coordination problem, you'd probably have to update BIP70 to include this feature, etc. What a mess.

  5. squidicuzz commented at 11:45 PM on August 22, 2015: none

    An potential attack vector scenario regarding Schism hardforks:

    If a fork is contested when activated and both resulting chains continue; impassioned and nefarious users may utilize their funds on the chain they oppose to flood the network with spam transactions. Attackers could also use funds on both chains to double their attack power. Since both chains should see these transactions and user passions may be high, this has the possibly of resulting in a significant spam attack.

    I am not sure how to handle something like this.

  6. jwilkins commented at 11:47 PM on August 22, 2015: contributor

    It would really help if BIPs related to the current blocksize debate were available in the repo, not just in pull requests. Any chance this and the others can get merged soon?

  7. jtimon commented at 6:59 AM on August 23, 2015: contributor

    Jonathan, I'm not sure why that's important: people can just PR to https://github.com/jtimon/bips/tree/bip-forks in the meantime.

    squidicuz sounds like a sensible thing to add to the text (I wonder where you get that idea from...). an you directly propose changes to the text by PRing to https://github.com/jtimon/bips/tree/bip-forks ?

    On Sun, Aug 23, 2015 at 1:47 AM, Jonathan Wilkins notifications@github.com wrote:

    It would really help if BIPs related to the current blocksize debate were available in the repo, not just in pull requests. Any chance this and the others can get merged soon?

    — Reply to this email directly or view it on GitHub.

  8. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
      31 | +- Consensus fork: a divergence in the implementation of the
  32 | +  verification rules can impede the expected eventual convergence of
  33 | +  the network in a single chain that has the most proof of work and
  34 | +  also satisfies the rules. This can be intentional or be caused by a
  35 | +  bug in consensus validation reimplementations.
  36 | +- Softfork: an intentional consensus fork where everything that
    kanzure commented at 9:39 PM on September 3, 2015:

    nitpick: "soft-fork" not "softfork". Same comment for hard-fork vs hardfork.

  9. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
      35 | +  bug in consensus validation reimplementations.
  36 | +- Softfork: an intentional consensus fork where everything that
  37 | +  was previously invalid remains invalid, but some things that were
  38 | +  valid also become invalid. Majority of miners can impose
  39 | +  this kind of changes and they also have some deployment advantages.
  40 | +- Hardfork: an intentional consensus fork that is not a softfork.
    kanzure commented at 9:40 PM on September 3, 2015:

    There can be non-intentional hard-forks, as evidenced by the existence of previous chain consensus forking. Non-intentional hard-forks are also not soft-forks, in addition to intentional consensus forks.

  10. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
      75 | +Hopefully libbitcoinconsensus will remove this type of consensus fork
  76 | +which - being accidental - obviously don't need a deployment plan.
  77 | +
  78 | +====11/12 March 2013 Chain Fork====
  79 | +
  80 | +There is a precedent of an accidental consensus fork at height 225430.
    kanzure commented at 9:42 PM on September 3, 2015:

    There's a post-mortem about the March 2013 fork in bip50, perhaps that should be linked or worked into this section?

    https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

  11. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
      78 | +====11/12 March 2013 Chain Fork====
  79 | +
  80 | +There is a precedent of an accidental consensus fork at height 225430. 
  81 | +Without entering in much detail, the situation was different from
  82 | +what's being described from the alternative implementation risks (today alternative implementation
  83 | +still usually rely in different degrees on bitcoin core trusted proxies, which
    kanzure commented at 9:42 PM on September 3, 2015:

    s/bitcoin core/Bitcoin Core/ to make the name more obvious here.

  12. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
     297 | +enough that is trivial to apply to diverse implementations (that
 298 | +currently can only use libbitcoinconsensus to validate script-related
 299 | +rules). The change has been already widely tested in many altcoins.
 300 | +
 301 | +The chosen consensus change is the fix of the timewarp attack
 302 | +discovered and also fixed with a simple patch[5] by @ArtForz. This
    kanzure commented at 9:45 PM on September 3, 2015:

    Is @ArtForz supposed to be a twitter reference? If so, simply link to the twitter page. We're not going to remember the "@ means twitter" stuff in 15 years.

    jtimon commented at 9:31 PM on November 5, 2015:

    it's supposed to be a github reference.

  13. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
     300 | +
 301 | +The chosen consensus change is the fix of the timewarp attack
 302 | +discovered and also fixed with a simple patch[5] by @ArtForz. This
 303 | +change has been deployed by most altcoins that made any minimally
 304 | +meaningful change to bitcoin and thus can be considered somewhat
 305 | +tested (in fact, most SHA256d altcoins that didn't implemented it have
    kanzure commented at 9:46 PM on September 3, 2015:

    minor grammar nit: "that didn't implemented it" -> "that didn't implement it"

  14. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
     319 | +
 320 | +[1] https://en.wikipedia.org/wiki/Schism
 321 | +
 322 | +[2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 323 | +
 324 | +[3] http://sourceforge.net/p/bitcoin/mailman/message/34146741/
    kanzure commented at 9:50 PM on September 3, 2015:

    Somehow I suspect the linuxfoundation mailing list archive will be more permanent or canonical than sourceforge links, so I suggest switching the link to: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html

  15. in bip-0099.mediawiki:None in 32bb5cdeab outdated 
     205 | +either since this kind of hardfork would not qualify as
 206 | +uncontroversial anyway.
 207 | +
 208 | +===Uncontroversial consensus upgrades===
 209 | +
 210 | +"Uncontroversial" is something though to define in this context. What
    kanzure commented at 9:51 PM on September 3, 2015:

    word choice nitpick: You might mean "tough" (difficult) and not "though", although "though" could be made to work in this context.

  16. gmaxwell commented at 11:03 PM on September 3, 2015: contributor

    Is this waiting for something for a merge?

  17. luke-jr commented at 11:24 PM on September 3, 2015: member

    IMO this BIP should actually be Process type, since it defines rules for other BIPs to use?

  18. luke-jr commented at 2:32 AM on September 4, 2015: member

    @andychase BIP drafts are not rejected. Merging is a given with approval from the author.

  19. luke-jr commented at 2:33 AM on September 4, 2015: member

    Oh, and don't forget to update README.mediawiki!

  20. andychase commented at 2:44 AM on September 4, 2015: contributor

    @luke-jr I was referring to merging or rejecting/closing these specifically: https://github.com/jtimon/bips/pull/2 https://github.com/jtimon/bips/pull/1 edit: merged and good to go

  21. kanzure commented at 11:57 PM on September 13, 2015: contributor

    @jtimon, I was talking with Rusty and he mentioned that all soft-forks are actually hard-forks for miners. Perhaps wording to this effect should be included in the soft-fork/hard-fork distinctions.

  22. luke-jr commented at 6:21 PM on September 19, 2015: member

    @jtimon Please add a copyright section, and address @kanzure 's comments (or say you do not intend to make further changes, so I know to merge without them).

  23. in bip-0099.mediawiki:None in 13edee0a62 outdated 
     136 | +
 137 | +In all of the following examples there's clearly a confrontation that
 138 | +is being resolved using an intentional consensus fork.
 139 | +
 140 | +Being a schism hardfork, there will likely be 2 chains
 141 | +coexisting for at least some time, maybe forever. Maybe bitcoin
    gavinandresen commented at 3:58 PM on October 8, 2015:

    I strongly disagree with "there will likely."

    There are incredibly strong incentives for people to come to consensus; if they don't, they will lose money (via the mechanism I described on the bitcoin-dev mailing list here: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011291.html).

    Jorge's response of "if there is demand then people will stick with the minority" is where I take issue: I claim that there will NOT be demand, because ~everybody has a limit to how economically irrational they will be.

    We saw this with the "Lets stick with 50 BTC" people around the first bitcoin halving.

    Did you run any of this by an economist who has studied markets that require consensus?

  24. luke-jr added the label New BIP on Oct 23, 2015
  25. Some of kanzure's nits, copyright, updated Attribution, don't repeat "Without entering in much detail" 8d4ae8adf6
  26. jtimon force-pushed on Nov 5, 2015
  27. jtimon commented at 10:39 PM on November 5, 2015: contributor

    @luke-jr added copyright section. I think this still needs more work, and some parts like the recommended deployment methods need more discussion. We can merge it and leave it as a draft and I open another PR with further changes. Or keep changing this one, whatever is preferred. @reviewers I'm going to switch from block height (which apparently only a couple of persons ) to the block median time, which shares its main advantages height while not having its "hard to calculate dates" problem. But in addition to the minimum activation median time, I'm going to maintain the 95% versionbits miner upgrade confirmation for uncontroversial hardforks (because if it's truly uncontroversial and we're expecting 100% of the users to upgrade before the minimum time, I think we can safely expect that also 95% of the miners (who are also users) will upgrade at some point). @kanzure I defined both softforks and hardforks and left the term "unintentional consensus fork" for unintentional consensus forks regardless of them being softforks or hardforks. I hopefully solved the rest of nits. @gavinandresen

    I strongly disagree with "there will likely."

    Fine, I will s/there will likely be 2 chains/there will be 2 chains/ and, at the same time, be more strict defining the conditions when a schism hardfork happens. I agree that the schism hardfork section needs more work though.

    Jorge's response of "if there is demand then people will stick with the minority" is where I take issue

    I never claimed to be able to predict whether "people" would stick to some particular chain or not, I said that if people stick to a chain and there's demand for the block reward in that chain, there will likely be miners to mine, even if it's just to sell it right away. This has been proven with a myriad of altcoins (including some like Freicoin that people assured me "no body would ever mine"). If there's demand, offer will likely appear, this is not specific to this market.

    We saw this with the "Lets stick with 50 BTC" people around the first bitcoin halving.

    Thank you very much! I didn't remember this. This is an excellent past example of a schism hardfork. If I remember correctly, the fork only lasted a few blocks that time. But from one observation, we cannot infer that all cases will last that long or even that they will have an end at all.

    EDIT: if anybody has any links to the inflatacoin schism hardfork, they're more than welcomed!

  28. luke-jr referenced this in commit ea6a7158cd on Nov 7, 2015
  29. luke-jr merged this on Nov 7, 2015
  30. luke-jr closed this on Nov 7, 2015
  31. jtimon commented at 10:28 AM on November 7, 2015: contributor

    I could have at least squashed and add it to the readme...

  32. andychase commented at 10:37 AM on November 7, 2015: contributor

    Just noticed that this patch no longer includes the changes made by @instagibbs and I. @jtimon did you force push your repository at some point?

    Also this still needs clarification on the type in the preamble.

  33. andychase commented at 10:37 AM on November 7, 2015: contributor

    @luke-jr Also what's the process to get this BIP approved? Is it just a simple majority vote among the core devs? BIP-0001 doesn't specify that process.

  34. jtimon commented at 11:10 AM on November 7, 2015: contributor

    @andychase I'll look into it, I merged your changes... No voting: when I think it's ready I move it from draft (that doesn't mean that the code has to be deployed or that people are forced to use my decinitions or classification though).

  35. luke-jr commented at 5:44 PM on November 7, 2015: member

    @andychase BIP 1 provides an overview of BIP status. Core devs are not particularly relevant in any special/unique way. That being said, I don't know how the status would proceed on this particular BIP. Perhaps someone should bring it up at a Bitcoin development meeting after the draft has reached a more-or-less-final state.

  36. jtimon commented at 6:23 PM on November 7, 2015: contributor

    @luke-jr +1 "after the draft has reached a more-or-less-final state".

  37. jtimon cross-referenced this on Nov 8, 2015 from issue Bip99: Improvements by jtimon
  38. jtimon commented at 12:26 PM on November 8, 2015: contributor

    @andychase you were right, I forgot to fetch the version with your changes incorporated and I kept working on a local older version. I've opened #237 with those changes and more improvements (specially in the "Schism hardforks" section).

  39. ajtowns referenced this in commit cb187012b6 on Jan 10, 2020
Contributors
jtimonkanzuresquidicuzzjwilkinsgmaxwellluke-jrandychasegavinandresen
Labels
New BIP
Linked (view graph)
#237 Bip99: Improvements
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-14 15:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me