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 D142F8D7 for ; Thu, 20 Aug 2015 00:53:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88E0F153 for ; Thu, 20 Aug 2015 00:53:47 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so14070926lbb.1 for ; Wed, 19 Aug 2015 17:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mCAQUyjmqoqBaK4xOQMEdFqdJSltSFcJbHUnGv8lwOk=; b=bF0ujfOYc5Qidh5TkwPvmzMjRbuE9ucx4ppA1FJfsldVGkmZr/4hCmGBI4FyI9Dj+6 JMTJFmhrb5dkJwNr7uyUtb4H1punA/USd1egYUg+ovw1v9EtqyWSs0joTS6L5XDJLx2K 4qFT3K3phtJMstQMlGZB5QUdRPuyq0XR2QefeRr1BwD3VftEi+OIvLZXG+bmuFAHfhXQ nvtY3dCaZNGdSBws2kaBD75uqWubbxSX5XO66RJyGdbSgfnEEmETgWadU5cIbc+ei324 Z2JQyllS8/MTIso/y7jxQp+UtCHCv0poFt97hpr7UQmMwHxUpRDXSzXVlq3NtW6eXRon YEEw== X-Gm-Message-State: ALoCoQnbTyZ6bz3Ci6lPdjG8JeMIxgE6cqbCytvhyg6mzcx8a+Bh+10nBCdjuCRRvnfMQgaWfN99 MIME-Version: 1.0 X-Received: by 10.152.37.196 with SMTP id a4mr351735lak.59.1440032025498; Wed, 19 Aug 2015 17:53:45 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 17:53:45 -0700 (PDT) In-Reply-To: References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> Date: Thu, 20 Aug 2015 02:53:45 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Eric Voskuil Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: Bitcoin Dev , Libbitcoin Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks) 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: Thu, 20 Aug 2015 00:53:48 -0000 Moving it here from the other thread. On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil wrote: > On 08/19/2015 04:27 PM, Jorge Tim=C3=B3n wrote: >> No, as previously explained, once libconsensus is complete it can be >> moved to a separate repository like libsecp256k1. > > I don't see this happening any time soon, and I'm not sure why we should > wait for it. Yes, unfortunately I don't see this happening any time soon either, at least not with the amount of review I'm getting. My initial hope was to complete libconsensus by 0.12 (one year should be enough time, right?) but I was being too optimistic. By "wait for it" I assume you mean waiting for libconsensus to be complete before we separate it to a different repository. The reason is just simplicity. >>> In our discussion leading up to libbitcoin building libbitcoin-consensu= s >>> we disagreed on whether intentional hard forks would (or even could) >>> happen. I think that issue is now settled. So my question remains how d= o >>> stakeholders (users/miners) maintain consensus when it's their >>> individual intent (the first objective of libconsensus), and diverge >>> when intended (which a direct dependency on libconsensus makes harder)? >>> IMO it's unreasonable to operate as if this won't happen, given that it= has. >> >> I believe the simplest option... > > You might consider this as feedback from your customer base. Mhmm, not sure I understand this point. >> would be to fork the libconsensus >> project and do the schism/controversial/contentious hardfork there. >> But of course modifying libconsensus will be much easier than >> modifying Bitcoin Core (if anything, because the amount of code is >> much smaller). > > That's a false dichotomy. We never would have considered forking Bitcoin > Core, and still wouldn't. Why would we set ourselves up for this > disruption, which would inevitably lead to us factoring the consensus > portions of libconsensus out of /bitcoin at the 11th hour? > > We have to operate as if it can happen at any time. Otherwise we have > relinquished control of this vote and failed our users. Given that > operating assumption, it is much safer for us to have already done this > work (which we did). [It also provides a forcing function for us to > review in detail any consensus changes that get pushed out.] Yes, you need to operate as if it can happen at any time. I now understandbetter your position of having your own repository until a complete libconsensus is separated. In the meantime you will have to keep using your re-implementation of the rest of the consensus rules (besides the script checks), but fortunately the most risky and harder reimplementation is the part of the script validation. > My question is why you would not embrace an independent consensus > repository? Your work to evolve it doesn't change. Yes, I want a separated repository. I just wanted to start with a separated folder first. Right now there's consensus code all over the place, specially in main.cpp. I think changing the order (separated repository first, moving code from Bitcoin Core to libconsensus later) would increase the total amount of work. Here's another option that has recently crossed my mind: 1) Finish the libconsensus separation in an independent branch on top of a given version, for example 0.11. 2) Separate a repository from that. Alternative implementations can start using a full libconsensus 3) Rebase that branch on top of bitcoin/master and start to PR small groups of commits. Once the whole branch has been merged, Bitcoin Core can replace the consensus folder with the libconsensus subtree, so that Bitcoin Core itself can start using a full libconsensus. Ironically with this plan Bitcoin Core may not be the full node first implementation to use a full libconsensus. There will be some consensus fork bug risks during 3 (which at the current speed I estimate it could easily take 3 or 4 years) and there would be some redundant work (replicating every consensus change in both Bitcoin Core and libconsensus). On the bright side, we may be able to have a full libconsensus this year (which was my goal after we exposed VerifyScript in the first libconsensus). Thoughts?