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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C04D2A7F
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Jan 2016 22:47:36 +0000 (UTC)
Received: by mail-pa0-f46.google.com with SMTP id yy13so272825852pab.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <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"
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 <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 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 <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--
|
