Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 96A9E19EC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Oct 2015 07:40:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com
	[209.85.220.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16E6B138
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Oct 2015 07:40:04 +0000 (UTC)
Received: by pablk4 with SMTP id lk4so79392369pab.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 09 Oct 2015 00:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
	:content-type; bh=MV09GQDSjOOKAhVlgtx1q/ZUY1hKYKciY827e1Ugm3Q=;
	b=HB0tcQfLYX5TtVpnnnvkJ6ewrFe3Es9Y55Q+PpXWMYm2hrtSc7OGZR/0zDPL4DCdW7
	bKhEMswFgfzB0uMmLo+klNv4JL4+T4K9Ka2PbUIbiW8oBXVLCNuL79bVGlc9g8inFt81
	4PCl44rxxydo40prk/mMu5TMYVrYEfjr9BVAtV+ZsQiKvr001XiPe7EJ26bDwDV4UPrB
	1day9KNyMHZ73CuPM+Y2hMtzAePvOrWXVjBwp8G3A7j6lehzMUDxdwjg0bm+1DLqcg/t
	NNLiAqTnX+Uz3kmV0JXJEBy7Jy+pl0iYvtga8LQcKLV+aUqOIXnQ2ysmp4GAJ09gzTFZ
	Zegw==
X-Received: by 10.68.241.234 with SMTP id wl10mr13610114pbc.27.1444376403737; 
	Fri, 09 Oct 2015 00:40:03 -0700 (PDT)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by smtp.gmail.com with ESMTPSA id ol3sm530838pbb.49.2015.10.09.00.40.02
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Fri, 09 Oct 2015 00:40:03 -0700 (PDT)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 09 Oct 2015 07:39:59 +0000
Message-Id: <em78f4e69c-a3ca-4fdd-9f5f-23aeb7e25358@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="------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Fw: Making soft forks pluggable
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 07:40:04 -0000


--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I wanted to clarify that this goal is for AFTER the next release in case=
=20
that didn't come across. The point is just to ascertain interest and=20
start thinking ahead. VersionBits can be fully ready to go well before=20
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=
=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
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68
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>

<STYLE>#xeae4b2a51df74b2094b4c61376a0809b BLOCKQUOTE.cite
{PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccccc 1px solid; PADD=
ING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b BLOCKQUOTE.cite2
{PADDING-TOP: 0px; PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccc=
cc 1px solid; MARGIN-TOP: 3px; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b .plain PRE, #xeae4b2a51df74b2094b4c61376=
a0809b .plain TT
{FONT-SIZE: 100%; FONT-FAMILY: monospace; WHITE-SPACE: pre-wrap; FONT-WEIGH=
T: normal; FONT-STYLE: normal}
#xeae4b2a51df74b2094b4c61376a0809b A IMG
{BORDER-TOP: 0px; BORDER-RIGHT: 0px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b .plain PRE, #xeae4b2a51df74b2094b4c61376=
a0809b .plain TT, #xeae4b2a51df74b2094b4c61376a0809b
{FONT-SIZE: 12pt; FONT-FAMILY: Tahoma}
</STYLE>
</HEAD>
<BODY scroll=3Dauto class>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>------ Forwarded Message ------</DIV>
<DIV>From: "Eric Lombrozo" &lt;<A href=3D"mailto:elombrozo@gmail.com">elomb=
rozo@gmail.com</A>&gt;</DIV>
<DIV>To: "bitcoin-dev" &lt;<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt;</DIV>
<DIV>Sent: 10/8/2015 8:58:12 PM</DIV>
<DIV>Subject: Making soft forks pluggable</DIV>
<DIV>&nbsp;</DIV>
<DIV id=3Dxeae4b2a51df74b2094b4c61376a0809b>
<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></DIV></BODY></HTML>
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68--