[bitcoin-dev] Making soft forks pluggable

["Eric Lombrozo" <elombrozo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

Before I scare anyone away, please here me out:

It occurs to me it wouldn't be all that difficult to support the ability 
to define soft forks entirely as standalone units that can be trivially 
merged with Bitcoin Core. It would require a few changes in some places 
in the consensus code, but at least for a very wide class of potential 
soft forks, all cases could be covered via only a small number of hooks, 
primarily in main.cpp, consensus/*, script/interpreter.cpp, and 
primitives/*. (Other hooks could be added in non-consensus code such as 
rpcblockchain.cpp or the wallet). It would be possible to build unit 
tests for each soft fork independently and compare enforcement of 
different combinations (as well as simulate these deployment 
combinations on regtest).

Before I get too heavily invested in this idea, though, I'd like to see 
if there are any reasonable objections to such a thing. Of course, 
refactors are generally disruptive in the short-term...but I think what 
I'm talking about can be done without having to move very large chunks 
of code around, with very specifically defined hooks that can be easily 
documented to make backports fairly simple.

My biggest concern (other than being able to convince everyone that we 
won't break anything, which of course I'd have to do a good job of in 
terms of rigor) is whether supporting this feature is a good idea in the 
first place. There's something to be said for it not being *too* easy to 
write and deploy a soft fork...however, unless we open this up a little 
more and make such deployments more routine (and safe) it will take a 
very long time to deploy stuff. A significant motivation behind 
VersionBits (BIP0009) is to make such deployments faster, so if we're 
already doing that perhaps we might as well take this initiative even 
further.

If others think this is a good idea I'll start writing up a detailed 
plan. (NOTE: The current versionbits deployment plan does not require 
this. I am working on an implementation of versionbits that could 
potentially support this plan but doesn't have to.)

If I'm very wrong, I am all ears to *sincere* objections.


- Eric

[-- Attachment #2: Type: text/html, Size: 3004 bytes --]