1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC93CAD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Jan 2016 08:37:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com
[209.85.213.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E520D137
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Jan 2016 08:37:47 +0000 (UTC)
Received: by mail-vk0-f50.google.com with SMTP id k1so257501533vkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Jan 2016 00:37:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=2YviUrguNL+sz3IVBVqqIp1yKQ536nNesEkKGwjfAJE=;
b=jbF9nEkHa+W1j2zCr1rPTUXcZ8PsuFA9wVs3jx487dTQtIHMJ3dyLhxe+anZrCGc0d
tPsijR4QzpRoTWVwOv1rntd396PWpGtyO1QG4I+5wHk2fL7K08eQ1nrQ8xJDhFFaM/bG
knDv50jJ0uov4FFGsb62Ebz3yNCqOOYPy6BMJDVB95Js5SJWR5J4zPdVEUwoSPlof7q5
citNFXC0dWmX3dbQ4f9gASBSzmulE1M5c9V7nHq1bUF3Ufaw2MMlOufjcPS7K3/rr6QV
KcmAwTdNL7MiJkvDxJicFzoIewN7w19ETxmxvOl8geGtshmBjoD0QpDr4CJcvOPg13zx
p+2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=2YviUrguNL+sz3IVBVqqIp1yKQ536nNesEkKGwjfAJE=;
b=P2cyb7o5rwVMVj70zGiGQTLucfJL3/MtvFlQNc/meePQtgU/U12rhgznJQmUTSSWJh
xlkr4aOH4ge1Deh8S0HHOYCobE3lHI++UWdfAjLNhgOWxNROplkryB6rtFBiWzibXpE3
K1q6IOYTlRIIdgl3goKMzxSZw5fa5RSmpu8llpQr1m6uzftVu/tRTDJw6oXoRsaoU32i
tLf6iOnPnURd1NJhrxNM/g46yGDFJM8ouhj3GBRhAwHZotsan4V9ABnkO3fCudvfm6x8
lIgbfe/cAs2ChKkeHctModMo1pC7Iqr0ujeHnsYfBdDM/4hPMrARt/H9t7XE/hM/V9L8
9pww==
X-Gm-Message-State: ALoCoQlcyUnEkMuzw9o0qoo45eLiXGY6ZMULkNdVE82pxrLDFxmhuvsFcFLfsczo7FyQbUo9x6WcmSFwXil9Ji9I/ob174GHTQ==
MIME-Version: 1.0
X-Received: by 10.31.154.213 with SMTP id c204mr96318708vke.38.1452674266688;
Wed, 13 Jan 2016 00:37:46 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Wed, 13 Jan 2016 00:37:46 -0800 (PST)
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
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Libbitcoin <libbitcoin@lists.dyne.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2016 08:37:48 -0000
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?
|
