Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1: Type: text/plain, Size: 6156 bytes --]

On 07/28/2015 02:58 AM, Jorge Timón wrote:
>> I haven't looked at any of these commits, but I'll make some time to at
>> least give a cursory review.
> 
> Great. I mean, I wasn't asking about reviewing the commits themselves
> (which is also great if you do), but rather on answering the questions
> I'm making there, ie: what to expose next (ie VerifyTx or
> VerifyHeader)?

Oh, I misunderstood your ask then. I don't have a preference on
prioritizing VerifyTx vs VerifyHeader.

> would this be an acceptable way to expose
> VerifyHeader?

I'm not sure how you mean to expose it, could you clarify?

> Which of he step-checks functions is worth exposing too (Bitcoin
> Core is currently using some to prevent DoS attacks, for example)?

I don't see any reason to expose checkpoints in this library. They are
trivial to implement and are not part of consensus.

>>> Would you agree that asking people to fork an independent libconsensus
>>> project instead of having to fork the full Bitcoin-qt is much more
>>> reasonable?
>>
>> Yes, of course. We've already done it. For each release of the satoshi
>> client since we made libbitcoin-consensus I've copied the sources. It's
>> pretty much automated and easy to visually verify that the sources
>> match. That would be quite a bit more difficult if there wasn't an
>> independent build.
> 
> Well, neither libbitcoincosnensus nor libbitcoin-consensus implements
> all the consensus rules.
> That's what makes them different from future-libconsensus.
> But great, we're confirming more views that we share.

Nothing can eliminate all consensus risk, not even a common full node
implementation.

>> Useful specifications often have two reference implementations. It's the
>> idea that there can be only one legitimate implementation that's
>> problematic.
> 
> Well, this is where I fear we will never agree. I think "Bitcoin is
> different" in this reward and you disagree.
> Maybe Pieter's explanation is more convincing to you:
> https://youtu.be/PxW5D9xCIsc?t=769
> Otherwise, I think I'll stop trying convincing you.

Maybe I wasn't sufficiently explicit. It is problematic. That is the
core issue we are dealing with. That doesn't mean I disagree with the
objectives of an independent community consensus library.

The premise of the "one true library" idea is that there is *no way* to
sufficiently test for consensus bugs in any software release. That of
course means that each release of the satoshi client poses a significant
risk to the network. This risk is presently greater than that posed by
other implementations simply because of adoption. That is the basis of
the red herring argument:

https://blog.conformal.com/the-bitcoin-consensus-red-herring

The bottom line is that nobody has control over this process. There are,
and will always be, a multitude of consensus implementations that intend
to target the same coin. Presently there are multiple versions of the
satoshi client, and this has produced forks, and will continue to do so.

Isolating the satoshi consensus checks to an independent library serves
not to eliminate that risk, but can reduce it somewhat. Importantly it
will allow various implementations to overcome a perception problem,
which will improve implementation diversity and developer participation.

>>> I believe that's the only point where we fundamentally disagree, but
>>> it shouldn't be a barrier in our common goal of taking "power" away
>>> from Bitcoin Core development. If we're successful Bitcoin Core won't
>>> have any privileged position with regards to, say, libbitcoin when it
>>> comes to deciding consensus rules changes.
>>
>> I don't think we disagree on anything fundamental. My issues with the
>> library were (1) the lack of isolation, (2) the fact that the satoshi
>> client wouldn't actually use the library, and (3) backtracking to use
>> OpenSSL, which we had recently removed from libbitcoin.
> 
> 1) Working on it

For the sake of clarity, this is now a non-issue for us.

> 2) The Satoshi client has been using all along and it will use it
> forever (maybe not through the API, but I don't get what the problem
> with that is).

Again, I consider this a requirement for us to link directly to it as a
library. If the sources are isolated into an independent repo, but the
satoshi client is embedding its own copies, one must continue to diff
the client sources against the library sources. We are doing this
already, so the benefit to having the independent repo is in no longer
having to do this.

There are also differences in the build system that can affect outcome.
Comparing those differences across repos can be more challenging. For
this reason I consider it important to your objective that the satoshi
client actually use the library - as I assume it will at some point.

If the satoshi client folks are to maintain a consensus library for the
community it's also important to show a commitment to its independence.
Dogfooding is of course a software engineering best practice. But there
is also the cynical perspective - the independent library in some ways
works against an advantage of the satoshi client.

I personally don't think the committers are parochial enough to let this
become an issue. We are all after something bigger. But if there was
push-back against using the library it would be a red flag. So until
that point passes I would just maintain our independent library, cloning
the sources from the satoshi client.

> 3) There will be an announce about this soon.

Yes, I've seen this as a temporary setback.

...
>> Always willing to work with you on it, although we're all busy, and this
>> isn't my top priority presently.
> 
> Is it because "fear of consensus bugs is what keeps people on the
> satoshi client" and you want to keep things this way?

No, I see it as less significant to the adoption of libbitcoin-server
than other issues we are working on, especially given the existence of
libbitcoin-consensus. I also trust you will make progress regardless.

e




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]