Gavin Andresen [ARCHIVE] on Nostr: š
Original date posted:2012-06-19 š Original message:> OK, to make progress on ...
š
Original date posted:2012-06-19
š Original message:> OK, to make progress on this work I need a few decisions (Gavin?)
>
> 1) Shall we do it?
What problem does it solve?
If the problem it will solve is "it will only take 4 hours to download
the entire blockchain next year instead of taking 16 hours" then no, I
don't think we should do it, both 4 and 16 hours to get fully up and
running is too long.
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.
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).
> 2) LevelDB is obscure, new and has a very minimalist build system. It
> supports "make" but not "make install", for example, and is unlikely
> to be packaged. It's also not very large. I suggest we just check the
> source into the main Bitcoin tree and link it statically rather than
> complicate the build.
As long as it compiles and runs on mac/windows/linux that doesn't
really worry me. I just tried it, and it compiled quickly with no
complaints on my mac.
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?)
> 3) As the DB format would change and a slow migration period
> necessary, any other tweaks to db format we could make at the same
> time? Right now the key/values are the same as before, though using
> satoshi serialization for everything is a bit odd.
Satoshi rolled his own network serialization because he didn't trust
existing serialization solutions to be 100% secure against remote
exploits. Then it made sense to use the same solution for disk
serialization; I don't see a compelling reason to switch to some other
serialization scheme.
Modifying the database schema during migration to better support
applications like InstaWallet (tens of thousands of separate wallets)
or something like Pieter's ultra-pruning makes sense.
--
--
Gavin Andresen
Published at
2023-06-07 10:17:41Event JSON
{
"id": "d01b0f4465b70c2ded509945a4d5aed4b15f9d30e8b3b20bba2acdfc0441833a",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686133061,
"kind": 1,
"tags": [
[
"e",
"04f378001a224b61fbc2cdf06fef1e31477c4fe54d08e030aa71e61ff8312ae3",
"",
"root"
],
[
"e",
"259347b0af29488154876c7ab162dcb2815759c683be2c3e0fb84e299c8473de",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "š
Original date posted:2012-06-19\nš Original message:\u003e OK, to make progress on this work I need a few decisions (Gavin?)\n\u003e\n\u003e 1) Shall we do it?\n\nWhat problem does it solve?\n\nIf the problem it will solve is \"it will only take 4 hours to download\nthe entire blockchain next year instead of taking 16 hours\" then no, I\ndon't think we should do it, both 4 and 16 hours to get fully up and\nrunning is too long.\n\nIf the problem it will solve is the \"too easy to get a DB_RUNRECOVERY\nerror\" because bdb is fragile when it comes to its environment... then\nLevelDB looks very interesting.\n\nIf the problem is bdb is creaky and old and has obscure semantics and\na hard-to-work-with API, then yes, lets switch (I'm easily seduced by\na pretty API and blazing fast performance).\n\n\u003e 2) LevelDB is obscure, new and has a very minimalist build system. It\n\u003e supports \"make\" but not \"make install\", for example, and is unlikely\n\u003e to be packaged. It's also not very large. I suggest we just check the\n\u003e source into the main Bitcoin tree and link it statically rather than\n\u003e complicate the build.\n\nAs long as it compiles and runs on mac/windows/linux that doesn't\nreally worry me. I just tried it, and it compiled quickly with no\ncomplaints on my mac.\n\nLack of infrastructure because it is new does worry me; for example,\ncould I rework bitcointools to read the LevelDB blockchain? (are\nthere python bindings for LevelDB?)\n\n\u003e 3) As the DB format would change and a slow migration period\n\u003e necessary, any other tweaks to db format we could make at the same\n\u003e time? Right now the key/values are the same as before, though using\n\u003e satoshi serialization for everything is a bit odd.\n\nSatoshi rolled his own network serialization because he didn't trust\nexisting serialization solutions to be 100% secure against remote\nexploits. Then it made sense to use the same solution for disk\nserialization; I don't see a compelling reason to switch to some other\nserialization scheme.\n\nModifying the database schema during migration to better support\napplications like InstaWallet (tens of thousands of separate wallets)\nor something like Pieter's ultra-pruning makes sense.\n\n-- \n--\nGavin Andresen",
"sig": "7c0e75e4c17d404f5c01c7624bdd9da4b427b4674d69957bbbb7da1c42763d5d782bea745871458b2d393a8e7f08ad34108b42face09c2d6c2a7ea1ebc7b1d1d"
}