MIME-Version: 1.0
In-Reply-To: <56955140.7050301@voskuil.org>
References: <CABm2gDqPrsuHH4L+dQE-6e162Zj6jbyyB1-6htjB_+2EY2qTXg@mail.gmail.com>
	<56955140.7050301@voskuil.org>
Date: Wed, 13 Jan 2016 09:37:46 +0100
Message-ID: <CABm2gDqz8NyZE_juwfqb23Hg5kZUU5oJuXHH098aU+_W8dPhBA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Libconsensus phase 2
Precedence: list

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, how
> will you isolate the database dependency from consensus critical code?
> Is it that the interface will exist but you will recommend against its use?

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/1717db89c6db17ea65ddbd5eb19034315db0b059/src/consensus/storage_interfaces_cpp.h

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/2bcc07c014e5dd000030e666be047dfa11f54c10/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).
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.

> 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.

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).

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.

Does that make sense?