|
Recently, a new Bitcoin Improvement Proposal (BIP) has attracted widespread attention from the community because of its highly controversial nature. It is BIP 148 (Segregated Witness Deployment Forced Activation), which involves a new soft fork method - UASF (User Activated Soft Fork). According to the description of this proposal, if the existing Segregated Witness deployment cannot be activated before August 1, 2017, then the BIP will be activated at a time point between August 1, 2017 and November 15, 2017 at midnight. But if the existing Segregated Witness deployment is activated, then this BIP will stop being activated. In this regard, some people in the community interpreted it as: CORE has abandoned the 95% computing power voting consensus and will unconditionally force the activation of isolated verification on August 1st. There is a misunderstanding here. Some people may understand the proposals at the draft stage as the consensus of CORE, which is the Final (implementation) stage. In order to avoid unnecessary misunderstandings, Wang Situ needs to explain the steps that BIP needs to go through from proposal to implementation, as well as what BIPs are currently available. 1. What is the BIP submission and review process? To submit a BIP, you should first post your idea or document to the mailing list. After discussion, the initiator needs to contact Luke Dashjr via email < [email protected] >. After Luke Dashjr edits and approves the BIP, it will be published at https://github.com/bitcoin/bips. According to the rules, anyone can submit a BIP. Please note that publishing a BIP on the https://github.com/bitcoin/bips page does not mean that it has been officially accepted . It is only officially accepted when its status changes to Active . In order for a BIP to be officially activated, it needs to be agreed upon by the developer community. The current BIP status can be divided into 9 types, namely Proposed , Draft , Active , Final , Replaced , Withdrawn , Deferred , BIP number allocated , and Rejected . Babbitt Forum moderator Maya divided this process into 7 steps based on his own understanding: Step 1: Ideas. Anyone can propose their own preliminary ideas for improvement through any channels, such as forums, Twitter, etc., to gain more support and recognition.
Step 2: Proposal, which can summarize the suggestions from community discussions, describe the plan in detail in a more standardized format, and submit it as a BIP proposal document.
Step 3: Formal proposals. Numbers are assigned to BIP proposals that are more important or have more approval. In order to facilitate discussion and distinguish between proposals, proposals with numbers are considered formal proposals.
Step 4: Implement the code. Some developers will implement the concept of the BIP formal proposal into specific code and conduct strict testing on the test network to ensure that the code is as bug-free as possible.
Step 5: Activation settings. After there are no problems with the code, set the activation threshold, allocate activation mark bits, buffer time, etc. according to the BIP9 Upgrade Specification.
Step 6: Release the version. If enough people sign and agree, the BIP code will be absorbed and released in the latest version, but it will be in an inactive state.
Step 7: Activate. After reaching the activation threshold set by BIP9, the plan will be officially activated and take effect. Test whether the plan is successful. If there is a problem, you may return to the previous version.
The currently controversial BIP 148 is only in the draft stage , and according to the responses of many developers, the possibility of this draft being activated is very low. What are the BIPs that are currently finalized? Attached is the list of BIPs that have been implemented ( Final ): BIP Support Software Version Title
9 v0.12.1 Version bits with timeout and delay
Author: (Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell)
11 v0.6.0 M-of-N Standard Transactions
Author: (Gavin Andresen)
13 v0.6.0 Address Format for pay-to-script-hash
Author: (Gavin Andresen)
14 v0.6.0 Protocol Version and User Agent
Author: (Amir Taaki, Patrick Strateman)
16 v0.6.0 Pay To Script Hash
Author: (Gavin Andresen)
21 v0.6.0 URI Scheme
Author: (Nils Schneider, Matt Corallo)
22 v0.7.0 getblocktemplate
Author: (Luke Dashjr)
23 v0.10.0 getblocktemplate – Pooled Mining
Author: (Luke Dashjr)
30 v0.6.0 Duplicate transactions
Author: (Pieter Wuille)
31 v0.6.1 Pong message
Author: Mike Hearn
34 v0.7.0 v2 version block, coinbase height (Block v2, Height in coinbase)
Author: （Gavin Andresen）
35 v0.7.0 mempool message
Author: (Jeff Garzik)
37 v0.8.0 Bloom filtering
Author: (Mike Hearn, Matt Corallo)
42 v0.9.2 A finite monetary supply for Bitcoin
Author: Pieter Wuille
61 v0.9.0 “reject” P2P message
Author: (Gavin Andresen)
65 v0.10.4 OP_CHECKLOCKTIMEVERIFY
Author: (Peter Todd)
68 v0.12.1 Relative lock-time using consensus-enforced sequence numbers
Author: (Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona)
66 v0.10.0 Strict DER signatures
Author: Pieter Wuille
70 v0.9.0 Payment protocol
Author: (Gavin Andresen, Mike Hearn)
71 v0.9.0 Payment protocol MIME types
Author: （Gavin Andresen）
72 v0.9.0 URI extensions for Payment Protocol
Author: （Gavin Andresen）
111 v0.12.0 NODE_BLOOM service bit
Author: Matt Corallo, Peter Todd
112 v0.12.1 OP_CHECKSEQUENCEVERIFY
Author: (BtcDrak, Mark Friedenbach, Eric Lombrozo)
113 v0.12.1 Median Time Past
Author: (Thomas Kerin, Mark Friedenbach)
125 v0.12.0 Opt-in Full Replace-by-Fee Signaling
Author: (David A. Harding, Peter Todd)
130 v0.12.0 Sendheaders message (Sendheaders message)
Author: (Suhas Daftuar)
141 v0.13.0 Segregated Witness (consensus layer)
Author: (Eric Lombrozo, Johnson Lau, Pieter Wuille)
143 v0.13.0 Transaction Signature Verification for Version 0 Witness Program
Author: （Johnson Lau, Pieter Wuille）
144 v0.13.0 Segregated Witness (Peer Services)
Author: (Eric Lombrozo, Pieter Wuille)
145 v0.13.0 getblocktemplate Updates for Segregated Witness
Author: (Luke Dashjr)
147 v0.13.1 Dealing with dummy stack element malleability
Author: (Johnson Lau) Sorting the developers by the number of times their BIPs entered the Final stage, the top 5 are Gavin Andresen (8 times), Pieter Wuille (7 times), Peter Todd (4 times), Luke Dashjr (3 times) and Johnson Lau (3 times). What are the current BIPs? Attached is a list of all current BIPs: | BIP Number | Layer | title | author | type | state | | 1 | | BIP Purpose and Guidelines | Amir Taaki | Process | Replaced | | 2 | | BIP process, revised | Luke Dashjr | Process | Active | | 9 | | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Final | | 10 | Applications | Multi-Sig Transaction Distribution | Alan Reiner | Informational | Withdrawn | | 11 | Applications | M-of-N Standard Transactions | Gavin Andresen | Standard | Final | | 12 | Consensus (soft fork) | OP_EVAL | Gavin Andresen | Standard | Withdrawn | | 13 | Applications | Address Format for pay-to-script-hash | Gavin Andresen | Standard | Final | | 14 | Peer Services | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard | Final | | 15 | Applications | Aliases | Amir Taaki | Standard | Deferred | | 16 | Consensus (soft fork) | Pay to Script Hash | Gavin Andresen | Standard | Final | | 17 | Consensus (soft fork) | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr | Standard | Withdrawn | | 18 | Consensus (soft fork) | hashScriptCheck | Luke Dashjr | Standard | Proposed | | 19 | Applications | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr | Standard | Draft | | 20 | Applications | URI Scheme | Luke Dashjr | Standard | Replaced | | twenty one | Applications | URI Scheme | Nils Schneider, Matt Corallo | Standard | Final | | twenty two | API/RPC | getblocktemplate – Fundamentals | Luke Dashjr | Standard | Final | | twenty three | API/RPC | getblocktemplate – Pooled Mining | Luke Dashjr | Standard | Final | | 30 | Consensus (soft fork) | Duplicate transactions | Pieter Wuille | Standard | Final | | 31 | Peer Services | Pong message | Mike Hearn | Standard | Final | | 32 | Applications | Hierarchical Deterministic Wallets | Pieter Wuille | Informational | Final | | 33 | Peer Services | Stratified Nodes | Amir Taaki | Standard | Draft | | 34 | Consensus (soft fork) | Block v2, Height in Coinbase | Gavin Andresen | Standard | Final | | 35 | Peer Services | mempool message | Jeff Garzik | Standard | Final | | 36 | Peer Services | Custom Services | Stefan Thomas | Standard | Draft | | 37 | Peer Services | Connection Bloom filtering | Mike Hearn, Matt Corallo | Standard | Final | | 38 | Applications | Passphrase-protected private key | Mike Caldwell, Aaron Voisine | Standard | Draft | | 39 | Applications | Mnemonic code for generating deterministic keys | Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard | Proposed | | 40 | API/RPC | Stratum wire protocol | Marek Palatinus | Standard | BIP number allocated | | 41 | API/RPC | Stratum mining protocol | Marek Palatinus | Standard | BIP number allocated | | 42 | Consensus (soft fork) | A finite monetary supply for Bitcoin | Pieter Wuille | Standard | Draft | | 43 | Applications | Purpose Field for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Informational | Draft | | 44 | Applications | Multi-Account Hierarchy for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Standard | Proposed | | 45 | Applications | Structure for Deterministic P2SH Multisignature Wallets | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Proposed | | 47 | Applications | Reusable Payment Codes for Hierarchical Deterministic Wallets | Justus Ranvier | Informational | Draft | | 49 | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl | Informational | Draft | | 50 | | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational | Final | | 60 | Peer Services | Fixed Length “version” Message (Relay-Transactions Field) | Amir Taaki | Standard | Draft | | 61 | Peer Services | Reject P2P message | Gavin Andresen | Standard | Final | | 62 | Consensus (soft fork) | Dealing with malleability | Pieter Wuille | Standard | Withdrawn | | 63 | Applications | Stealth Addresses | Peter Todd | Standard | BIP number allocated | | 64 | Peer Services | getutxo message | Mike Hearn | Standard | Draft | | 65 | Consensus (soft fork) | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard | Final | | 66 | Consensus (soft fork) | Strict DER signatures | Pieter Wuille | Standard | Final | | 67 | Applications | Deterministic Pay-to-script-hash multi-signature addresses through public key sorting | Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard | Proposed | | 68 | Consensus (soft fork) | Relative lock-time using consensus-enforced sequence numbers | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard | Final | | 69 | Applications | Lexicographical Indexing of Transaction Inputs and Outputs | Kristov Atlas | Informational | Proposed | | 70 | Applications | Payment Protocol | Gavin Andresen, Mike Hearn | Standard | Final | | 71 | Applications | Payment Protocol MIME types | Gavin Andresen | Standard | Final | | 72 | Applications | bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final | | 73 | Applications | Use “Accept” header for response type negotiation with Payment Request URLs | Stephen Pair | Standard | Final | | 74 | Applications | Allow zero value OP_RETURN in Payment Protocol | Toby Padilla | Standard | Draft | | 75 | Applications | Out of Band Address Exchange using Payment Protocol Encryption | Justin Newton, Matt David, Aaron Voisine, James MacWhyte | Standard | Draft | | 80 | | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred | | 81 | | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred | | 83 | Applications | Dynamic Hierarchical Deterministic Key Trees | Eric Lombrozo | Standard | Draft | | 90 | Consensus (hard fork) | Buried Deployments | Suhas Daftuar | Informational | Draft | | 99 | | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón | Informational | Draft | | 101 | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Withdrawn | | 102 | Consensus (hard fork) | Block size increased to 2MB | Jeff Garzik | Standard | Draft | | 103 | Consensus (hard fork) | Block size following technological growth | Pieter Wuille | Standard | Draft | | 104 | Consensus (hard fork) | 'Block75′ – Max block size like difficulty | t.khan | Standard | Draft | | 105 | Consensus (hard fork) | Consensus based block size retargeting algorithm | BtcDrak | Standard | Draft | | 106 | Consensus (hard fork) | Dynamically Controlled Bitcoin Block Size Max Cap | Upal Chakraborty | Standard | Draft | | 107 | Consensus (hard fork) | Dynamic limit on the block size | Washington Y. Sanchez | Standard | Draft | | 109 | Consensus (hard fork) | Two million byte size limit with sigop and sighash limits | Gavin Andresen | Standard | Rejected | | 111 | Peer Services | NODE_BLOOM service bit | Matt Corallo, Peter Todd | Standard | Proposed | | 112 | Consensus (soft fork) | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Final | | 113 | Consensus (soft fork) | Median time-past as endpoint for lock-time calculations | Thomas Kerin, Mark Friedenbach | Standard | Final | | 114 | Consensus (soft fork) | Merkelized Abstract Syntax Tree | Johnson Lau | Standard | Draft | | 120 | Applications | Proof of Payment | Kalle Rosenbaum | Standard | Draft | | 121 | Applications | Proof of Payment URI scheme | Kalle Rosenbaum | Standard | Draft | | 122 | Applications | URI scheme for Blockchain references/exploration | Marco Pontello | Standard | Draft | | 123 | | BIP Classification | Eric Lombrozo | Process | Active | | 124 | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Informational | Draft | | 125 | Applications | Opt-in Full Replace-by-Fee Signaling | David A. Harding, Peter Todd | Standard | Proposed | | 126 | | Best Practices for Heterogeneous Input Script Transactions | Kristov Atlas | Informational | Draft | | 130 | Peer Services | sendheaders message | Suhas Daftuar | Standard | Proposed | | 131 | Consensus (hard fork) | “Coalescing Transaction” Specification (wildcard inputs) | Chris Priest | Standard | Draft | | 132 | | Committee-based BIP Acceptance Process | Andy Chase | Process | Withdrawn | | 133 | Peer Services | feefilter message | Alex Morcos | Standard | Draft | | 134 | Consensus (hard fork) | Flexible Transactions | Tom Zander | Standard | Draft | | 140 | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard | Draft | | 141 | Consensus (soft fork) | Segregated Witness (Consensus layer) | Eric Lombrozo, Johnson Lau, Pieter Wuille | Standard | Draft | | 142 | Applications | Address Format for Segregated Witness | Johnson Lau | Standard | Deferred | | 143 | Consensus (soft fork) | Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard | Draft | | 144 | Peer Services | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard | Draft | | 145 | API/RPC | getblocktemplate Updates for Segregated Witness | Luke Dashjr | Standard | Draft | | 146 | Consensus (soft fork) | Dealing with signature encoding malleability | Johnson Lau, Pieter Wuille | Standard | Draft | | 147 | Consensus (soft fork) | Dealing with dummy stack element malleability | Johnson Lau | Standard | Draft | | 148 | Consensus (soft fork) | Mandatory activation of segwit deployment | Shaolin Fry | Standard | Draft | | 150 | Peer Services | Peer Authentication | Jonas Schnelli | Standard | Draft | | 151 | Peer Services | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard | Draft | | 152 | Peer Services | Compact Block Relay | Matt Corallo | Standard | Draft | | 171 | Applications | Currency/exchange rate information API | Luke Dashjr | Standard | Draft | | 180 | Peer Services | Block size/weight fraud proof | Luke Dashjr | Standard | Draft | | 199 | Applications | Hashed Time-Locked Contract transactions | Sean Bowe, Daira Hopwood | Standard | Draft |
Interestingly, among all the BIPs, the only one in the Rejected state is BIP109 proposed by Gavin Andresen. At this point, readers should have some understanding of BIP. We should treat BIP rationally. Only when it enters the Active state, we consider it accepted by Core. (This article is purely for popular science and does not represent my personal position) |
