From: "Eric Lombrozo" <elombrozo@gmail•com>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Making soft forks pluggable
Date: Fri, 09 Oct 2015 03:58:12 +0000 [thread overview]
Message-ID: <em9172c2aa-5388-48dc-9d68-b942bdd936e3@platinum> (raw)
[-- 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 --]
reply other threads:[~2015-10-09 3:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=em9172c2aa-5388-48dc-9d68-b942bdd936e3@platinum \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox