summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEric Lombrozo <elombrozo@gmail.com>2015-08-23 02:19:26 +0000
committerbitcoindev <bitcoindev@gnusha.org>2015-08-23 02:19:37 +0000
commit7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed (patch)
treecb44bef3d3e9748cf8d4454920791b5c110a3685
parent116552c0bfa721fed0005573bac33856730973ba (diff)
downloadpi-bitcoindev-7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed.tar.gz
pi-bitcoindev-7711dfce2d4ed6a7b584b7d6cf6db22e91c227ed.zip
Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
-rw-r--r--2f/501e58cf1b9c50ca0a25a592c60a6df1576fd0479
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&#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--
+