BUIP039: Upgrade via extension point
Proposer: Amaury SÉCHET
Submitted: 2016-12-04
Status: draft

Summary:

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 BUIP defines OP_NOP1, OP_NOP4, OP_NOP5, OP_NOP6, OP_NOP7,
OP_NOP8, OP_NOP0 and OP_NOP10 as extension points. Future BUIP should
specify the extension points they add if appropriate.

After this BUIP 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 BUIP 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 BUIP 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.