From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 96A9E19EC for ; 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 ; Fri, 9 Oct 2015 07:40:04 +0000 (UTC) Received: by pablk4 with SMTP id lk4so79392369pab.3 for ; 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 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Oct 2015 00:40:03 -0700 (PDT) From: "Eric Lombrozo" To: bitcoin-dev Date: Fri, 09 Oct 2015 07:39:59 +0000 Message-Id: Reply-To: "Eric Lombrozo" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "bitcoin-dev" 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
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" <elomb= rozo@gmail.com>
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 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).
 
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.
 
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.
 
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
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68--