📅 Original date posted:2012-06-19
📝 Original message:> What problem does it solve?
Primarily that block verification and therefore propagation is too
slow because it's very CPU and IO intensive. The CPU work can be
multi-threaded. The IO work, not as much. As Bitcoin grows we need to
scale the nodes. Eventually there may be multi-machine nodes, but for
now we can buy more time by making the existing nodes faster.
I don't see this as a replacement for moving users to SPV clients.
Obviously, otherwise I would not be writing one ;)
> If the problem it will solve is the "too easy to get a DB_RUNRECOVERY
> error" because bdb is fragile when it comes to its environment... then
> LevelDB looks very interesting.
I have no experience with how robust LevelDB is. It has an API call to
try and repair the database and I know from experience that BigTable
is pretty solid. But that doesn't mean LevelDB is.
> If the problem is bdb is creaky and old and has obscure semantics and
> a hard-to-work-with API, then yes, lets switch (I'm easily seduced by
> a pretty API and blazing fast performance).
The code is a lot simpler for sure.
> As long as it compiles and runs on mac/windows/linux that doesn't
> really worry me.
It was refactored out of BigTable and made standalone for usage in
Chrome. Therefore it's as portable as Chrome is. Mac/Windows/Linux
should all work. Solaris, I believe, may need 64 bit binaries to avoid
low FD limits.
> Lack of infrastructure because it is new does worry me; for example,
> could I rework bitcointools to read the LevelDB blockchain? (are
> there python bindings for LevelDB?)
Yes: http://code.google.com/p/py-leveldb/
First look at the code is here, but it's not ready for a pull req yet,
and I'll force push over it a few times to get it into shape. So don't
branch:
https://github.com/mikehearn/bitcoin/commit/2b601dd4a0093f834084241735d84d84e484f183
It has misc other changes I made whilst profiling, isn't well
commented enough, etc.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:17:44
in reply to nevent1q…ler6
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydSeen on
wss://relay.noswhere.comPublished at
2023-06-07 10:17:44Event JSON
{
"id": "98ec6938bf16e0a42f6b8a235e3b784ed5122c408a29f070d396dbe4a2a8677d",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686133064,
"kind": 1,
"tags": [
[
"e",
"04f378001a224b61fbc2cdf06fef1e31477c4fe54d08e030aa71e61ff8312ae3",
"",
"root"
],
[
"e",
"d01b0f4465b70c2ded509945a4d5aed4b15f9d30e8b3b20bba2acdfc0441833a",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2012-06-19\n📝 Original message:\u003e What problem does it solve?\n\nPrimarily that block verification and therefore propagation is too\nslow because it's very CPU and IO intensive. The CPU work can be\nmulti-threaded. The IO work, not as much. As Bitcoin grows we need to\nscale the nodes. Eventually there may be multi-machine nodes, but for\nnow we can buy more time by making the existing nodes faster.\n\nI don't see this as a replacement for moving users to SPV clients.\nObviously, otherwise I would not be writing one ;)\n\n\u003e If the problem it will solve is the \"too easy to get a DB_RUNRECOVERY\n\u003e error\" because bdb is fragile when it comes to its environment... then\n\u003e LevelDB looks very interesting.\n\nI have no experience with how robust LevelDB is. It has an API call to\ntry and repair the database and I know from experience that BigTable\nis pretty solid. But that doesn't mean LevelDB is.\n\n\u003e If the problem is bdb is creaky and old and has obscure semantics and\n\u003e a hard-to-work-with API, then yes, lets switch (I'm easily seduced by\n\u003e a pretty API and blazing fast performance).\n\nThe code is a lot simpler for sure.\n\n\u003e As long as it compiles and runs on mac/windows/linux that doesn't\n\u003e really worry me.\n\nIt was refactored out of BigTable and made standalone for usage in\nChrome. Therefore it's as portable as Chrome is. Mac/Windows/Linux\nshould all work. Solaris, I believe, may need 64 bit binaries to avoid\nlow FD limits.\n\n\u003e Lack of infrastructure because it is new does worry me; for example,\n\u003e could I rework bitcointools to read the LevelDB blockchain? (are\n\u003e there python bindings for LevelDB?)\n\nYes: http://code.google.com/p/py-leveldb/\n\nFirst look at the code is here, but it's not ready for a pull req yet,\nand I'll force push over it a few times to get it into shape. So don't\nbranch:\n\nhttps://github.com/mikehearn/bitcoin/commit/2b601dd4a0093f834084241735d84d84e484f183\n\nIt has misc other changes I made whilst profiling, isn't well\ncommented enough, etc.",
"sig": "1974adaa739d2f44565eb58799c1128c803fd4fc9396d4f3a785ed4b78c0a27f83e937960f35818c8f6acf70133615779271a7741bd29e7ff9d5cac954ed802f"
}