> On Aug 21, 2015, at 21:46, Jorge Timón <jti...@jtimon.cc> wrote: > > On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <ta...@bitsofproof.com > <mailto:ta...@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=764 <https://youtu.be/l3O4nh79CUU?t=764>
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’s decisions in an SPV manner. One might think of this setup as wasteful and unsuitable for “small devices” 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’s 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’s. I know that they are behind the curtain of modern abstractions with similar use, I still prefer not to see them again. Tamas Blummer
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
