Message-ID: <5696D410.7080609@voskuil.org>
Date: Wed, 13 Jan 2016 14:47:44 -0800
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: <CABm2gDqPrsuHH4L+dQE-6e162Zj6jbyyB1-6htjB_+2EY2qTXg@mail.gmail.com>	<56955140.7050301@voskuil.org>
	<CABm2gDqz8NyZE_juwfqb23Hg5kZUU5oJuXHH098aU+_W8dPhBA@mail.gmail.com>
In-Reply-To: <CABm2gDqz8NyZE_juwfqb23Hg5kZUU5oJuXHH098aU+_W8dPhBA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="Fk6htccKXvd6uChEcuVsO8PBrW4pX5XNj"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Libconsensus phase 2
Precedence: list

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 <eric@voskuil.org> 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--