Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 48BAC273 for ; Sat, 22 Aug 2015 11:04:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from wp059.webpack.hosteurope.de (wp059.webpack.hosteurope.de [80.237.132.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14B2B11E for ; Sat, 22 Aug 2015 11:04:52 +0000 (UTC) Received: from [37.143.74.116] (helo=[192.168.2.11]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1ZT6bO-0001H8-6f; Sat, 22 Aug 2015 13:04:46 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0AC7FFE2-27D0-42BB-AD83-48BBC8CA66FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Tamas Blummer In-Reply-To: Date: Sat, 22 Aug 2015 13:04:44 +0200 Message-Id: References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> <3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com> To: =?utf-8?Q?Jorge_Tim=C3=B3n?= , Matt Corallo X-Mailer: Apple Mail (2.2104) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440241492; 4fdc44cc; X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Libbitcoin 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2015 11:04:53 -0000 --Apple-Mail=_0AC7FFE2-27D0-42BB-AD83-48BBC8CA66FA Content-Type: multipart/alternative; boundary="Apple-Mail=_03E79B10-48E5-4696-8CD0-8A433D1AD39B" --Apple-Mail=_03E79B10-48E5-4696-8CD0-8A433D1AD39B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 21, 2015, at 21:46, Jorge Tim=C3=B3n wrote: >=20 > On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer > wrote: >> Every re-implementation, re-factoring even copy-paste introduces a = risk of disagreement, >> but also open the chance of doing the work better, in the sense of = software engineering. >=20 > But you don't want something better, you want something functionally = identical. > You may want to watch sipa's explanation on why "the implementation is > the specification" and the reasons to separate libconsensus: > https://youtu.be/l3O4nh79CUU?t=3D764 = 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 = 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 = practically relevant in my commercially successful deployments, because of the use of a border router, but it = helped development, enabling easier debug and precise error feedback esp. end even after = Core had a reject message. 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 = to see them again. Tamas Blummer --Apple-Mail=_03E79B10-48E5-4696-8CD0-8A433D1AD39B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 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 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 practically relevant in my = commercially
successful deployments, because of the use of a = border router, but it helped development, 
enabling = easier debug and precise error feedback esp. end even after Core had a = reject message. 

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 to see them again.

Tamas = Blummer

= --Apple-Mail=_03E79B10-48E5-4696-8CD0-8A433D1AD39B-- --Apple-Mail=_0AC7FFE2-27D0-42BB-AD83-48BBC8CA66FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV2FdNAAoJEPZykcUXcTkcbhYH/R1Z7RlCBucHlUiz8EaQQz95 unJunq3QESYqCkmW2QWUiSmMPOYC6+rSUOpu9OprNLyXdiQzantRwOh7tY6Hd6ut b59R1/RzW5i7Q/2G0TqgMnXh1D3HrMWvMjihZeuWG5pen6RKZhAASz2rccAxoHWL teoooe5jBFihg1uMtkyTwdQWUF16TVmqkNksgi5TW+oZt82EQ2WjxuG9E1GbloR4 oRHqa/QzAGowOIaAoRBACUh83b9+3Hv6zG55Go3n/qxWVBBSftU3iCbFvrWraKX0 u2OmKv5SMhyBwuxIgd116r2qx7REYXMBzY581q6Wq76bKqormF28ZOG2/tFzS2c= =TQyS -----END PGP SIGNATURE----- --Apple-Mail=_0AC7FFE2-27D0-42BB-AD83-48BBC8CA66FA--