From: "Eric Lombrozo" <elombrozo@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 09 Oct 2015 03:58:12 +0000
Message-Id: <em9172c2aa-5388-48dc-9d68-b942bdd936e3@platinum>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94"
Subject: [bitcoin-dev] Making soft forks pluggable
Precedence: list


--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Before I scare anyone away, please here me out:

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

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

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

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

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


- Eric
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>
<DIV>Before I scare anyone away, please here me out:</DIV>
<DIV>&nbsp;</DIV>
<DIV>It occurs to me it wouldn't be all that difficult to support the abili=
ty 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&nbsp;on regtest).</DIV>
<DIV>&nbsp;</DIV>
<DIV>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 docum=
ented to&nbsp;make backports fairly simple.</DIV>
<DIV>&nbsp;</DIV>
<DIV>My biggest concern (other than&nbsp;being able to convince everyone=
 that&nbsp;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&nbsp;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)&nbsp;it=
 will take a very long time to deploy stuff. A significant motivation behin=
d VersionBits (BIP0009) is to make such deployments faster, so if we're =
already doing that perhaps we might as well take this initiative even furth=
er.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>If I'm very wrong, I am all ears to *sincere* objections.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Eric</DIV></BODY></HTML>
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94--