From: "Jorge Timón" <jtimon@jtimon•cc>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Libbitcoin <libbitcoin@lists•dyne.org>
Subject: Re: [bitcoin-dev] Libconsensus phase 2
Date: Wed, 13 Jan 2016 09:37:46 +0100 [thread overview]
Message-ID: <CABm2gDqz8NyZE_juwfqb23Hg5kZUU5oJuXHH098aU+_W8dPhBA@mail.gmail.com> (raw)
In-Reply-To: <56955140.7050301@voskuil.org>
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?
next prev parent reply other threads:[~2016-01-13 8:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 17:53 Jorge Timón
2016-01-12 19:17 ` Eric Voskuil
2016-01-13 8:37 ` Jorge Timón [this message]
2016-01-13 22:47 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABm2gDqz8NyZE_juwfqb23Hg5kZUU5oJuXHH098aU+_W8dPhBA@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
--cc=libbitcoin@lists$(echo .)dyne.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox