MIME-Version: 1.0
In-Reply-To: <20150728084312.GA29453@amethyst.visucore.com>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
	<20150728084312.GA29453@amethyst.visucore.com>
Date: Tue, 28 Jul 2015 12:09:22 +0200
Message-ID: <CABm2gDo-ziQLpDiFbmkYjMcsFJ2EVXe1hMOjm0gXQiRxp-K78Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin
 Core and hard forks)
Precedence: list

On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan
<laanwj@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Tim=C3=B3n via bitcoin-de=
v wrote:
>> But I thought you also wanted Bitcoin Core to use libconsensus instead
>> of just having a subtree/subrepository like it currently does with
>> libsecp256k1.
>> I'm not sure if that would ever be accepted, but in any case we're
>> certainly far away from that goal. Here are some things that need to
>> happen first:
>
> I don't see any reason why Bitcoin Core would not use the consensus libra=
ry. Eating our own dogfood and such.

As explained to Eric, it's not that I don't want Bitcoin Core to use
future-libconsensu through the API instead of a subtree: it's just
that that's more long-term and more work. And I don't see why other
implementations should really care about it.

> Biggest risk, as I've said before, is that the refactoring loading to a (=
more complete) consensus library will result in code that is no longer bug-=
for-bug compatible with previous versions, thus defeating its entire purpos=
e and introducing fork risk.
>
> If that can be avoided - for example by going from here to there using pu=
re code moves, as you're trying to do - I'm all for it.

Well, pure movements will not be enough, parameters will have to
change, incompatible dependencies have to be removed (ie util.h which
contains globals), etc.
But yes, I think we can do it with only low-risk and easy-to-review commits=
.

>> 3) Move libconsensus to a separate repository as a
>> subtree/subrepository of Bitcoin Core.
>
> If the rest is done, this is the easy part :)

And still, this doesn't require Bitcoin Core to use the API, a subtree
is enough at first.
This "easy step" doesn't guarantee that Bitcoin Core is using
future-libconsensus' API.

> Code review capacity is still our greatest bottleneck.
> And I don't see any way out of that, unfortunately.

I really think these code separations help with this (ie there are
many more people in the world with enough knowledge to review the qt
or even policy parts than there's people able to review consensus
changes).

> I do really care about this.

I know and I said so.