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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4FD283D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 20:07:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA21914C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 20:07:26 +0000 (UTC)
Received: by igui7 with SMTP id i7so25646493igu.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 13:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=VP7AI/+n3Eln6NA6Z1B6Yr+EE9hAqfUHrDzhh716ElA=;
b=qZQm4Lnh2HZnIQkEsM+x0BsXPyXRWuKzkbKdyBIt6Kt64Wi1VCWPBRcZ7QdWJRCvdq
hP8/Xd395+TCu+XrkogbSUo3Td2gZt87tcUltuDIR72U7tTFCefFjJQeZW8hlVApB//F
X5n+XQslNiInhjSDxobNC60fjnG4bScgI4A8/hV3Zq73iR5u2eWM0m7S7Y1jwOuAkFdB
uKrOFTyWcz5JPdrxLt6JJ3WMt2xHnObe05UFzhjEApVPAZRv6u+QWUbtqfF0mq54U7yv
YdjfKRZdzFfAEZ7BcUCMpVdaS4Q6TyP55s30XlVXafW4s7TShfQGeDx2mV/JcEehCTKL
etyw==
X-Received: by 10.50.73.168 with SMTP id m8mr4187799igv.25.1440187646244; Fri,
21 Aug 2015 13:07:26 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
<55B723EA.7010700@voskuil.org>
<CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
<55B939CF.1080903@voskuil.org>
<CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
<CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
<C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
<CABm2gDqkF20ZoexQSV8iORb3ukxxZr5RasTLxJqQfSTsTqHvog@mail.gmail.com>
<3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com>
<CABm2gDpcEmiPNQWeUk5aTjuTSRAJSPYfgAKc7B_qrqw0w04xoA@mail.gmail.com>
In-Reply-To: <CABm2gDpcEmiPNQWeUk5aTjuTSRAJSPYfgAKc7B_qrqw0w04xoA@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Fri, 21 Aug 2015 20:07:15 +0000
Message-ID: <CABr1YTfKFzdJ5DuWrb_ua+s16Px9sgSrdLcYxAjEDujnbiy76Q@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>,
Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/alternative; boundary=089e013a239c107c38051dd7d1bc
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no 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 separated repository (was Bitcoin
Core and hard forks)
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: Fri, 21 Aug 2015 20:07:27 -0000
--089e013a239c107c38051dd7d1bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Unfortunately we have no way of rigorously proving functional equivalence
other than code review and unit testing. The simpler the consensus code
(and the more we can write it in a style that affords provability of
correctness) the easier it will be in the future to compare implementations=
.
Prior to swapping out implementations, we should at the least run it
through the gauntlet and perhaps run both implementations side-by-side.
All I/O should be treated abstractly in the API.
In C++ I really like using a nearly bare-bones signal template for most
async message handling, i.e.
https://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h
This greatly facilitates support for async bidirectional I/O, etc...with
minimal overhead.
But others might have other stylistic preferences.
- Eric
On Fri, Aug 21, 2015, 12:46 PM Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas@bitsofproof.com>
> wrote:
> > Every re-implementation, re-factoring even copy-paste introduces a risk
> of disagreement,
> > but also open the chance of doing the work better, in the sense of
> software engineering.
>
> But you don't want something better, you want something functionally
> identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=3D764
>
> >> On Aug 20, 2015, at 10:06, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> >>
> >>
> >> But the goal is not reimplementing the consensus rules but rather
> >> extract them from Bitcoin Core so that nobody needs to re-implement
> >> them again.
> >
> >
> >
> > My goal is different. Compatibility with Bitcoin is important as I also
> want to deal with Bitcoins,
> > but it is also imperative to be able to create and serve other block
> chains with other rules and for those
> > I do not want to carry on the legacy of an antique tool set and a
> spaghetti style.
> >
> > Bits of Proof uses scala (akka networking), java (api service), c++
> (leveledb and now libconsensus)
> > and I am eager to integrate secp256k1 (c) as soon as part of consensus.
> The choices were
> > made because each piece appears best in what they do.
>
> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e013a239c107c38051dd7d1bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Unfortunately we have no way of rigorously proving functiona=
l equivalence other than code review and unit testing. The simpler the cons=
ensus code (and the more we can write it in a style that affords provabilit=
y of correctness) the easier it will be in the future to compare implementa=
tions.</p>
<p dir=3D"ltr">Prior to swapping out implementations, we should at the leas=
t run it through the gauntlet and perhaps run both implementations side-by-=
side.</p>
<p dir=3D"ltr">All I/O should be treated abstractly in the API. </p>
<p dir=3D"ltr">In C++ I really like using a nearly bare-bones signal templa=
te for most async message handling, i.e. <a href=3D"https://github.com/ciph=
rex/mSIGNA/blob/master/deps/Signals/src/Signals.h">https://github.com/ciphr=
ex/mSIGNA/blob/master/deps/Signals/src/Signals.h</a></p>
<p dir=3D"ltr">This greatly facilitates support for async bidirectional I/O=
, etc...with minimal overhead.</p>
<p dir=3D"ltr">But others might have other stylistic preferences.</p>
<p dir=3D"ltr">- Eric<br>
</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 21, 2015, 12:46=
PM=C2=A0Jorge Tim=C3=B3n <<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blumm=
er <<a href=3D"mailto:tamas@bitsofproof.com" target=3D"_blank">tamas@bit=
sofproof.com</a>> wrote:<br>
> Every re-implementation, re-factoring even copy-paste introduces a ris=
k of disagreement,<br>
> but also open the chance of doing the work better, in the sense of sof=
tware engineering.<br>
<br>
But you don't want something better, you want something functionally id=
entical.<br>
You may want to watch sipa's explanation on why "the implementatio=
n is<br>
the specification" and the reasons to separate libconsensus:<br>
<a href=3D"https://youtu.be/l3O4nh79CUU?t=3D764" rel=3D"noreferrer" target=
=3D"_blank">https://youtu.be/l3O4nh79CUU?t=3D764</a><br>
<br>
>> On Aug 20, 2015, at 10:06, Jorge Tim=C3=B3n <jtimon@jtimon.cc&g=
t; wrote:<br>
>><br>
>><br>
>> But the goal is not reimplementing the consensus rules but rather<=
br>
>> extract them from Bitcoin Core so that nobody needs to re-implemen=
t<br>
>> them again.<br>
><br>
><br>
><br>
> My goal is different. Compatibility with Bitcoin is important as I als=
o want to deal with Bitcoins,<br>
> but it is also imperative to be able to create and serve other block c=
hains with other rules and for those<br>
> I do not want to carry on the legacy of an antique tool set and a spag=
hetti style.<br>
><br>
> Bits of Proof uses scala (akka networking), java (api service), c++ (l=
eveledb and now libconsensus)<br>
> and I am eager to integrate secp256k1 (c) as soon as part of consensus=
. The choices were<br>
> made because each piece appears best in what they do.<br>
<br>
Since you already depend on libconsensus for VerifyScript, wouldn't it<=
br>
be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?<br>
You would still have complete control over storage, concurrency,<br>
networking, policy...<br>
My plan is for the C API to interface with the external storage by<br>
passing a function pointer to it.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e013a239c107c38051dd7d1bc--
|
