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> </DIV> <DIV>------ Forwarded Message ------</DIV> <DIV>From: "Eric Lombrozo" <<A href=3D"mailto:elombrozo@gmail.com">elomb= rozo@gmail.com</A>></DIV> <DIV>To: "bitcoin-dev" <<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat= ion.org">bitcoin-dev@lists.linuxfoundation.org</A>></DIV> <DIV>Sent: 10/8/2015 8:58:12 PM</DIV> <DIV>Subject: Making soft forks pluggable</DIV> <DIV> </DIV> <DIV id=3Dxeae4b2a51df74b2094b4c61376a0809b> <DIV>Before I scare anyone away, please here me out:</DIV> <DIV> </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 on regtest).</DIV> <DIV> </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 make backports fairly simple.</DIV> <DIV> </DIV> <DIV>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 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> </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> </DIV> <DIV>If I'm very wrong, I am all ears to *sincere* objections.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>- Eric</DIV></DIV></BODY></HTML> --------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68--