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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
|
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 0EC78826
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 21:26:25 +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 BD95619D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 21:26:23 +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 1ZSXLp-0001Nh-JK; Thu, 20 Aug 2015 23:26:21 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <55D611FC.6010305@mattcorallo.com>
Date: Thu, 20 Aug 2015 23:26:19 +0200
Message-Id: <9861CA5B-A13D-4CFB-9529-511F93E68A72@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>
<C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
<CABm2gDqkF20ZoexQSV8iORb3ukxxZr5RasTLxJqQfSTsTqHvog@mail.gmail.com>
<3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com>
<55D611FC.6010305@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: Apple Mail (2.2102)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440105983;
064818b8;
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.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 21:26:25 -0000
--Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5
Content-Type: multipart/alternative;
boundary="Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC"
--Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
I know what you mean as I already have such a component with pluggable =
block store and networking.
While you are at it you could aim for isolation of bitcoin specific =
decisions and algos from generic block chain code.
The magnitude of refactoring you would have to do to get there from =
main.cpp and the rest of the hairball
is harder than a re-write from scratch, and the result will not be =
impressive, just hopefully working.
I think a slim API server was a lower hanging fruit in Core=92s case.
BTW, support for refactoring is an example where you see if your tool =
set is modern.
Tamas Blummer
> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I dont think a libconsensus would have any kind of networking layer, =
nor
> is C++ an antique tool set (hopefully libconsensus can avoid a boost
> dependency, though thats not antique either). Ideally it would have a
> simple API to give it blocks and a simple API for it to inform you of
> what the current chain is. If you really want to get fancy maybe it =
has
> pluggable block storage, too, but I dont see why you couldnt use this =
in
> ~any client?
>=20
> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev 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.
>>=20
>>> On Aug 20, 2015, at 10:06, Jorge Tim=F3n <jtimon@jtimon.cc> wrote:
>>>=20
>>>=20
>>> 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.
>>=20
>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Tamas Blummer
>>=20
>>=20
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I know what you mean as I already have such a =
component with pluggable block store and networking.</div><div =
class=3D"">While you are at it you could aim for isolation of bitcoin =
specific decisions and algos from generic block chain =
code. </div><div class=3D""><br class=3D""></div><div class=3D"">The =
magnitude of refactoring you would have to do to get there from main.cpp =
and the rest of the hairball</div><div class=3D"">is harder than a =
re-write from scratch, and the result will not be impressive, just =
hopefully working.</div><div class=3D"">I think a slim API server was a =
lower hanging fruit in Core=92s case.</div><div class=3D""><br =
class=3D""></div><div class=3D"">BTW, support for refactoring is an =
example where you see if your tool set is modern.</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 19:44, Matt Corallo 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"">I dont think a =
libconsensus would have any kind of networking layer, nor<br class=3D"">is=
C++ an antique tool set (hopefully libconsensus can avoid a boost<br =
class=3D"">dependency, though thats not antique either). Ideally it =
would have a<br class=3D"">simple API to give it blocks and a simple API =
for it to inform you of<br class=3D"">what the current chain is. If you =
really want to get fancy maybe it has<br class=3D"">pluggable block =
storage, too, but I dont see why you couldnt use this in<br =
class=3D"">~any client?<br class=3D""><br class=3D"">On 08/20/15 08:35, =
Tamas Blummer via bitcoin-dev wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D"">Every re-implementation, re-factoring even =
copy-paste introduces a risk of disagreement,<br class=3D"">but also =
open the chance of doing the work better, in the sense of software =
engineering.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">On Aug 20, 2015, at 10:06, Jorge Tim=F3n <<a =
href=3D"mailto:jtimon@jtimon.cc" class=3D"">jtimon@jtimon.cc</a>> =
wrote:<br class=3D""><br class=3D""><br class=3D"">But the goal is not =
reimplementing the consensus rules but rather<br class=3D"">extract them =
from Bitcoin Core so that nobody needs to re-implement<br class=3D"">them =
again.<br class=3D""></blockquote><br class=3D""><br class=3D""><br =
class=3D"">My goal is different. Compatibility with Bitcoin is important =
as I also want to deal with Bitcoins,<br class=3D"">but it is also =
imperative to be able to create and serve other block chains with other =
rules and for those<br class=3D"">I do not want to carry on the legacy =
of an antique tool set and a spaghetti style.<br class=3D""><br =
class=3D"">Bits of Proof uses scala (akka networking), java (api =
service), c++ (leveledb and now libconsensus)<br class=3D"">and I am =
eager to integrate secp256k1 (c) as soon as part of consensus. The =
choices were<br class=3D"">made because each piece appears best in what =
they do.<br class=3D""><br class=3D"">Tamas Blummer<br class=3D""><br =
class=3D""><br class=3D""><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""><br =
class=3D""></blockquote>_______________________________________________<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""><br class=3D""></div></blockquote></div><br =
class=3D""></body></html>=
--Apple-Mail=_8749E4FB-6C14-4E9D-9175-56691217DCCC--
--Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5
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
iQEcBAEBCgAGBQJV1kX8AAoJEPZykcUXcTkcr5EH/2U0oDgzCzCLeRSp5x1T73/t
b+JFxl/Ae7cNoS+6voi2PV6gJROj7DIVsnrzfpfS5Ktv8tC1BAW/OHxKoXHfq2rM
9wNnBy2KcMyZx55BpwWZ9cwzjMgRCe6ot+mXQW/ynWjwkrYScAZIu0aofEZFgkjv
fiW0BSoQrxeEI7n8sbPujky2Bx2/FGM4yymW8K+ycLn/z1pWGV6TTlvzx/D5buHi
HYXivA1585T2WizqLb535XcwJne7MEyrhH3jSaewbRcYcsuhvpym17Vvd6nySrBu
ZsV9TmtOgoLRKHy7PsMxPCkdgyUk4T5kaA/1q1LY3RNVrjILi17WNdM2+4a1+J8=
=aGDB
-----END PGP SIGNATURE-----
--Apple-Mail=_407FE1A1-EB42-4EBB-B0AD-E89A96BF57C5--
|
