BIP 90: Buried deployments #480

1. 
   sdaftuar commented at 5:29 pm on November 30, 2016: member

   I think this is ready to move forward, can this be assigned a BIP number?
2. Initial draft of buried deployments. 836d2dc91e
3. Emphasize code simplification over performance optimization 0fc3fe20ca
4. 
   luke-jr commented at 9:19 pm on November 30, 2016: member

   Let’s call this BIP 90.

   It would be ideal if it had a dedicated Backwards Compatibility section and was explicit about being a hardfork.

5. luke-jr added the label New BIP on Nov 30, 2016
6. luke-jr renamed this:
   Proposed BIP: Buried Deployments
   BIP 90: Buried deployments
   on Nov 30, 2016
7. 
   sipa commented at 9:24 pm on November 30, 2016: member

   It does explicitly mention It is technically possible for this to be a non-backwards compatible change., which is true, though in Bitcoin Core at this point that is dependent on also removing checkpoints.
8. 
   luke-jr commented at 9:35 pm on November 30, 2016: member

   Indeed, it’s not a barrier to merging because B.C. is being addressed in another section. I just thought it would still be nice to have an explicit section for this. :)

   AFAIK Core doesn’t enforce checkpoints strictly anymore?

9. 
   sdaftuar commented at 1:46 pm on December 1, 2016: member

   @luke-jr I felt the Considerations section addressed all the information that a Backwards Compatibility section would have; if I were to add one, I’m not sure what more to say.

   As for using the term “hard fork” in this document – I considered adding something like that, but rejected that idea because I think the term “hard fork” is not a universally well understood/defined term, and that it would be less clarifying to use that term than the language I’ve already included, which more explicitly describes the circumstances which lead to consensus split. (FYI I double-checked that BIP 34 and BIP 65 make no mention of the terms “soft fork” or “hard fork”, though BIP 66 does use the term “soft fork” without definition.)

   This is an aside, but regarding checkpoints:

   though in Bitcoin Core at this point that is dependent on also removing checkpoints.

   I don’t believe this is the case for BIP 65 or BIP 66, which activated past the last Core-checkpointed block height.

   AFAIK Core doesn’t enforce checkpoints strictly anymore?

   There have been some tweaks to how checkpoints are used, but Core hasn’t yet released a version that disable the effect of checkpoints locking in a particular chain, once the headers have been seen – though I believe there’s work underway to do so, potentially even for the next release.

10. Assign BIP90 and update README 5d21c93a68
11. 
    sdaftuar commented at 1:57 pm on December 1, 2016: member

    Updated with BIP number assignment and added to README.mediawiki.
12. 
    btcdrak commented at 4:23 pm on December 1, 2016: contributor

    ACK
13. fix preamble 2bc2f06089
14. sdaftuar force-pushed on Dec 1, 2016
15. luke-jr merged this on Dec 1, 2016
16. luke-jr closed this on Dec 1, 2016

    ---

17. 
    NicolasDorier commented at 5:40 pm on December 2, 2016: contributor

    if anybody have interest, I can rebase https://github.com/bitcoin/bitcoin/pull/8460 which formalize that better in code.

Contributors
sdaftuar luke-jr sipa btcdrak NicolasDorier

Labels
New BIP