MIME-Version: 1.0
In-Reply-To: <CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
	<55B723EA.7010700@voskuil.org>
	<CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
	<55B939CF.1080903@voskuil.org>
	<CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
Date: Thu, 20 Aug 2015 02:53:45 +0200
Message-ID: <CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@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] Libconsensus separated repository (was Bitcoin
	Core and hard forks)
Precedence: list

Moving it here from the other thread.

On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil <eric@voskuil.org> 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?