Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B02A514 for ; 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 ; Wed, 29 Jul 2015 20:38:21 +0000 (UTC) Received: by pacan13 with SMTP id an13so11280429pac.1 for ; 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 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?= References: <55B723EA.7010700@voskuil.org> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--