summaryrefslogtreecommitdiff
path: root/a9/50899e4dd1e998e8703ff1bb30fe575b26ce5e
blob: cc10cce8809e5b89380a6409c98dfe0ed94d60e8 (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
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 7B2ED87A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 01:23:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
	[209.85.213.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 304C8E8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 01:23:44 +0000 (UTC)
Received: by igfj19 with SMTP id j19so36123939igf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Aug 2015 18:23:43 -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=YRhIKPoVoSWqfzJT0yQyTEZndUne8zc9gzGO/OtMP5o=;
	b=KWeLDWwU2fSLChoe2DWU7qHa36vfygg7nue/5K62GwkDtlmV3g4cwdjOzQmFljrax8
	WYIddNPKwqfT+rYHBfu6iw7/oTrsGyLSQNIiYq7saKh8dqXMSz+3c+injJYlkdS25IVV
	WEX85hbN2ctquzlOizzTmT4dRuE5aVO8v02fQmTP46dKXNpGrLXJCzF8lYsZALcaOkrg
	XfQjGcT0DZszzxqv+z9Az6oo0NuC5Vm8P8GFujDXLWLv676tsWvOfXC4EUDubFKn0/Vb
	bHR1XyKLaYWCUtGIcvlxqE8iBtA/TEEdRnU3cXn7IGERX57UlJ9qGUQyisOAymyXExjz
	IzMA==
X-Received: by 10.50.62.46 with SMTP id v14mr9645116igr.79.1440293023593; Sat,
	22 Aug 2015 18:23:43 -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>
	<C486E9D9-D799-48B9-B80F-1A165DFD6536@bitsofproof.com>
In-Reply-To: <C486E9D9-D799-48B9-B80F-1A165DFD6536@bitsofproof.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sun, 23 Aug 2015 01:23:33 +0000
Message-ID: <CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
To: Tamas Blummer <tamas@bitsofproof.com>,
	=?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=047d7bd771220b3d48051df05aeb
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: Sun, 23 Aug 2015 01:23:45 -0000

--047d7bd771220b3d48051df05aeb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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.

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.

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.

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.

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...

On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Aug 21, 2015, at 21:46, Jorge Tim=C3=B3n <jtimon@jtimon.cc> 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 o=
f
> 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
>
>
> I do want something better, but not for the focus you have.
>
> 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.
>
> 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 unsuitabl=
e
> for =E2=80=9Csmall devices=E2=80=9D
> therefore an example of centralization people here try to avoid.
>
> Enterprises have sufficient resources. Solving the business problem is
> valuable to them even at
> magnitudes higher cost than a hobbyist would bear.
>
> 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.
>
> Bits of Proof=E2=80=99s own implementation of the scripts was not practic=
ally
> 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.
>
> 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.
>
> I would likely use an other extended libconsensus too, but do not think
> there was a dependency on
> that for enterprise development.
>
> It would help there more to have a slim protocol server, no wallet, no
> rpc, no qt but a high
> performance remoting API.
>
> 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.
>
>
> Storage and validation is non-trivially interconnected, but I now the
> separation can be done,
> since I did it.
>
> 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 t=
o
> see them again.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--047d7bd771220b3d48051df05aeb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I&#39;ve been pushing for greater modularization since I fir=
st got into bitcoin. I got quickly frustrated when I was only able to get t=
hrough 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&#39=
;re clearly in userland working at the application layer, a good layered pr=
otocol 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 ea=
sily forked in contentious ways pretty much defeats its own purpose.</p>
<p dir=3D"ltr">I went off to develop my own stack, where I could more easil=
y avoid politics and focus on engineering. But I now understand the politic=
s are inevitable. Bitcoin is inherently a cooperative project. Several peop=
le have poured themselves passionately into the reference codebase, most of=
 whom did it (at least initially) purely as unpaid volunteers. There&#39;s =
a lot of love that&#39;s gone into this. But it&#39;s become pretty clear t=
hat the modularization is no longer merely a matter of good engineering - i=
t is essential to resolving serious political challenges.</p>
<p dir=3D"ltr">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 divergence=
s of opinion without either stagnating or becoming polarized.</p>
<p dir=3D"ltr">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&#39;t really seem like it will ultimate=
ly be a convergent process. It&#39;s too easy to let ego and habit dictate =
one&#39;s preferences rather than rational engineering considerations. </p>
<p dir=3D"ltr">I know that some might feel I&#39;m just preaching to the ch=
oir, but we should probably take a step back from implementation hackery an=
d try to specify some core protocol layers, focusing on interfaces. Specifi=
cally, we need a consensus layer that doesn&#39;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 co=
nverge on a common history and state. At the same time, let&#39;s open up m=
ore competition on all these other things that are separate from the consen=
sus layer.</p>
<p dir=3D"ltr">If only we were to dedicate a fraction of the effort we&#39;=
ve put into this whole block size circus into what&#39;s actually important=
...and I blame myself as well...<br></p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 22, 2015, 4:05 =
AM=C2=A0Tamas Blummer via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><div><blockquote type=3D"cite"><div>On Aug 21, 2015, at 21:46, Jorge Tim=
=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jt=
imon.cc</a>&gt; wrote:</div><br><div><span style=3D"font-family:Helvetica;f=
ont-size:12px;font-style:normal;font-variant:normal;font-weight:normal;lett=
er-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px;float:none;display:inlin=
e!important">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-s=
ize:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-sp=
acing:normal;line-height:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px" target=3D"_blank">tamas@bits=
ofproof.com</a><span style=3D"font-family:Helvetica;font-size:12px;font-sty=
le:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line=
-height:normal;text-align:start;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px;float:none;display:inline!important">&gt; wrot=
e:</span><br style=3D"font-family:Helvetica;font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px"><blockquote type=3D"cite" style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px">Every re-implement=
ation, re-factoring even copy-paste introduces a risk of disagreement,<br>b=
ut also open the chance of doing the work better, in the sense of software =
engineering.<br></blockquote><br style=3D"font-family:Helvetica;font-size:1=
2px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing=
:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px"><span style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;float:none;display:=
inline!important">But you don&#39;t want something better, you want somethi=
ng functionally identical.</span><br style=3D"font-family:Helvetica;font-si=
ze:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"><span style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;disp=
lay:inline!important">You may want to watch sipa&#39;s explanation on why &=
quot;the implementation is</span><br style=3D"font-family:Helvetica;font-si=
ze:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"><span style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;disp=
lay:inline!important">the specification&quot; and the reasons to separate l=
ibconsensus:</span><br style=3D"font-family:Helvetica;font-size:12px;font-s=
tyle:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;li=
ne-height:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px"><a href=3D"https://youtu.be/l3O4nh79CUU?t=
=3D764" target=3D"_blank">https://youtu.be/l3O4nh79CUU?t=3D764</a><br style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px"></div></blockquote><div><br></div></div></div><div style=3D"word-wrap:b=
reak-word"><div><div>I do want something better, but not for the focus you =
have.=C2=A0</div><div><br></div><div>Not because what you produce was not h=
igh quality, but because quality is achieved at a very</div><div>high cost =
and is hard to uphold over generations of developer. You focus on a single =
use case</div><div>while there are many out there for distributed ledgers.<=
/div><div><br></div><div>I think in an infrastructure for enterprise applic=
ations, building consensus on the ledger is a=C2=A0</div><div>cornerstone t=
here, but is only a piece of the solution. I built several commercially suc=
cessful</div><div>deployments where I delegated the consensus building to a=
 border router, a Bitcoin Core,=C2=A0</div><div>then interfaced that truste=
d peer with my =C2=A0implementation that accepted Core=E2=80=99s decisions=
=C2=A0</div><div>in an SPV manner. One might think of this setup as wastefu=
l and unsuitable for =E2=80=9Csmall devices=E2=80=9D</div><div>therefore an=
 example of centralization people here try to avoid.</div><div><br></div><d=
iv>Enterprises have sufficient resources. Solving the business problem is v=
aluable to them even at=C2=A0</div><div>magnitudes higher cost than a hobby=
ist would bear.</div><div><br></div><div>For mainstream adoption you need t=
o get enterprises on board too, and =C2=A0that is what I care of.=C2=A0</di=
v><div>Enterprises want code that is not only high quality, but is easy to =
maintain with a development=C2=A0</div><div>team with high attrition. One h=
as to take whatever help is offered for that, and one is modern=C2=A0</div>=
<div>languages and runtimes.</div><div><br></div><div><div>Bits of Proof=E2=
=80=99s own implementation of the scripts was not practically relevant in m=
y commercially</div><div>successful deployments, because of the use of a bo=
rder router, but it helped development,=C2=A0</div><div>enabling easier deb=
ug and precise error feedback esp. end even after Core had a reject message=
.=C2=A0</div></div><div><br></div><div>I integrated libconsensus only for t=
he hope that is significantly fastens application side tx verification,</di=
v><div>=C2=A0which it has turned out it does not, until secp265k1 is integr=
ated.</div><div><br></div><div>I would likely use an other extended libcons=
ensus too, but do not think there was a dependency on=C2=A0</div><div>that =
for enterprise development.=C2=A0</div><div><br></div><div>It would help th=
ere more to have a slim protocol server, no wallet, no rpc, no qt but a hig=
h=C2=A0</div><div>performance remoting API.</div></div></div><div style=3D"=
word-wrap:break-word"><div><div><br></div><blockquote type=3D"cite"><div><s=
pan style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va=
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;float:none;display:inline!important">Since you already depend o=
n libconsensus for VerifyScript, wouldn&#39;t it</span><br style=3D"font-fa=
mily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-we=
ight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span s=
tyle=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant=
:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;float:none;display:inline!important">be nice that it also offered Ve=
rifyTx, VerifyHeader and VerifyBlock?</span><br style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px"><span style=3D"fon=
t-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;fon=
t-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;floa=
t:none;display:inline!important">You would still have complete control over=
 storage, concurrency,</span><br style=3D"font-family:Helvetica;font-size:1=
2px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing=
:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px"><span style=3D"font-family:Helvet=
ica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;float:none;display:=
inline!important">networking, policy...</span><br style=3D"font-family:Helv=
etica;font-size:12px;font-style:normal;font-variant:normal;font-weight:norm=
al;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"><span style=3D"f=
ont-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;f=
ont-weight:normal;letter-spacing:normal;line-height:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;fl=
oat:none;display:inline!important">My plan is for the C API to interface wi=
th the external storage by</span><br style=3D"font-family:Helvetica;font-si=
ze:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"><span style=3D"font-family:He=
lvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:no=
rmal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;disp=
lay:inline!important">passing a function pointer to it.</span></div></block=
quote></div></div><div style=3D"word-wrap:break-word"><div></div><div><br><=
/div><div>Storage and validation is non-trivially interconnected, but I now=
 the separation can be done,</div><div>since I did it.=C2=A0</div><div><br>=
</div><div>Excuse me, but function pointers is a pattern I used in the 80=
=E2=80=99s. I know that they are behind=C2=A0</div><div>the curtain of mode=
rn abstractions with similar use, I still prefer not to see them again.</di=
v></div><div style=3D"word-wrap:break-word"><div><br></div><div><div><div>T=
amas Blummer</div><div><br></div></div><div><blockquote type=3D"cite"></blo=
ckquote></div></div></div>_______________________________________________<b=
r>
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>

--047d7bd771220b3d48051df05aeb--