* [bitcoin-dev] Fw: Making soft forks pluggable
@ 2015-10-09 7:39 Eric Lombrozo
0 siblings, 0 replies; only message in thread
From: Eric Lombrozo @ 2015-10-09 7:39 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]
I wanted to clarify that this goal is for AFTER the next release in case
that didn't come across. The point is just to ascertain interest and
start thinking ahead. VersionBits can be fully ready to go well before
then and is well underway.
------ Forwarded Message ------
From: "Eric Lombrozo" <elombrozo@gmail•com>
To: "bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org>
Sent: 10/8/2015 8:58:12 PM
Subject: Making soft forks pluggable
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: 4600 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-10-09 7:40 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-09 7:39 [bitcoin-dev] Fw: Making soft forks pluggable Eric Lombrozo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox