📅 Original date posted:2015-08-21
📝 Original message: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.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 15:48:47
in reply to nevent1q…28qh
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:48:47Event JSON
{
"id": "03b1fadadc9378051d9b7fdf879ed4203a1417ad44837b6699de1d593a385c99",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152927,
"kind": 1,
"tags": [
[
"e",
"2cb77a81d8c40c165dca19129371f9698d50bec611bf964a3c59cbb47a7d1941",
"",
"root"
],
[
"e",
"3a17faab5c02532dea4fbbad6502a9eb71be8f152c539aadd1a19ba77896761c",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2015-08-21\n📝 Original message:On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer \u003ctamas at bitsofproof.com\u003e wrote:\n\u003e Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,\n\u003e but also open the chance of doing the work better, in the sense of software engineering.\n\nBut you don't want something better, you want something functionally identical.\nYou may want to watch sipa's explanation on why \"the implementation is\nthe specification\" and the reasons to separate libconsensus:\nhttps://youtu.be/l3O4nh79CUU?t=764\n\n\u003e\u003e On Aug 20, 2015, at 10:06, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e But the goal is not reimplementing the consensus rules but rather\n\u003e\u003e extract them from Bitcoin Core so that nobody needs to re-implement\n\u003e\u003e them again.\n\u003e\n\u003e\n\u003e\n\u003e My goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,\n\u003e but it is also imperative to be able to create and serve other block chains with other rules and for those\n\u003e I do not want to carry on the legacy of an antique tool set and a spaghetti style.\n\u003e\n\u003e Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)\n\u003e and I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were\n\u003e made because each piece appears best in what they do.\n\nSince you already depend on libconsensus for VerifyScript, wouldn't it\nbe nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?\nYou would still have complete control over storage, concurrency,\nnetworking, policy...\nMy plan is for the C API to interface with the external storage by\npassing a function pointer to it.",
"sig": "81983136bb7ab2b8655f5533f81f68fda3f29a6bf9fd49a727afd4e38c4719505650bf48cba62a9a48fc8410f73611d613fcad6d6e61275beee11d9aeef0d17a"
}