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 6E1BC955 for ; Wed, 19 Aug 2015 23:27:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 770B889 for ; Wed, 19 Aug 2015 23:27:53 +0000 (UTC) Received: by lbbsx3 with SMTP id sx3so13194645lbb.0 for ; Wed, 19 Aug 2015 16:27:52 -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=HD5QH4TG++Z3pc9/YBye9VvGt8SV+oZeVLV8gpcjZuU=; b=evBGBo0CR9bsigTI2Yn1OVLhqvif4yZDOFYkXvNfUCZVgpgEx0iQNLa4ozuMk7HUzk 5YOT8csj099ptx0AQQ2RjH5VvayIBfJC0J7YtV7foT/ZKU73jND8X7Sddbu12bH5j2GA HuYMVGDp+yC65VmyUDV8hSrrePnlRDio1uMr2mYkMjTPJ9RSbtUGbIdGw9LJ7m+e4QID nzAzfpc92B1XYDWQmcllUP1qf9Aa4abkM5G2KLkc72AeuJuprfIzpRntrhx/sZchD57h Lls3quoMgzhcjOSASvpWAhti1uWbQu7KpDfCVQXLob0YjWp69pXqHsub9cmnlxcqqsiZ yRxw== X-Gm-Message-State: ALoCoQn79uxONrC1pOqIf/uwoJdwNLMXvetqo1SvLKJ/KDeYfYVxQHKqILwAU82hxkYCOYKI5p+I MIME-Version: 1.0 X-Received: by 10.152.21.196 with SMTP id x4mr46074lae.117.1440026871989; Wed, 19 Aug 2015 16:27:51 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 16:27:51 -0700 (PDT) In-Reply-To: <55D50C15.9020402@voskuil.org> References: <20150819182010.GB12306@muck> <55D4D9C3.5070004@riseup.net> <55D50C15.9020402@voskuil.org> Date: Thu, 20 Aug 2015 01:27:51 +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] Bitcoin XT Fork 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: Wed, 19 Aug 2015 23:27:54 -0000 On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil wrote: > [cross-posted to libbitcoin] > > On 08/19/2015 03:00 PM, Jorge Tim=C3=B3n via bitcoin-dev wrote:> On Wed, = Aug > 19, 2015 at 10:04 PM, Eric Lombrozo wrote: >>> But the consensus code should NOT be subject to the same commit > policies=E2=80=A6and we should make an effort to separate the two clearly= . And > we should find a way to communicate the difference succinctly and > clearly to laypeople (which is something I think the XT opponents have > been horrible at doing so far). >> >> I think that effort is in progress (again, much slower that I would >> like it to be) and it's called libconsensus. >> Once we have libconsensus Bitcoin Core it's just another >> implementation (even if it is the reference one) and it's not "the >> specification of the consensus rules" which is a "privileged" position >> that brings all sorts of misunderstandings and problems (the block >> size debate is just one example). > > Jorge, > > I applaud your efforts and objectives WRT libconsensus independence. But > as you know I differ with you on this point: > >> Once we have libconsensus Bitcoin Core it's just another >> implementation > > I do not consider Bitcoin Core just another implementation as long as > libconsensus is built directly out of the bitcoind repository. It's a > finer point, but an important one. Eric makes this point emphatically as > well: > >>> But the consensus code should NOT be subject to the same commit > policies...and we should make an effort to separate the two clearly. > > As you have implied, it's not likely to happen in the Bitcoin Core repo. > Taking a dependency on Bitcoin Core is a metaphorical deal with the > devil from our perspective. So my question is, how do you expect other > implementations to transition off of that repository (and commit > policies)? Or do you expect the dependency to be perpetual? No, as previously explained, once libconsensus is complete it can be moved to a separate repository like libsecp256k1. At first it will need to be a subtree/subrepository of Bitcoin Core (like libsecp256k1 currently is), but I still don't undesrtand how that can possibly be a problem for alternative implementations (they can use a subtree as well if they want to). Depending on a separated libconsensus doesn't "make Bitcoin Core a dependency" more than depending on libsecp256k1 currently does. > In our discussion leading up to libbitcoin building libbitcoin-consensus > we disagreed on whether intentional hard forks would (or even could) > happen. I think that issue is now settled. So my question remains how do > 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 h= as. I believe the simplest option 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). > There are a very small number of implementations that rely on consensus > (fewer that aren't also forks of Bitcoin Core). I think it's time we > discuss how to work together to achieve our mutual goal. I assume you > have been in contact with all of us. If you would like to facilitate > this I'd be happy to join in an offline discussion. Unfortunately I only directly contacted libbitcoin because I was subscribed to the list at the time (maybe I'm still subscribed, not really sure). The other attempts to get feedback from other alternative implementations have been just mostly-ignored threads in bitcoin-dev. So, no, I cannot facilitate such a discussion, but I'm more than happy to collaborate to achieve our mutual goal.