To this date, there are only 2 ways to upgrade the Bitcoin network, commonly know as hard fork and soft fork. Both mechanisms have their own shortcomings. Soft forks are activated by miners and there is no way for node operators to voice their opinion on the fork nor is there a mechanism for them to oppose it. On the other hand, hard forks require everybody to upgrade in lockstep and create risk at activation time.

This BUIP proposes to upgrade using known extension points to introduce new feature into bitcoin. Because nodes known about these extension points, they can notice feature activation, even of features they don't know about, and act accordingly.

This task defines OP_NOP1, OP_NOP4, OP_NOP5, OP_NOP6, OP_NOP7, OP_NOP8, OP_NOP0 and OP_NOP10 as extension points. Future proposals should specify the extension points they add if appropriate.

After this proposal activates, soft forks must be considered as 51% attack and dealt with accordingly. Adding new extension points should either be done using an existing extension points, or via a hard forks.

Extension activation, signaling and acceptance:

To start using an extension point, miner can signal their intention to do so using BIP9 signaling. When the extension point activates, node can either accept blocks using the extension point, or use their AD parameter to wait and see if the block is accepted by the network at large before accepting it itself, if they don't know about this new feature, or do not wish to activate it. Effectively, if too many nodes reject the block using the new extension point, the block will be orphaned.

The process repeats for each extension point.

Nodes can signal the extension they are willing to activate in their user agent string in a / separated string as they do for MG/EB/AD . For OP_NOP, They can signal using the OP_NOP prefix followed by a coma separated list of number indicating which OP_NOP the node is willing to activate. For instance, OP_NOP1,5,8 indicate that the node is willing to activate use of OP_NOP1, OP_NOP5 and OP_NOP8. other OP_NOP uses will be rejected until AD blocks are constructed on top of the first block that uses it.

Conclusion:

This proposal introduces an upgrade mechanism that has guarantee close the ones of a hard fork, while greatly diminishing the risks involved. Most upgrade to the consensus code which have been done over the years do fit what this proposal describes, except P2SH and SegWit. This process has been relatively successful and should serve as a model for future upgrades. Adding the capability for nodes to voice their intention add insurance that the interests of various actors are aligned.