From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C04D2A7F for ; Wed, 13 Jan 2016 22:47:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1AB6161 for ; Wed, 13 Jan 2016 22:47:36 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id yy13so272825852pab.3 for ; Wed, 13 Jan 2016 14:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Oahm2Apaaf7H7369rZJjnDyE9w8Cv/lG1/SauVgrLU4=; b=GydUXFxFs45HErIrj2hmsAKRWsJtcbVylosqI3rpOyfKPSs9osUkvnEBa3AYNvqavr pTUEYdQ0K/N3ILZ3zf45lQcgVy7paW88aaUEkV0dVXa8+RkrGF/rBxGEQ+cr4IjX399B /kr4HU3jmSgIcadh5kFtkE68m+QvGQewwkuLFY7BT/2WB4bW9Q+1j3PErNu4giWGQCIl h+vP3n8T2f46pB6DRxL2k4NRbaHbcFyTDnl3OfwR+eqfzhQHESkoKG5YYMbdpcV4S6zZ NgkZacbRzC4zttqmm4TBHB1PcextRvh41QO/4c8Q7eXR1DLdl2e7komGn7ldb0hEXlad AcVA== 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=Oahm2Apaaf7H7369rZJjnDyE9w8Cv/lG1/SauVgrLU4=; b=I1w32fDuHwtY2iZdMM5ENOOCarOoTySEnGJjOvrhzb4Tg6htWxwpXSU4N0nRgRBmh2 Lhxugt1wDJAZgAmymnC+Hg4pI0XVV0iSAZe+F+WJYkkPV/MIlUAFMGfJmwCRVZCmsGz2 hSSRqOSHj+sPabmb3Z2Vxa5KWkq+MXs17crzFdOZnd76X3Z+npwHtSafTgXG+kAITvJ2 W/CFEIgnryMLL0RTwfdem9/6xhbMuEG7NAbTQA2lmJPR50n6K4uEMz0e8QbMa/DQKZLt NpXXp+2otxnVr8sNNogEmxip/fUOH6dpRzkDbIxV5d6RKou+bQiJNtFFlvBN4xaUUAWa +H3A== X-Gm-Message-State: ALoCoQmyS8QfSgEx7t8DOtnD+Zei13JkPR5Js708W1S3v3Fx9P6sM0CXKBq3Jf1E8XHZmQHsQCrzOODqLzvb3shdqIJAam48/w== X-Received: by 10.66.236.103 with SMTP id ut7mr1051616pac.4.1452725256630; Wed, 13 Jan 2016 14:47:36 -0800 (PST) Received: from ?IPv6:2601:600:9001:8060:4ce9:d433:71e4:c369? ([2601:600:9001:8060:4ce9:d433:71e4:c369]) by smtp.googlemail.com with ESMTPSA id n5sm4925067pfi.3.2016.01.13.14.47.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 14:47:35 -0800 (PST) Message-ID: <5696D410.7080609@voskuil.org> Date: Wed, 13 Jan 2016 14:47:44 -0800 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: <56955140.7050301@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Fk6htccKXvd6uChEcuVsO8PBrW4pX5XNj" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Wed, 13 Jan 2016 23:03:00 +0000 Cc: Bitcoin Dev , Libbitcoin Subject: Re: [bitcoin-dev] Libconsensus phase 2 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, 13 Jan 2016 22:47:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fk6htccKXvd6uChEcuVsO8PBrW4pX5XNj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/13/2016 12:37 AM, Jorge Tim=C3=B3n wrote: > On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote:= >> Jorge, first, thanks again for your work on this. >> >> Without creating and using a public blockchain interface in phase 2, h= ow >> will you isolate the database dependency from consensus critical code?= >> Is it that the interface will exist but you will recommend against its= use? >=20 > The interface will exist but it will be a C++ interface that fits > better with Bitcoin Core internals. > See an initial draft of what could be the storage interface: > https://github.com/jtimon/bitcoin/blob/1717db89c6db17ea65ddbd5eb1903431= 5db0b059/src/consensus/storage_interfaces_cpp.h >=20 > Phase 3 will consist on discussing and refining that interface to also > define the C interfaces using structs of function pointers instead of > classes (see https://github.com/jtimon/bitcoin/blob/2bcc07c014e5dd00003= 0e666be047dfa11f54c10/src/consensus/interfaces.h > for an early draft) that is needed for the "final" C API. > But since I think there will be more discussion and work defining > those interfaces, I would rather start with ANY interface that allows > us to decouple the consensus code from chain.o and coins.o, which we > don't want to be built as part of the consensus building package > (which is used for building both libbitcoinconsensus and Bitcoin > Core). Okay. > Future potential users are more than welcomed to draft their own C > APIs and that experience should be useful for phase 3. > I was expecting you, for example, to include the whole consensus code > (even if it lacks a C API) in > https://github.com/libbitcoin/libbitcoin-consensus for better testing > of the equivalent code in libbitcoin. You are kind of taking the C API > part out already, so this time you will just have less things to > delete/ignore. Generalization of the store interface may be more challenging than you anticipate, but the objective makes sense. >> This work presumes that the users of the library reject the argument >> that the database implementation is consensus critical code. Faithful >> reproduction of stored data is a prerequisite for a validity. But a >> common store implementation is only slightly more reasonable for this >> library than a common RAM implementation. >=20 > This is a concern that has been risen repeatedly. > I am aware that faithful reproduction of the stored data is a > prerequisite for consensus validity. On the other hand, my presumption > is that a libbitcoinconsensus that forces its users to a given unifrom > storage will likely had much less users and any alternative > implementation that wants to implement its own custom storage would > have to necessarily reimplement the consensus validation code. > Doing it this way is more flexible. We can relatively easily implement > another library (if I remember correctly, last time we talked about it > we reffered to it as "libconsensus plus", but there's probably better > names) also takes care of storage for the users that don't want to > take the risks of reimplementing the storage (probably just using > Bitcoin Core's structures). >=20 > Unlike me, Luke Dashjr, for example, advocated for the > storage-dependent version, but I believe that implementing both > versions was an acceptable solution to him. > It is certainly an acceptable solution for me. I don't want to force > anyone that doesn't want or need to take the risks reimplementing the > consensus storage part to do so. But at the same time I really believe > that it would be a mistake to not allow it optionally. >=20 > Does that make sense? We would not offer libbitcoinconsensus integration if it required us to incorporate the store. These are distinct logical components, as are p2p networking and client-server networking (e.g. RPC), for example. I would not think of these as multiple versions of libbitcoinconsensus but instead as distinct components of a bitcoin node. It doesn't make sense to me that you would ship this as two consensus variants. I would work toward shipping independent component libraries (i.e. consensus and store= ). e --Fk6htccKXvd6uChEcuVsO8PBrW4pX5XNj 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 iQEcBAEBCAAGBQJWltQQAAoJEDzYwH8LXOFO/YoH/0rMtPVMb0BK3nB/9KNmsCge BuSKJpuo3Ay404h+pEJwNOmiSuU8o7MB66GDxkw+lOO9zvl8J69sPMzFI210dA0m J7arPS/l9hsePR7+vGN/Y3S7QyeN5mp/W7T0TKEIhyGYKaGesW+Y1UFTOJ9JX3cL bPtLaGXtwo28CJzzF+lsIWxU7NSnU0q+GTkr0164MqLXOXnFgvHd2mQetthei5lO c6+w3qGZTe0ieNHPSO14YaoybuUJ7/uRjqYYxYtgyU4abE2o2b3AH87qgMGHW+S+ zQIM69FKYJpYa9oiLQIqOrwUlGK9Bmy1nsKv8GlvDfS0uAFSQCncein/9xW9lZc= =NCPF -----END PGP SIGNATURE----- --Fk6htccKXvd6uChEcuVsO8PBrW4pX5XNj--