📅 Original date posted:2015-08-21
📝 Original message:Thinking in Bitcoins only on the level of technology unnecessarily narrows your view.
OK, I hope to be pleasantly surprised.
Tamas Blummer
> On Aug 20, 2015, at 23:35, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
>
>
> On 08/20/15 21:26, Tamas Blummer wrote:
>> I know what you mean as I already have such a component with pluggable
>> block store and networking.
>
> I'm not suggesting pluggable networking, I'm suggesting (and I think
> everyone thinks the design should be) NO networking. The API is
> ValidationResult libconsensus.HeyIFoundABlock(Block) and
> ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
>
>> While you are at it you could aim for isolation of bitcoin specific
>> decisions and algos from generic block chain code.
>
> Are you suggesting to support altcoins? I dont think anyone cares about
> supporting that.
>
>> The magnitude of refactoring you would have to do to get there from
>> main.cpp and the rest of the hairball
>> is harder than a re-write from scratch,
>
> I think you'd be very pleasantly surprised. It sounds like you havent
> dug into Bitcoin Core validation code in years.
>
>> and the result will not be
>> impressive, just hopefully working.
>
> Hmm? The result would be an obviously correct consensus implementation
> that everyone could use, instead of everyone going off and writing their
> own and either being wrong, or never updating in the case of forks. Its
> a huge deal to allow people to focus on making their libraries have good
> APIs/Wallets/etc instead of focusing on making a working validation
> engine (though maybe for that the p2p layer needs to also be in a library).
>
>> I think a slim API server was a lower hanging fruit in Core’s case.
>
> We have one, it just needs a few already obvious performance improvements.
>
>> BTW, support for refactoring is an example where you see if your tool
>> set is modern.
>
> There are a number of good development tools for C++ that allow this....
>
>> Tamas Blummer
>>
>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> I dont think a libconsensus would have any kind of networking layer, nor
>>> is C++ an antique tool set (hopefully libconsensus can avoid a boost
>>> dependency, though thats not antique either). Ideally it would have a
>>> simple API to give it blocks and a simple API for it to inform you of
>>> what the current chain is. If you really want to get fancy maybe it has
>>> pluggable block storage, too, but I dont see why you couldnt use this in
>>> ~any client?
>>>
>>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev 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.
>>>>
>>>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc
>>>>> <mailto: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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto: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/9b8a4eb3/attachment.html>;
-------------- 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/20150821/9b8a4eb3/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 19:37:18
in reply to nevent1q…4xzl
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 19:37:18Event JSON
{
"id": "b9a4e39f53cc8192b34907aad7d02722a04d102696260da2d1ad01f1a33f390f",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686159438,
"kind": 1,
"tags": [
[
"e",
"62eaaecf7e0dd571a7fefc51979233ca5e3a2661a7ebffd6475a1fa69ae78e93",
"",
"root"
],
[
"e",
"a9af1da94745d63e4ab5840c9d03b3405aa165637b7ae943ab1b686b68992a23",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2015-08-21\n📝 Original message:Thinking in Bitcoins only on the level of technology unnecessarily narrows your view.\n\nOK, I hope to be pleasantly surprised.\n\nTamas Blummer\n\n\u003e On Aug 20, 2015, at 23:35, Matt Corallo \u003clf-lists at mattcorallo.com\u003e wrote:\n\u003e \n\u003e \n\u003e \n\u003e On 08/20/15 21:26, Tamas Blummer wrote:\n\u003e\u003e I know what you mean as I already have such a component with pluggable\n\u003e\u003e block store and networking.\n\u003e \n\u003e I'm not suggesting pluggable networking, I'm suggesting (and I think\n\u003e everyone thinks the design should be) NO networking. The API is\n\u003e ValidationResult libconsensus.HeyIFoundABlock(Block) and\n\u003e ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).\n\u003e \n\u003e\u003e While you are at it you could aim for isolation of bitcoin specific\n\u003e\u003e decisions and algos from generic block chain code.\n\u003e \n\u003e Are you suggesting to support altcoins? I dont think anyone cares about\n\u003e supporting that.\n\u003e \n\u003e\u003e The magnitude of refactoring you would have to do to get there from\n\u003e\u003e main.cpp and the rest of the hairball\n\u003e\u003e is harder than a re-write from scratch,\n\u003e \n\u003e I think you'd be very pleasantly surprised. It sounds like you havent\n\u003e dug into Bitcoin Core validation code in years.\n\u003e \n\u003e\u003e and the result will not be\n\u003e\u003e impressive, just hopefully working.\n\u003e \n\u003e Hmm? The result would be an obviously correct consensus implementation\n\u003e that everyone could use, instead of everyone going off and writing their\n\u003e own and either being wrong, or never updating in the case of forks. Its\n\u003e a huge deal to allow people to focus on making their libraries have good\n\u003e APIs/Wallets/etc instead of focusing on making a working validation\n\u003e engine (though maybe for that the p2p layer needs to also be in a library).\n\u003e \n\u003e\u003e I think a slim API server was a lower hanging fruit in Core’s case.\n\u003e \n\u003e We have one, it just needs a few already obvious performance improvements.\n\u003e \n\u003e\u003e BTW, support for refactoring is an example where you see if your tool\n\u003e\u003e set is modern.\n\u003e \n\u003e There are a number of good development tools for C++ that allow this....\n\u003e \n\u003e\u003e Tamas Blummer\n\u003e\u003e \n\u003e\u003e\u003e On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e I dont think a libconsensus would have any kind of networking layer, nor\n\u003e\u003e\u003e is C++ an antique tool set (hopefully libconsensus can avoid a boost\n\u003e\u003e\u003e dependency, though thats not antique either). Ideally it would have a\n\u003e\u003e\u003e simple API to give it blocks and a simple API for it to inform you of\n\u003e\u003e\u003e what the current chain is. If you really want to get fancy maybe it has\n\u003e\u003e\u003e pluggable block storage, too, but I dont see why you couldnt use this in\n\u003e\u003e\u003e ~any client?\n\u003e\u003e\u003e \n\u003e\u003e\u003e On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e Every re-implementation, re-factoring even copy-paste introduces a\n\u003e\u003e\u003e\u003e risk of disagreement,\n\u003e\u003e\u003e\u003e but also open the chance of doing the work better, in the sense of\n\u003e\u003e\u003e\u003e software engineering.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e On Aug 20, 2015, at 10:06, Jorge Timón \u003cjtimon at jtimon.cc\n\u003e\u003e\u003e\u003e\u003e \u003cmailto:jtimon at jtimon.cc\u003e\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e But the goal is not reimplementing the consensus rules but rather\n\u003e\u003e\u003e\u003e\u003e extract them from Bitcoin Core so that nobody needs to re-implement\n\u003e\u003e\u003e\u003e\u003e them again.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e My goal is different. Compatibility with Bitcoin is important as I\n\u003e\u003e\u003e\u003e also want to deal with Bitcoins,\n\u003e\u003e\u003e\u003e but it is also imperative to be able to create and serve other block\n\u003e\u003e\u003e\u003e chains with other rules and for those\n\u003e\u003e\u003e\u003e I do not want to carry on the legacy of an antique tool set and a\n\u003e\u003e\u003e\u003e spaghetti style.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Bits of Proof uses scala (akka networking), java (api service), c++\n\u003e\u003e\u003e\u003e (leveledb and now libconsensus)\n\u003e\u003e\u003e\u003e and I am eager to integrate secp256k1 (c) as soon as part of\n\u003e\u003e\u003e\u003e consensus. The choices were\n\u003e\u003e\u003e\u003e made because each piece appears best in what they do.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Tamas Blummer\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \n\u003e\u003e \n\u003e \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/9b8a4eb3/attachment.html\u003e\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/20150821/9b8a4eb3/attachment.sig\u003e",
"sig": "d5f34b265618711fc7b391f7670812dc42744cebef16d24fe983a5815087e674af33724e5a754b7b69315a8151bbe103ffa57043b45c5b971c6475ab8a8b7f85"
}