MIME-Version: 1.0
In-Reply-To: <55D50C15.9020402@voskuil.org>
References: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>
	<CADJgMzv+cKPY9wrAzbk5pgQJS0=R9KWu-+EuppM=nmXs8RHxYg@mail.gmail.com>
	<20150819182010.GB12306@muck>
	<CADJgMzskK9iNoRzVr0BtK+XH-x2w5mGZtBiieQpwcGevnHRjGg@mail.gmail.com>
	<55D4D9C3.5070004@riseup.net>
	<C47D37EE-AE42-4175-AD6B-F6FD0841287B@gmail.com>
	<CABm2gDpAOQim63Q7r9r-Pv-K+FqizgDHNUmQ7uheGMuMt-e2QA@mail.gmail.com>
	<E3D72CF4-3D1C-4235-87F9-A035AFF28C27@gmail.com>
	<CABm2gDrefdHeYWF2y_o7A9NxRssC=ddHqY--ExxLv00TS4ShKQ@mail.gmail.com>
	<55D50C15.9020402@voskuil.org>
Date: Thu, 20 Aug 2015 01:27:51 +0200
Message-ID: <CABm2gDpzAL9Rci8m60ruhHeDXx3gvGgPHMbupZKUZA1wys-AiQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
Precedence: list

On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric@voskuil.org> 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 <elombrozo@gmail.com> 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.