📅 Original date posted:2015-08-21
📝 Original message:Unfortunately we have no way of rigorously proving functional equivalence
other than code review and unit testing. The simpler the consensus code
(and the more we can write it in a style that affords provability of
correctness) the easier it will be in the future to compare implementations.
Prior to swapping out implementations, we should at the least run it
through the gauntlet and perhaps run both implementations side-by-side.
All I/O should be treated abstractly in the API.
In C++ I really like using a nearly bare-bones signal template for most
async message handling, i.e.
https://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h
This greatly facilitates support for async bidirectional I/O, etc...with
minimal overhead.
But others might have other stylistic preferences.
- Eric
On Fri, Aug 21, 2015, 12:46 PM Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at 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
>
> >> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >>
> >> But the goal is not reimplementing the consensus rules but rather
> >> extract them from Bitcoin Core so that nobody needs to re-implement
> >> them again.
> >
> >
> >
> > My goal is different. Compatibility with Bitcoin is important as I also
> want to deal with Bitcoins,
> > but it is also imperative to be able to create and serve other block
> chains with other rules and for those
> > I do not want to carry on the legacy of an antique tool set and a
> spaghetti style.
> >
> > Bits of Proof uses scala (akka networking), java (api service), c++
> (leveledb and now libconsensus)
> > and I am eager to integrate secp256k1 (c) as soon as part of consensus.
> The choices were
> > made because each piece appears best in what they do.
>
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/71b04009/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 15:48:47
in reply to nevent1q…9ey8
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 15:48:47Event JSON
{
"id": "34d28e4cb55704d2b4d696396338bafb343426b17ad6d38770e7d73a75876386",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686152927,
"kind": 1,
"tags": [
[
"e",
"2cb77a81d8c40c165dca19129371f9698d50bec611bf964a3c59cbb47a7d1941",
"",
"root"
],
[
"e",
"03b1fadadc9378051d9b7fdf879ed4203a1417ad44837b6699de1d593a385c99",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-21\n📝 Original message:Unfortunately we have no way of rigorously proving functional equivalence\nother than code review and unit testing. The simpler the consensus code\n(and the more we can write it in a style that affords provability of\ncorrectness) the easier it will be in the future to compare implementations.\n\nPrior to swapping out implementations, we should at the least run it\nthrough the gauntlet and perhaps run both implementations side-by-side.\n\nAll I/O should be treated abstractly in the API.\n\nIn C++ I really like using a nearly bare-bones signal template for most\nasync message handling, i.e.\nhttps://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h\n\nThis greatly facilitates support for async bidirectional I/O, etc...with\nminimal overhead.\n\nBut others might have other stylistic preferences.\n\n- Eric\n\nOn Fri, Aug 21, 2015, 12:46 PM Jorge Timón \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer \u003ctamas at bitsofproof.com\u003e\n\u003e wrote:\n\u003e \u003e Every re-implementation, re-factoring even copy-paste introduces a risk\n\u003e of disagreement,\n\u003e \u003e but also open the chance of doing the work better, in the sense of\n\u003e software engineering.\n\u003e\n\u003e But you don't want something better, you want something functionally\n\u003e identical.\n\u003e You may want to watch sipa's explanation on why \"the implementation is\n\u003e the specification\" and the reasons to separate libconsensus:\n\u003e https://youtu.be/l3O4nh79CUU?t=764\n\u003e\n\u003e \u003e\u003e On Aug 20, 2015, at 10:06, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e But the goal is not reimplementing the consensus rules but rather\n\u003e \u003e\u003e extract them from Bitcoin Core so that nobody needs to re-implement\n\u003e \u003e\u003e them again.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e My goal is different. Compatibility with Bitcoin is important as I also\n\u003e want to deal with Bitcoins,\n\u003e \u003e but it is also imperative to be able to create and serve other block\n\u003e chains with other rules and for those\n\u003e \u003e I do not want to carry on the legacy of an antique tool set and a\n\u003e spaghetti style.\n\u003e \u003e\n\u003e \u003e Bits of Proof uses scala (akka networking), java (api service), c++\n\u003e (leveledb and now libconsensus)\n\u003e \u003e and I am eager to integrate secp256k1 (c) as soon as part of consensus.\n\u003e The choices were\n\u003e \u003e made because each piece appears best in what they do.\n\u003e\n\u003e Since you already depend on libconsensus for VerifyScript, wouldn't it\n\u003e be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?\n\u003e You would still have complete control over storage, concurrency,\n\u003e networking, policy...\n\u003e My plan is for the C API to interface with the external storage by\n\u003e passing a function pointer to it.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/71b04009/attachment.html\u003e",
"sig": "5b62ac9205b0ea93f2ee9b9399952fc0ff9106a36f17af4d3f36b45db3afa1c43e752493dd41b28c00fcbe38f855d0b940afb91ef213abdc18d28d0ff3bc7df7"
}