Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-09 📝 Original message:Before I scare anyone ...
📅 Original date posted:2015-10-09
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151009/474dbc5d/attachment-0001.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151009/474dbc5d/attachment-0001.html>;