📅 Original date posted:2015-08-20
📝 Original message: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.
> 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.
Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/ea9ba04d/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 15:48:45
in reply to nevent1q…gkem
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 15:48:45Event JSON
{
"id": "272d0972bcb653fd4de771ef905843096ae0d25170c3c857f1fd8278c50a68bf",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686152925,
"kind": 1,
"tags": [
[
"e",
"2cb77a81d8c40c165dca19129371f9698d50bec611bf964a3c59cbb47a7d1941",
"",
"root"
],
[
"e",
"ce2b48ee162cb17e67b7b9bd3df5aeda7930013596615d0426a2027b7957c2ed",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-20\n📝 Original message:Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,\nbut also open the chance of doing the work better, in the sense of software engineering.\n\n\u003e On Aug 20, 2015, at 10:06, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e \n\u003e \n\u003e But the goal is not reimplementing the consensus rules but rather\n\u003e extract them from Bitcoin Core so that nobody needs to re-implement\n\u003e them again.\n\n\n\nMy goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,\nbut it is also imperative to be able to create and serve other block chains with other rules and for those\nI do not want to carry on the legacy of an antique tool set and a spaghetti style.\n\nBits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)\nand I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were\nmade because each piece appears best in what they do.\n\nTamas Blummer\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/ea9ba04d/attachment.sig\u003e",
"sig": "66d8fa973d8852adbdb3bd6159e5c0f4f827e53f2edc642c99ed84a5f6fc2bf06ff0b5de9290a84b47189341cbbb473b123a020bc6756873025405e1432c30fe"
}