diff options
author | Eric Lombrozo <elombrozo@gmail.com> | 2015-08-23 02:19:26 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-23 02:19:37 +0000 |
commit | 7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed (patch) | |
tree | cb44bef3d3e9748cf8d4454920791b5c110a3685 | |
parent | 116552c0bfa721fed0005573bac33856730973ba (diff) | |
download | pi-bitcoindev-7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed.tar.gz pi-bitcoindev-7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed.zip |
Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
-rw-r--r-- | 2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0 | 479 |
1 files changed, 479 insertions, 0 deletions
diff --git a/2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0 b/2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0 new file mode 100644 index 000000000..65a593be3 --- /dev/null +++ b/2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0 @@ -0,0 +1,479 @@ +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'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 <<a href=3D"mailto:elombrozo@gmail.com">elombrozo@= +gmail.com</a>> 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'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'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's = +a lot of love that's gone into this. But it'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't really seem like it will ultimate= +ly 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">I know that some might feel I'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'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'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'= +ve put into this whole block size circus into what'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 <<a href=3D"mailto:bitcoin-dev@lis= +ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation= +.org</a>> 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 <<a href=3D"mailto:jtimon@jtimon.cc" target=3D= +"_blank">jtimon@jtimon.cc</a>> 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 <</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">> 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'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's ex= +planation on why "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" 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'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-- + |