public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Fw: Making soft forks pluggable
Date: Fri, 09 Oct 2015 07:39:59 +0000	[thread overview]
Message-ID: <em78f4e69c-a3ca-4fdd-9f5f-23aeb7e25358@platinum> (raw)

[-- 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 --]

                 reply	other threads:[~2015-10-09  7:40 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=em78f4e69c-a3ca-4fdd-9f5f-23aeb7e25358@platinum \
    --to=elombrozo@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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