So I got some feedback on this and the #1 feed back is that they were confused. I tried to put the post above is abstract terms as I don't wanted to tie the idea to a specific implementation of the idea (as I wanted to ruse it for BUIP037).



In order to makes things clearer, I'll explain how the mechanism would work specifically for OP_NOPs.



Bitcoin uses a script mechanism to check the validity of transaction. This script allows for non Turing complete smart contracts. The script are made of opcodes and each opcodes does something, such as checking if a signature is valid.



The scripting language have several operation knows as OP_NOPX where X is a number that do nothing. These opcodes can be repurposed to add new feature to bitcoin. This is how

OP_CHECKLOCKTIMEVERIFY was a repruposing of OP_NOP2 . Old nodes do nothing when encountering this opcode, while newer nodes will check that the lock time is what's expected.



The way opcodes are repuposed as soft fork today imposes some limitations on what these new opcodes can do. They cannot modify the stack, cannot produce result, and can only conditionally fail to validate a transaction.



Upgrading via soft fork has the problem that old nodes are fooled into thinking they do validate the blockchain when they actually can't. In addition, soft forks imposes design constraint on how things can be done, and lead to accumulating technical debt. On the other hand, hard fork imposes everybody to upgrade at once, and older nodes cannot validate either as they can't make sense of the blockchain and/or transactions they receive. Both situation aren't ideal.



I propose to define all the remaining OP_NOPs as "extension point". An extension point is something that is agreed upon up front that it will be used to add new feature to the protocol. Once OP_NOPs are defined to be extension point, the protocol can be extended by assigning a specific feature to this extension point.



New node, which supports the feature can accept and validate transactions using it. On the other hand, old nodes who see the usage of an extension point they do not know about will know that a feature they do not understand triggered on the network. At this point, they have various options:

- They can chose to treat these extension point as a soft fork and skip the script signature if the script uses the extension point.

- They can chose to wait for AD blocks and see if the use of the extension point is accepted by the network at large. If so, they proceed by skipping signature checks for these specific transactions.

- They can chose to not follow the chain and wait for an operator to upgrade, which is threating the extension point as a hard fork.



If extension points are tied to the AD parameter, then all 3 behaviors can be achieved by choosing an appropriate value for AD.



In short, current nodes have 2 state for the validity of the chain: valid or invalid. Using extension point, you get 3: valid, invalid, and "something I do not understand happened". As for soft forks, old nodes can still operate on the network with reduced security, however, contrary to soft forks, these nodes KNOW they are operating under reduced security condition and aren't fooled into think they still validate. In addition, nodes can refuse to accept the new feature if they so wish.



I hope that makes things clearer.