path: root/6f/77e336d1e1a135c87c08eb5fce6f42dfc9725b

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B02A514
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 20:38:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com
	[209.85.220.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65AB9254
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 20:38:21 +0000 (UTC)
Received: by pacan13 with SMTP id an13so11280429pac.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 13:38:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type;
	bh=nOBT3l4mofwOWXJwmRUmzwHP/o1AyP+iAgKUVYS2ibQ=;
	b=bEE/TkNIaFVMvNHBrgEknHsVbZNEU8qXwSpIj6Ql31dyuVxJhPK+TomFQKUVssGy3z
	dnUxAStNSG2VMM29DMv6DFOzF7Uz+8dDXh5O21wTAkW3D7yIMrowhhn1nIbPFQF+Whd5
	TeZNOTf6QHxqcDgo3/cx1gPPpDssn7eNFpgSGloaVadw1zvsSX3vDJWJ6ctjntGCGvP3
	pMr/XaihggHbZIPPKcecubrD9Tfoa1VSGdgfHY5ONXdIYSmbMf/ecbQMSoJuAcCTcyYl
	eCH59zKYbGDFSYe2nQR36wQAiAmhnIJAt1nx/5uwL9Muz8m9f43g9x1AxBPNrIsWTLLi
	cefQ==
X-Gm-Message-State: ALoCoQnBeNdgP2bsBs2WnhRJozMlNOi4QDcQwtvCK7pbQISIexCr/YKKV050cLX5XZFyBbp49aVu
X-Received: by 10.66.155.36 with SMTP id vt4mr99038135pab.32.1438202301087;
	Wed, 29 Jul 2015 13:38:21 -0700 (PDT)
Received: from [10.0.1.14] (c-67-161-88-20.hsd1.wa.comcast.net. [67.161.88.20])
	by smtp.googlemail.com with ESMTPSA id
	bu10sm42572157pac.36.2015.07.29.13.38.20
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 29 Jul 2015 13:38:20 -0700 (PDT)
Message-ID: <55B939CF.1080903@voskuil.org>
Date: Wed, 29 Jul 2015 13:38:39 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>	<55B723EA.7010700@voskuil.org>
	<CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
In-Reply-To: <CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="OHdoGccOdf1eKJkPQvXSVLdVJN0gquOgc"
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin
 Core and hard forks)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 20:38:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OHdoGccOdf1eKJkPQvXSVLdVJN0gquOgc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07/28/2015 02:58 AM, Jorge Tim=C3=B3n wrote:
>> I haven't looked at any of these commits, but I'll make some time to a=
t
>> least give a cursory review.
>=20
> 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 libconsensu=
s
>>> 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.
>=20
> 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 t=
he
>> idea that there can be only one legitimate implementation that's
>> problematic.
>=20
> 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=3D769
> 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.
>=20
> 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.

=2E..
>> Always willing to work with you on it, although we're all busy, and th=
is
>> isn't my top priority presently.
>=20
> 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




--OHdoGccOdf1eKJkPQvXSVLdVJN0gquOgc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVuTnPAAoJEDzYwH8LXOFOB0MH/1Niap+cWujCgvFHQlbMyWDE
Btdub3YPy+QOsqwA7KJ7nLtqgvMUuJG1KUOw8yGr7UKRft/ikcrPOURm9ZcgDyxS
UOES6bny4s9SLL8wH8+NUqmIV7HgCgcAPtS2vJTn9bS2hte1EFD6o8HBAZHi7PrL
BlXmFyyX8/AWccpo0SpzyKsfDagiqQW6HGr5kzPBo7yOZewzaGl0pX7ZM+q7hfnd
9jQJPPy2I9lWQL6LW5sG8ImZKbjEcRIQmdsq/BMI5GUb6mcFzSxUzlNmGqhJmIau
Xor0k90MIl8484mLWgspmWY8dcoQT2+mWny26MsIIHmnorfTvGHOqDq/T1U3djM=
=M7XS
-----END PGP SIGNATURE-----

--OHdoGccOdf1eKJkPQvXSVLdVJN0gquOgc--