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 0680D11D7 for ; Fri, 9 Oct 2015 03:58:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8729416D for ; Fri, 9 Oct 2015 03:58:17 +0000 (UTC) Received: by pacex6 with SMTP id ex6so73986583pac.0 for ; Thu, 08 Oct 2015 20:58:17 -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=GXTbJ1sWyOTeFKQ49ZyPixjbh6wwb+VkoMDvaeeXMMY=; b=VzxSUXkR16ZLMour4SfSflJyDHlbBqIafAhDVs9warC3NM3gXWgA24TgWxKng7phAp taWx2hbae2BpZtsopilaUfb/5r9iO4z1mXGEnOftFSVJY6C2suThPxAMxkEvJxfnwikt 6yYWAx685KDBTWE0haLVsIPUlGLI5QjJwbkDXqaZA1gNQ6E3vfDhIQOQcZm5XNSvLzy4 +WCrAEycqPSreRvNOEsUcHeqabuv91Vm9hvlOTRlWTOKVzsjH54mbSiAcZSg0NhUgpcb Ad7VbNx4xAY774Yq4kzZMplbleZ2rl1bBuHVTSxnHuUVg1wA0bHgEpQLf7u82odlNpLd Lo1g== X-Received: by 10.66.66.166 with SMTP id g6mr7737428pat.152.1444363097281; Thu, 08 Oct 2015 20:58:17 -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 ze3sm10017290pac.5.2015.10.08.20.58.16 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Oct 2015 20:58:16 -0700 (PDT) From: "Eric Lombrozo" To: bitcoin-dev Date: Fri, 09 Oct 2015 03:58:12 +0000 Message-Id: Reply-To: "Eric Lombrozo" User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94" 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] 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 03:58:18 -0000 --------=_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
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
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94--