< ZSky>
sipa: dumb question: why not using leveldb this way: block13672: [BLOCKRAWDATA]
< ZSky>
and totally rely on leveldb's data management?
< sipa>
because we don't need leveldb's data management
< ZSky>
you use it for metadata
< ZSky>
so you kind of need a small key:value db
< sipa>
yes, which is a tiny amount of data
< ZSky>
true
< ZSky>
so the idea is: you keep a key:value store for the smallest amount of data possible
< sipa>
but for blocks themselves, we don't need consistency, or the ability to selectively update and delete, or ...
< ZSky>
true
< sipa>
it's just a stream of data that comes in, and we can drop it in effectively append only files on disk
< sipa>
in fact, we hardly use the block data after it's been processed
< sipa>
it's just for when another peer in the network asks for it
< sipa>
or to rescan for old wallet activity
< ZSky>
yes i see
< ZSky>
historically, in the earliest implementations, what was used before leveldb?
< sipa>
BDB
< sipa>
changed in 0.8
< sipa>
and the wallet still uses BDB
< ZSky>
why no BDB anymore?
< sipa>
many many reports of corruption
< sipa>
incompatibilities between versions (you can't downgrade, and in some cases you can't even upgrade)
< sipa>
and the fact that BDB was indirectly the cause for one of the largest operational problems the system has seen in years (read BIP50)
< ZSky>
oh really?
< sipa>
which was related due to it know how many locks the database will require during its operation
< ZSky>
tl;dr what was it?
< sipa>
while we don't need any locks at all
< sipa>
you need to configure BDB with "i need up to X locks", and if any atomic database operation touches more internal records than you have configured locks, the operations fails
< sipa>
this is because BDB is a multi-application database system (multiple processes can simultaneously open and modify the database, and there is consistency across them), which is something we don't care about at all
< ZSky>
sipa: what was used in 0.1.0?
< sipa>
BDB
< ZSky>
ok right
< ZSky>
sipa: do you do python sometimes?
< sipa>
hardly
< ZSky>
i was looking for such a keystore in py
< ZSky>
sipa: thanks for these informations!
< sipa>
yw
< cluelessperson>
aj: thank you for your help
< cluelessperson>
How can I help you all?
< cluelessperson>
I can do some devops
< cluelessperson>
put me to use
< meshcollider>
devops...199
< mryandao>
meshcollider: lol, funny
< meshcollider>
CScripts in the wallet don't have birth-times associated with them do they
< bitcoin-git>
[bitcoin] luke-jr opened pull request #11658: During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after (master...ibd_prune_extra) https://github.com/bitcoin/bitcoin/pull/11658
< bitcoin-git>
bitcoin/master ea0cd24 John Newbery: [tests] Tidy up receivedby.py...
< bitcoin-git>
bitcoin/master 5e0ba8f John Newbery: [wallet] getreceivedbyaddress should return error if address is not mine
< bitcoin-git>
bitcoin/master 95e14dc MarcoFalke: Merge #11055: [wallet] [rpc] getreceivedbyaddress should return error if called with address not owned by the wallet...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11055: [wallet] [rpc] getreceivedbyaddress should return error if called with address not owned by the wallet (master...getreceivedbyaddress_error) https://github.com/bitcoin/bitcoin/pull/11055
< bitcoin-git>
[bitcoin] benma closed pull request #9897: AppInitMain: split initialization of Connman into a new function (master...connman) https://github.com/bitcoin/bitcoin/pull/9897
< luke-jr>
promag: for some reason, GitHub isn't showing me that part :|
< luke-jr>
oh well
< jtimon>
jl2012: not sure if you still want to do #11398 on top of #11426 since some people don't seem to agree it makes things easier, but rebased