summaryrefslogtreecommitdiff
path: root/21/2e16413e541838a83a644b143d67d4cbca13b0
blob: e6845eeb7d6ca27400b44340f8bab4fbbd922fb9 (plain)
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
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
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 33BE874
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 06:42:26 +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 7D8D0E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 06:42:24 +0000 (UTC)
Received: from [37.143.74.116] (helo=[192.168.2.11]); authenticated
	by wp059.webpack.hosteurope.de running ExIM with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	id 1ZTOyw-0002b4-SK; Sun, 23 Aug 2015 08:42:18 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_17BEBBF6-E660-4298-A3A0-1309321DE788";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
Date: Sun, 23 Aug 2015 08:42:17 +0200
Message-Id: <22CF03CB-7A4B-44D9-8989-22798795BB16@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>
	<CABm2gDpcEmiPNQWeUk5aTjuTSRAJSPYfgAKc7B_qrqw0w04xoA@mail.gmail.com>
	<C486E9D9-D799-48B9-B80F-1A165DFD6536@bitsofproof.com>
	<CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440312144;
	7eb00295; 
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 <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: Sun, 23 Aug 2015 06:42:26 -0000


--Apple-Mail=_17BEBBF6-E660-4298-A3A0-1309321DE788
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B72C70AC-BB6F-472F-83AF-BB1FEAC4B96B"


--Apple-Mail=_B72C70AC-BB6F-472F-83AF-BB1FEAC4B96B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I see the huge amount of sweat and love that went into core and it =
actually hurts to see that most is expended in friction and lack of a =
vision for the software architecture.

To be concrete, this was my plan if dealing with the Core code base:

1) I'd consider the separation of networking and storage as suggested =
for a future extended libconsensus low priority, as their design should =
be (are) dominated by the need of the consensus logic only.

2) create an API to the consensus+networking+storage service that is not =
at the C++ language level but some scaleable cross-platform remoting, =
like eg. ZeroMQ.
This API should be minimal and simple, assuming that one fully trusts =
the node answering it. This API would unlock user land development by =
distinct teams with diverse technologies.

3) move the wallet, QT and RPC and other backward compatibility stuff =
(if e.g. there is some mining support) in-top of the new API and into =
distinct source code repositories.


Tamas Blummer

> On Aug 23, 2015, at 03:23, Eric Lombrozo <elombrozo@gmail.com> wrote:
>=20
> I've been pushing for greater modularization since I first got into =
bitcoin. I got quickly frustrated when I was only able to get through =
very few things (i.e. moving core structure serialization classes to a =
separate unit not called main). Working on Bitcoin has an added layer of =
frustration that goes beyond most open source projects: even though =
we're clearly in userland working at the application layer, a good =
layered protocol design is still lacking. We have no standards process =
separate from what basically amount to updates to one specific reference =
implementation. And we all need to agree on any major change, since a =
blockchain that is easily forked in contentious ways pretty much defeats =
its own purpose.
>=20
> I went off to develop my own stack, where I could more easily avoid =
politics and focus on engineering. But I now understand the politics are =
inevitable. Bitcoin is inherently a cooperative project. Several people =
have poured themselves passionately into the reference codebase, most of =
whom did it (at least initially) purely as unpaid volunteers. There's a =
lot of love that's gone into this. But it's become pretty clear that the =
modularization is no longer merely a matter of good engineering - it is =
essential to resolving serious political challenges.
>=20
> Perhaps the most frustrating thing of all is watching people pushing =
for relatively superficial yet highly controversial changes while we =
still lack the proper infrastructure to handle these kinds of =
divergences of opinion without either stagnating or becoming polarized.
>=20
> I could continue working to reimplement an entire stack from scratch, =
as several others have also done - but besides the serious effort =
duplication this entails, it doesn't really seem like it will ultimately =
be a convergent process. It's too easy to let ego and habit dictate =
one's preferences rather than rational engineering considerations.
>=20
> I know that some might feel I'm just preaching to the choir, but we =
should probably take a step back from implementation hackery and try to =
specify some core protocol layers, focusing on interfaces. Specifically, =
we need a consensus layer that doesn't try to specify networking, =
storage, wallets, UI, etc. Let different people improve upon these =
things independently in their own implementations. What matters is that =
we all converge on a common history and state. At the same time, let's =
open up more competition on all these other things that are separate =
from the consensus layer.
>=20
> If only we were to dedicate a fraction of the effort we've put into =
this whole block size circus into what's actually important...and I =
blame myself as well...
>=20
>=20
> On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> On Aug 21, 2015, at 21:46, Jorge Tim=C3=B3n <jtimon@jtimon.cc =
<mailto:jtimon@jtimon.cc>> wrote:
>>=20
>> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer =
<tamas@bitsofproof.com <mailto: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.
>>=20
>> 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 =
<https://youtu.be/l3O4nh79CUU?t=3D764>
>=20
> I do want something better, but not for the focus you have.
>=20
> Not because what you produce was not high quality, but because quality =
is achieved at a very
> high cost and is hard to uphold over generations of developer. You =
focus on a single use case
> while there are many out there for distributed ledgers.
>=20
> I think in an infrastructure for enterprise applications, building =
consensus on the ledger is a
> cornerstone there, but is only a piece of the solution. I built =
several commercially successful
> deployments where I delegated the consensus building to a border =
router, a Bitcoin Core,
> then interfaced that trusted peer with my  implementation that =
accepted Core=E2=80=99s decisions
> in an SPV manner. One might think of this setup as wasteful and =
unsuitable for =E2=80=9Csmall devices=E2=80=9D
> therefore an example of centralization people here try to avoid.
>=20
> Enterprises have sufficient resources. Solving the business problem is =
valuable to them even at
> magnitudes higher cost than a hobbyist would bear.
>=20
> For mainstream adoption you need to get enterprises on board too, and  =
that is what I care of.
> Enterprises want code that is not only high quality, but is easy to =
maintain with a development
> team with high attrition. One has to take whatever help is offered for =
that, and one is modern
> languages and runtimes.
>=20
> Bits of Proof=E2=80=99s own implementation of the scripts was not =
practically relevant in my commercially
> successful deployments, because of the use of a border router, but it =
helped development,
> enabling easier debug and precise error feedback esp. end even after =
Core had a reject message.
>=20
> I integrated libconsensus only for the hope that is significantly =
fastens application side tx verification,
>  which it has turned out it does not, until secp265k1 is integrated.
>=20
> I would likely use an other extended libconsensus too, but do not =
think there was a dependency on
> that for enterprise development.
>=20
> It would help there more to have a slim protocol server, no wallet, no =
rpc, no qt but a high
> performance remoting API.
>=20
>> 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.
>=20
>=20
> Storage and validation is non-trivially interconnected, but I now the =
separation can be done,
> since I did it.
>=20
> Excuse me, but function pointers is a pattern I used in the 80=E2=80=99s=
. I know that they are behind
> the curtain of modern abstractions with similar use, I still prefer =
not to see them again.
>=20
> Tamas Blummer
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>


--Apple-Mail=_B72C70AC-BB6F-472F-83AF-BB1FEAC4B96B
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"">I see the huge amount of sweat and love that went into core =
and it actually hurts to see that most is expended in friction and lack =
of a vision for the software architecture.<div class=3D""><br =
class=3D""></div><div class=3D"">To be concrete, this was my plan if =
dealing with the Core code base:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1) I'd consider the separation of =
networking and storage as suggested for a future extended libconsensus =
low priority, as their design should be (are) dominated by the need of =
the consensus logic only.</div><div class=3D""><br class=3D""></div><div =
class=3D"">2) create an API to the consensus+networking+storage service =
that is not at the C++ language level but some scaleable cross-platform =
remoting, like eg. ZeroMQ.&nbsp;</div><div class=3D"">This API should be =
minimal and simple, assuming that one fully trusts the node answering =
it. This API would unlock user land development by distinct teams with =
diverse technologies.</div><div class=3D""><br class=3D""></div><div =
class=3D"">3) move the wallet, QT and RPC and other backward =
compatibility stuff (if e.g. there is some mining support) in-top of the =
new API and into distinct source code repositories.&nbsp;</div><div =
class=3D""><br class=3D""></div><div class=3D""><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""><br class=3D""></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"">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 23, 2015, at 03:23, Eric Lombrozo =
&lt;<a href=3D"mailto:elombrozo@gmail.com" =
class=3D"">elombrozo@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><p dir=3D"ltr" =
class=3D"">I've been pushing for greater modularization since I first =
got into bitcoin. I got quickly frustrated when I was only able to get =
through very few things (i.e. moving core structure serialization =
classes to a separate unit not called main). Working on Bitcoin has an =
added layer of frustration that goes beyond most open source projects: =
even though we're clearly in userland working at the application layer, =
a good layered protocol design is still lacking. We have no standards =
process separate from what basically amount to updates to one specific =
reference implementation. And we all need to agree on any major change, =
since a blockchain that is easily forked in contentious ways pretty much =
defeats its own purpose.</p><p dir=3D"ltr" class=3D"">I went off to =
develop my own stack, where I could more easily avoid politics and focus =
on engineering. But I now understand the politics are inevitable. =
Bitcoin is inherently a cooperative project. Several people have poured =
themselves passionately into the reference codebase, most of whom did it =
(at least initially) purely as unpaid volunteers. There's a lot of love =
that's gone into this. But it's become pretty clear that the =
modularization is no longer merely a matter of good engineering - it is =
essential to resolving serious political challenges.</p><p dir=3D"ltr" =
class=3D"">Perhaps the most frustrating thing of all is watching people =
pushing for relatively superficial yet highly controversial changes =
while we still lack the proper infrastructure to handle these kinds of =
divergences of opinion without either stagnating or becoming =
polarized.</p><p dir=3D"ltr" class=3D"">I could continue working to =
reimplement an entire stack from scratch, as several others have also =
done - but besides the serious effort duplication this entails, it =
doesn't really seem like it will ultimately be a convergent process. =
It's too easy to let ego and habit dictate one's preferences rather than =
rational engineering considerations. </p><p dir=3D"ltr" class=3D"">I =
know that some might feel I'm just preaching to the choir, but we should =
probably take a step back from implementation hackery and try to specify =
some core protocol layers, focusing on interfaces. Specifically, we need =
a consensus layer that doesn't try to specify networking, storage, =
wallets, UI, etc. Let different people improve upon these things =
independently in their own implementations. What matters is that we all =
converge on a common history and state. At the same time, let's open up =
more competition on all these other things that are separate from the =
consensus layer.</p><p dir=3D"ltr" class=3D"">If only we were to =
dedicate a fraction of the effort we've put into this whole block size =
circus into what's actually important...and I blame myself as well...<br =
class=3D""></p>
<br class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On =
Sat, Aug 22, 2015, 4:05 AM&nbsp;Tamas Blummer via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Aug 21, 2015, at 21:46, =
Jorge Tim=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank"=
 class=3D"">jtimon@jtimon.cc</a>&gt; wrote:</div><br class=3D""><div =
class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">On Thu, Aug =
20, 2015 at 10:35 AM, Tamas Blummer &lt;</span><a =
href=3D"mailto:tamas@bitsofproof.com" =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" target=3D"_blank" class=3D"">tamas@bitsofproof.com</a><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">&gt; =
wrote:</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><blockquote type=3D"cite" =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" 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""></blockquote><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">But you don't =
want something better, you want something functionally =
identical.</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">You may want =
to watch sipa's explanation on why "the implementation is</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">the =
specification" and the reasons to separate libconsensus:</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><a href=3D"https://youtu.be/l3O4nh79CUU?t=3D764" =
target=3D"_blank" class=3D"">https://youtu.be/l3O4nh79CUU?t=3D764</a><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""></div></blockquote><div class=3D""><br =
class=3D""></div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D"">I do want something better, =
but not for the focus you have.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">Not because what you produce was not =
high quality, but because quality is achieved at a very</div><div =
class=3D"">high cost and is hard to uphold over generations of =
developer. You focus on a single use case</div><div class=3D"">while =
there are many out there for distributed ledgers.</div><div class=3D""><br=
 class=3D""></div><div class=3D"">I think in an infrastructure for =
enterprise applications, building consensus on the ledger is =
a&nbsp;</div><div class=3D"">cornerstone there, but is only a piece of =
the solution. I built several commercially successful</div><div =
class=3D"">deployments where I delegated the consensus building to a =
border router, a Bitcoin Core,&nbsp;</div><div class=3D"">then =
interfaced that trusted peer with my &nbsp;implementation that accepted =
Core=E2=80=99s decisions&nbsp;</div><div class=3D"">in an SPV manner. =
One might think of this setup as wasteful and unsuitable for =E2=80=9Csmal=
l devices=E2=80=9D</div><div class=3D"">therefore an example of =
centralization people here try to avoid.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Enterprises have sufficient resources. =
Solving the business problem is valuable to them even at&nbsp;</div><div =
class=3D"">magnitudes higher cost than a hobbyist would bear.</div><div =
class=3D""><br class=3D""></div><div class=3D"">For mainstream adoption =
you need to get enterprises on board too, and &nbsp;that is what I care =
of.&nbsp;</div><div class=3D"">Enterprises want code that is not only =
high quality, but is easy to maintain with a development&nbsp;</div><div =
class=3D"">team with high attrition. One has to take whatever help is =
offered for that, and one is modern&nbsp;</div><div class=3D"">languages =
and runtimes.</div><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D"">Bits of Proof=E2=80=99s own implementation of =
the scripts was not practically relevant in my commercially</div><div =
class=3D"">successful deployments, because of the use of a border =
router, but it helped development,&nbsp;</div><div class=3D"">enabling =
easier debug and precise error feedback esp. end even after Core had a =
reject message.&nbsp;</div></div><div class=3D""><br class=3D""></div><div=
 class=3D"">I integrated libconsensus only for the hope that is =
significantly fastens application side tx verification,</div><div =
class=3D"">&nbsp;which it has turned out it does not, until secp265k1 is =
integrated.</div><div class=3D""><br class=3D""></div><div class=3D"">I =
would likely use an other extended libconsensus too, but do not think =
there was a dependency on&nbsp;</div><div class=3D"">that for enterprise =
development.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">It would help there more to have a slim protocol server, no =
wallet, no rpc, no qt but a high&nbsp;</div><div class=3D"">performance =
remoting API.</div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D""><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">Since you =
already depend on libconsensus for VerifyScript, wouldn't it</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">be nice that =
it also offered VerifyTx, VerifyHeader and VerifyBlock?</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">You would =
still have complete control over storage, concurrency,</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">networking, =
policy...</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">My plan is =
for the C API to interface with the external storage by</span><br =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px" class=3D""><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important" class=3D"">passing a =
function pointer to it.</span></div></blockquote></div></div><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">Storage and validation =
is non-trivially interconnected, but I now the separation can be =
done,</div><div class=3D"">since I did it.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">Excuse me, but function pointers is a =
pattern I used in the 80=E2=80=99s. I know that they are =
behind&nbsp;</div><div class=3D"">the curtain of modern abstractions =
with similar use, I still prefer not to see them again.</div></div><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><br =
class=3D""></div><div class=3D""><div class=3D""><div class=3D"">Tamas =
Blummer</div><div class=3D""><br class=3D""></div></div><div =
class=3D""><blockquote type=3D"cite" =
class=3D""></blockquote></div></div></div>________________________________=
_______________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
 class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</blockquote></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_B72C70AC-BB6F-472F-83AF-BB1FEAC4B96B--

--Apple-Mail=_17BEBBF6-E660-4298-A3A0-1309321DE788
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

iQEcBAEBCgAGBQJV2WtKAAoJEPZykcUXcTkc5WcIAJCySmxF3G2DiiZ4OegkX0Fs
ONIkmP9+l/+jPcAeZ1CdbZvXajAnMpAIlNdM+B/qK44vU8T4PCIFZNGgNOX0F1Fx
d2opKN+K+ILfGVhsbE4Tb55C9ExqYdlIinEXAaYVrZRda4zZfHqeO+oQ378zFYwX
c2PXOHVqbK76Qzmua5BmN63mq+dpm+DALpSi+aTOP2f5Y4xCViQPZjO0E6UL1WPd
qR+s9AIWYDLBcGAYPymC7zIWjFbwuNnRgdxhKLoZnfHOdWI4YnKosEj4ey/N0mJg
24oYb48zG3p4jemY0qh7CewZpFz1qS0PDJry1hr2cEEOIemdgK4YC8coi4T0D1w=
=3sUq
-----END PGP SIGNATURE-----

--Apple-Mail=_17BEBBF6-E660-4298-A3A0-1309321DE788--