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
|
Return-Path: <tamas@bitsofproof.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 84D9B68
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 07:14:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from wp059.webpack.hosteurope.de (wp059.webpack.hosteurope.de
[80.237.132.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FCBE13D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 07:14:16 +0000 (UTC)
Received: from [37.143.74.116] (helo=[192.168.2.15]); authenticated
by wp059.webpack.hosteurope.de running ExIM with esmtpsa
(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
id 1ZSK3B-0008PG-BZ; Thu, 20 Aug 2015 09:14:13 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
Date: Thu, 20 Aug 2015 09:14:11 +0200
Message-Id: <C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
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>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: Apple Mail (2.2102)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440054856;
c6d5fa2e;
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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 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: Thu, 20 Aug 2015 07:14:17 -0000
--Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF
Content-Type: multipart/alternative;
boundary="Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA"
--Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Jorge,
separating script engine into libconsensus was very helpful, since =
wrapped the piece of consensus
that would least likely to be captured exactly with an implementation =
from scratch. Thank you for your
effort there. Bits of Proof now uses its own or alternatively =
libconsensus for full validation.
I am sceptical however that a =E2=80=9Cfull=E2=80=9D consensus lib =
extracted from satoshi=E2=80=99s code is worth trying.
Not because it was impossible, but because the result would not be =
higher quality, if measured on agreement
with satoshi, than other re-implementations. It would actually be lower =
quality because of the antique tool set.
The rules outside script engine are simpler, therefore much easier to =
capture exactly. They are however
scattered around in the spaghetti and are often just a single if =
statement, also repeated elsewhere.
You would either have to very extensively refactor the code, that =
unlikely goes through as a PR, or
do what me and others did. Read satoshi code and rewrite the same. You =
have
a slight advantage of copy-paste small fragments, but I doubt the =
consensus relevant advantage of that.
Tamas Blummer
> On Aug 20, 2015, at 02:53, Jorge Tim=C3=B3n via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>=20
> 1) Finish the libconsensus separation in an independent branch on top
> of a given version, for example 0.11.
> 2) Separate a repository from that. Alternative implementations can
> start using a full libconsensus
> 3) Rebase that branch on top of bitcoin/master and start to PR small
> groups of commits. Once the whole branch has been merged, Bitcoin Core
> can replace the consensus folder with the libconsensus subtree, so
> that Bitcoin Core itself can start using a full libconsensus.
>=20
> Ironically with this plan Bitcoin Core may not be the full node first
> implementation to use a full libconsensus.
> There will be some consensus fork bug risks during 3 (which at the
> current speed I estimate it could easily take 3 or 4 years) and there
> would be some redundant work (replicating every consensus change in
> both Bitcoin Core and libconsensus).
> On the bright side, we may be able to have a full libconsensus this
> year (which was my goal after we exposed VerifyScript in the first
> libconsensus).
>=20
> Thoughts?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">Jorge,</div><div class=3D""><br =
class=3D""></div><div class=3D"">separating script engine into =
libconsensus was very helpful, since wrapped the piece of =
consensus</div><div class=3D"">that would least likely to be captured =
exactly with an implementation from scratch. Thank you for =
your</div><div class=3D"">effort there. Bits of Proof now uses its =
own or alternatively libconsensus for full validation.</div><div =
class=3D""><br class=3D""></div><div class=3D"">I am sceptical however =
that a =E2=80=9Cfull=E2=80=9D consensus lib extracted from satoshi=E2=80=99=
s code is worth trying. </div><div class=3D"">Not because it was =
impossible, but because the result would not be higher quality, if =
measured on agreement</div><div class=3D"">with satoshi, than other =
re-implementations. It would actually be lower quality because of the =
antique tool set.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The rules outside script engine are simpler, therefore much =
easier to capture exactly. They are however </div><div =
class=3D"">scattered around in the spaghetti and are often just a single =
if statement, also repeated elsewhere.</div><div class=3D""><br =
class=3D""></div><div class=3D"">You would either have to very =
extensively refactor the code, that unlikely goes through as a PR, =
or</div><div class=3D"">do what me and others did. Read satoshi code and =
rewrite the same. You have </div><div class=3D"">a slight advantage =
of copy-paste small fragments, but I doubt the consensus relevant =
advantage of that.</div><div class=3D""><br class=3D""></div><div =
apple-content-edited=3D"true" class=3D"">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D"">Tamas Blummer</div><div style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><br =
class=3D""></div></div><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Aug 20, 2015, at 02:53, Jorge Tim=C3=B3n via bitcoin-dev =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><br class=3D"">1) =
Finish the libconsensus separation in an independent branch on top<br =
class=3D"">of a given version, for example 0.11.<br class=3D"">2) =
Separate a repository from that. Alternative implementations can<br =
class=3D"">start using a full libconsensus<br class=3D"">3) Rebase that =
branch on top of bitcoin/master and start to PR small<br class=3D"">groups=
of commits. Once the whole branch has been merged, Bitcoin Core<br =
class=3D"">can replace the consensus folder with the libconsensus =
subtree, so<br class=3D"">that Bitcoin Core itself can start using a =
full libconsensus.<br class=3D""><br class=3D"">Ironically with this =
plan Bitcoin Core may not be the full node first<br =
class=3D"">implementation to use a full libconsensus.<br class=3D"">There =
will be some consensus fork bug risks during 3 (which at the<br =
class=3D"">current speed I estimate it could easily take 3 or 4 years) =
and there<br class=3D"">would be some redundant work (replicating every =
consensus change in<br class=3D"">both Bitcoin Core and =
libconsensus).<br class=3D"">On the bright side, we may be able to have =
a full libconsensus this<br class=3D"">year (which was my goal after we =
exposed VerifyScript in the first<br class=3D"">libconsensus).<br =
class=3D""><br class=3D"">Thoughts?<br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_CBC7B358-3364-4D7C-B79C-EF348AA6D2AA--
--Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJV1X5EAAoJEPZykcUXcTkc+VcIALmj+HHHJl1xED999/LCEB8W
+P7bA/nuBWbPLwps44Ai2fpn1QMjBJadDTq3PGlBW9RtB6ijKr2vmvleKdvfteI6
YZdWIykccqeuqluQgQidFyHXwj4IQrECbt8/ELRO6VoLkv2V36vhceJBdpWPCaZc
C93q+OsTch64TRXypAtI7Rh0K0w+bN+beExLsarzvAQ8HqQA3zZqK/332w1ELu3p
7oz/C/Od82S/pP6nZVWuQ1cAVExxN0IXs4lVAvYfTAAX7y3ktHUG+f7Mey7/LgNM
U59Pm51UyMSPmUe0gPPpC//lq8PEAtLu/u4tlxBrfQ1PvYtz2WPfY1r0/ydYhPM=
=D0EJ
-----END PGP SIGNATURE-----
--Apple-Mail=_AF6D2BB3-3AF5-48B4-9A48-9D5B783E17FF--
|
