From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 327CD120A for ; Sat, 29 Aug 2015 22:08:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E259AB for ; Sat, 29 Aug 2015 22:08:26 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so45428990lbb.1 for ; Sat, 29 Aug 2015 15:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y2BxBi/QlTq4dvqWfKRQpbTOrh1gTAZs86B/ZkTz3tQ=; b=b8rHI/XBqcBSzN2wRcan7M429BHS+Gf4Q5H2HU+Imu5bPecqG4upKe4eTTCyUgNK18 4cdwcJvHbiU0WYfaVxhRdLFfNbkjKUL95f52BtS9odhqD8N8uZXEv6KzFF+Q4ENU/2pi pBKZjDeyHlNqs9ZRR4m5FyDt1dHVMgGIr2fHDE1vNq154P4VNFR6rwDqngECZc7W+I4p bqtN5z4BW6I5Cl1OI7F/iz6/SincqSiHcBWQxnzrXPMmgBoQ2XXODlnBtttGl6FIGorN EBpodz2TUpnlIISmZzFyeh5jTpskpGI9qvbItlK9vg7jmNc+UR6mCvchMNIjdnUPk4BL F/QA== X-Gm-Message-State: ALoCoQkrvS7Jy1mAAh8n+Z+SjJeuL81aJl31iMJ0vapeOvM9nd2TR13HPO1y4zUw7PlhkSL4N+DL MIME-Version: 1.0 X-Received: by 10.112.146.106 with SMTP id tb10mr7657056lbb.22.1440886104151; Sat, 29 Aug 2015 15:08:24 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Sat, 29 Aug 2015 15:08:24 -0700 (PDT) In-Reply-To: References: <55B723EA.7010700@voskuil.org> <55B939CF.1080903@voskuil.org> <3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com> Date: Sun, 30 Aug 2015 00:08:24 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tamas Blummer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,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, 29 Aug 2015 22:08:27 -0000 On Sat, Aug 22, 2015 at 1:04 PM, Tamas Blummer wrot= e: > On Aug 21, 2015, at 21:46, Jorge Tim=C3=B3n wrote: > > On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer > wrote: > > Every re-implementation, re-factoring even copy-paste introduces a risk o= f > disagreement, > but also open the chance of doing the work better, in the sense of softwa= re > 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 consen= sus > on the ledger is a > cornerstone there, but is only a piece of the solution. I built several > commercially successful > deployments where I delegated the consensus building to a border router, = a > Bitcoin Core, > then interfaced that trusted peer with my implementation that accepted > Core=E2=80=99s decisions > in an SPV manner. One might think of this setup as wasteful and unsuitabl= e > for =E2=80=9Csmall devices=E2=80=9D > therefore an example of centralization people here try to avoid. > > Enterprises have sufficient resources. Solving the business problem is > valuable to them even at > magnitudes higher cost than a hobbyist would bear. > > For mainstream adoption you need to get enterprises on board too, and th= at > is what I care of. > Enterprises want code that is not only high quality, but is easy to maint= ain > with a development > team with high attrition. One has to take whatever help is offered for th= at, > and one is modern > languages and runtimes. > > Bits of Proof=E2=80=99s own implementation of the scripts was not practic= ally > relevant in my commercially > successful deployments, because of the use of a border router, but it hel= ped > development, > enabling easier debug and precise error feedback esp. end even after Core > had a reject message. In fact I have been accused in the past (by at least Peter Todd) of having "too many cases in mind" or "doing refactors that are good for altchains". That's why I'm very cautious about proposing changes that are not strict improvments in maintainability to bitcoin itself. But I actually have freicoin, sidechains and private chains (defined in freimarkets, used in elements alpha as "block signing") in mind. Some of the consensus changes I have in mind are support for multiple assets or interest-bearing assets, for example. But if you need to change the consensus rules you need to change the code, there's no way around that. It will be much simpler to only adapt libconsensus to other chains than it is to adapt the whole Bitcoin Core code base. Libconsensus can free you from the need of running "border routers" (which you need to adapt if you depend on them and are supporting chains with different rules). When libconsensus has it's own independent repository, will I fork the project to have a multi-consensus library supporting multiple different chains (apart from bitcoin and its testchains)? Maybe, I'm not sure it makes sense, maybe it's just simpler to maintain a different project for each different chain (ie libfreicoinconsensus, libbetaconsensus, etc). > 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. That is very sad to hear. The main reason to integrate libconsensus is to avoid consensus fork bugs (or to not depend on the "border routers" to avoid those bugs). > 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 rp= c, > no qt but a high > performance remoting API. That's out of scope for libconsensus which will be stateless and whose only API would be in C. But the refactors in Bitcoin Core will hopefully make it easier to support such a minimal node in it (you know you can "./configure --disable-wallet --without-gui" already, right?, about RPC, that's the remaining API!). > Since you already depend on libconsensus for VerifyScript, wouldn't it > be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock? > You would still have complete control over storage, concurrency, > networking, policy... > My plan is for the C API to interface with the external storage by > passing a function pointer to it. > > > Storage and validation is non-trivially interconnected, but I now the > separation can be done, > since I did it. > > Excuse me, but function pointers is a pattern I used in the 80=E2=80=99s.= I know > that they are behind > the curtain of modern abstractions with similar use, I still prefer not t= o > see them again. Yes, and the wheel it's an invention used in pre-historic times: that doesn't make it less useful. Do you have any other suggestion for interfacing with external storage using a C API?