path: root/2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0

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 82F9E847
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 02:19:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B9A7255
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Aug 2015 02:19:36 +0000 (UTC)
Received: by iods203 with SMTP id s203so117101270iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Aug 2015 19:19:35 -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=gZzWMi8MNGbLMhrW89gINxXWLRBlf+L9D5vxR73Nmnw=;
	b=GCGv8x4tn22YrwAfcoVdtpOQQd5CVP1JRbc7mpomibRpUm8o+ZHMmzf5J0K28Pe90+
	c/+M7Sj67N8nB6nXes68QZSTkXA4LBkNe5+GWtb809gD+7F0XM8+e4WqxjJUtuDo9naq
	KBz3iRTJwv8ruU9KRAV7eESCZ0t02/t6hrNG0DL9fS2D9kkwPcJbsDTSxsTgW3NWDQGo
	I7CbYA9giVzwvLph1pwGjzvVeYiXukgmWQk+9j3E+pbO4mHi46DmLuSAP3/AVTrQnBkO
	/8vnhBhT6Xhq8+IqUtf/PACOvFBu/SFCw+xtw+M59qcVL+ZvvdEVFhw5yBMm7FcNEhBa
	Sncg==
X-Received: by 10.107.4.85 with SMTP id 82mr12727249ioe.180.1440296375444;
	Sat, 22 Aug 2015 19:19:35 -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>
	<CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
In-Reply-To: <CABr1YTcx4V0Q4-ZQBEiNG-z1NKeFzxzhMekRN3YRRLz+bme2iw@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sun, 23 Aug 2015 02:19:26 +0000
Message-ID: <CABr1YTce7Q_=J9DVsmGQYUd6OVODiEqfFi+jPM6pMYn9uNpJOA@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=001a113d54eed46ad6051df12118
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 02:19:37 -0000

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

One thing it occurs to me (and I don't know if this has been suggested
before) we could do is separate the BIP process into at several distinct
areas:

1) Commit structure changes/consensus rule change proposals
- Consensus-building process (how are proposals debated, improved, vetted,
and selected)
- Update/deployment mechanisms for rule changes
- Specific hard fork proposals
- Specific soft fork proposals

2) Peer policies
- Seeding and discovery mechanisms
- Relay policies
- p2p message support

3) RPC

4) Everything else

On Sat, Aug 22, 2015, 6:28 PM Eric Lombrozo <elombrozo@gmail.com> wrote:

> 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 ver=
y
> few things (i.e. moving core structure serialization classes to a separat=
e
> unit not called main). Working on Bitcoin has an added layer of frustrati=
on
> 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 basical=
ly
> amount to updates to one specific reference implementation. And we all ne=
ed
> 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 l=
ot
> 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 la=
ck
> 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 duplicatio=
n
> 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 shoul=
d
> 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 comm=
on
> history and state. At the same time, let's open up more competition on al=
l
> 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 myse=
lf
> 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
>> 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
>>
>>
>> I do want something better, but not for the focus you have.
>>
>> Not because what you produce was not high quality, but because quality i=
s
>> 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
>> unsuitable 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 practi=
cally
>> 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 Cor=
e
>> had a reject message.
>>
>> I integrated libconsensus only for the hope that is significantly fasten=
s
>> 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
>> to see them again.
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<p dir=3D"ltr">One thing it occurs to me (and I don&#39;t know if this has =
been suggested before) we could do is separate the BIP process into at seve=
ral distinct areas:</p>
<p dir=3D"ltr">1) Commit structure changes/consensus rule change proposals<=
br>
- Consensus-building process (how are proposals debated, improved, vetted, =
and selected)<br>
- Update/deployment mechanisms for rule changes<br>
- Specific hard fork proposals<br>
- Specific soft fork proposals</p>
<p dir=3D"ltr">2) Peer policies<br>
- Seeding and discovery mechanisms<br>
- Relay policies<br>
- p2p message support</p>
<p dir=3D"ltr">3) RPC</p>
<p dir=3D"ltr">4) Everything else</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 22, 2015, 6:28 =
PM=C2=A0Eric Lombrozo &lt;<a href=3D"mailto:elombrozo@gmail.com">elombrozo@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">I&#39;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 sep=
arate unit not called main). Working on Bitcoin has an added layer of frust=
ration that goes beyond most open source projects: even though we&#39;re cl=
early in userland working at the application layer, a good layered protocol=
 design is still lacking. We have no standards process separate from what b=
asically amount to updates to one specific reference implementation. And we=
 all need to agree on any major change, since a blockchain that is easily f=
orked 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" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"w=
ord-wrap:break-word"><div><blockquote type=3D"cite"><div>On Aug 21, 2015, a=
t 21:46, Jorge Tim=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D=
"_blank">jtimon@jtimon.cc</a>&gt; wrote:</div><br><div><span style=3D"font-=
family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-=
weight:normal;letter-spacing:normal;line-height:normal;text-align:start;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:=
none;display:inline!important">On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blum=
mer &lt;</span><a href=3D"mailto:tamas@bitsofproof.com" style=3D"font-famil=
y:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weigh=
t:normal;letter-spacing:normal;line-height:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px" target=3D"=
_blank">tamas@bitsofproof.com</a><span style=3D"font-family:Helvetica;font-=
size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-s=
pacing:normal;line-height:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;float:none;display:inline!im=
portant">&gt; wrote:</span><br style=3D"font-family:Helvetica;font-size:12p=
x;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:n=
ormal;line-height:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px"><blockquote type=3D"cite" style=3D"=
font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;=
font-weight:normal;letter-spacing:normal;line-height:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">=
Every re-implementation, re-factoring even copy-paste introduces a risk of =
disagreement,<br>but also open the chance of doing the work better, in the =
sense of software engineering.<br></blockquote><br style=3D"font-family:Hel=
vetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:nor=
mal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px"><span style=3D"=
font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;=
font-weight:normal;letter-spacing:normal;line-height:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;f=
loat:none;display:inline!important">But you don&#39;t want something better=
, you want something functionally identical.</span><br style=3D"font-family=
:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight=
:normal;letter-spacing:normal;line-height:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px"><span 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;float:none;display:inline!important">You may want to watch sipa&#39;s ex=
planation on why &quot;the implementation is</span><br style=3D"font-family=
:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight=
:normal;letter-spacing:normal;line-height:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px"><span 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;float:none;display:inline!important">the specification&quot; and the rea=
sons to separate libconsensus:</span><br style=3D"font-family:Helvetica;fon=
t-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter=
-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px"><a href=3D"https://youtu.=
be/l3O4nh79CUU?t=3D764" target=3D"_blank">https://youtu.be/l3O4nh79CUU?t=3D=
764</a><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;=
font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:no=
rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px"></div></blockquote><div><br></div></div></div><div styl=
e=3D"word-wrap:break-word"><div><div>I do want something better, but not fo=
r the focus you have.=C2=A0</div><div><br></div><div>Not because what you p=
roduce was not high quality, but because quality is achieved at a very</div=
><div>high cost and is hard to uphold over generations of developer. You fo=
cus on a single use case</div><div>while there are many out there for distr=
ibuted ledgers.</div><div><br></div><div>I think in an infrastructure for e=
nterprise applications, building consensus on the ledger is a=C2=A0</div><d=
iv>cornerstone there, but is only a piece of the solution. I built several =
commercially successful</div><div>deployments where I delegated the consens=
us building to a border router, a Bitcoin Core,=C2=A0</div><div>then interf=
aced that trusted 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 wasteful 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><div>Enterprises have sufficient resources. Solving the busi=
ness problem is valuable to them even at=C2=A0</div><div>magnitudes higher =
cost than a hobbyist would bear.</div><div><br></div><div>For mainstream ad=
option you need to get enterprises on board too, and =C2=A0that is what I c=
are of.=C2=A0</div><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 has to take whatever help is offered for that, and one is m=
odern=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 practica=
lly relevant in my commercially</div><div>successful deployments, because o=
f the use of a border router, but it helped development,=C2=A0</div><div>en=
abling easier debug and precise error feedback esp. end even after Core had=
 a reject message.=C2=A0</div></div><div><br></div><div>I integrated libcon=
sensus only for the hope that is significantly fastens application side tx =
verification,</div><div>=C2=A0which it has turned out it does not, until se=
cp265k1 is integrated.</div><div><br></div><div>I would likely use an other=
 extended libconsensus too, but do not think there was a dependency on=C2=
=A0</div><div>that for enterprise development.=C2=A0</div><div><br></div><d=
iv>It would help there more to have a slim protocol server, no wallet, no r=
pc, no qt but a high=C2=A0</div><div>performance remoting API.</div></div><=
/div><div style=3D"word-wrap:break-word"><div><div><br></div><blockquote ty=
pe=3D"cite"><div><span 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;float:none;display:inline!important">Since y=
ou already depend on libconsensus for VerifyScript, wouldn&#39;t it</span><=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;font-style:=
normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-he=
ight:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;float:none;display:inline!important">be nice that=
 it also offered VerifyTx, VerifyHeader and VerifyBlock?</span><br style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
><span style=3D"font-family:Helvetica;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;wo=
rd-spacing:0px;float:none;display:inline!important">You would still have co=
mplete control over storage, concurrency,</span><br 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"><span style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;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: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"><span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;f=
ont-variant:normal;font-weight:normal;letter-spacing:normal;line-height:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;float:none;display:inline!important">My plan is for the C=
 API to interface with the external storage by</span><br style=3D"font-fami=
ly:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weig=
ht:normal;letter-spacing:normal;line-height:normal;text-align:start;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span sty=
le=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:n=
ormal;font-weight:normal;letter-spacing:normal;line-height:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px;float:none;display:inline!important">passing a function pointer to it.=
</span></div></blockquote></div></div><div style=3D"word-wrap:break-word"><=
div></div><div><br></div><div>Storage and validation is non-trivially inter=
connected, 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 patte=
rn I used in the 80=E2=80=99s. I know that they are behind=C2=A0</div><div>=
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"><div><br></d=
iv><div><div><div>Tamas Blummer</div><div><br></div></div><div><blockquote =
type=3D"cite"></blockquote></div></div></div>______________________________=
_________________<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></blockquote></div>

--001a113d54eed46ad6051df12118--