< bitcoin-git>
bitcoin/master 69bfcac fanquake: gui: update Qt base translations for macOS release
< bitcoin-git>
bitcoin/master 14f8447 fanquake: Merge #19059: gui: update Qt base translations for macOS release
< bitcoin-git>
[bitcoin] fanquake merged pull request #19059: gui: update Qt base translations for macOS release (master...macdeploy_translations) https://github.com/bitcoin/bitcoin/pull/19059
< achow101>
for sqlite wallet, what do people think about keeping the name "wallet.dat" for them?
< achow101>
I'm inclined to say that that's a bad idea, but it does make things a lot easier
< fanquake>
achow101: what are you thinking instead?
< achow101>
fanquake: just keeping them named wallet.dat
< achow101>
it's trivial to discover the file type by checking magic numbers
< achow101>
my current implementation names them wallet.sqlite but that requires many checks in different places
< achow101>
it works but there's probably some edge cases and gotchas that'll break something
< tryphe>
achow101, i think it's fine. it's unlikely they'll need to know the underlying format, and seems easier for when they backup (if the new file has a different name, they might get confused about support for old bdb backup compatability, which name their wallet should have, etc.)
< luke-jr>
sqlite wallets don't need a directory, right?
< achow101>
luke-jr: no, but keeping that for consistency
< achow101>
actually, we probably still need to keep it to prevent 2 bitcoinds from opening the same wallet file
< tryphe>
ah, the bdb can be opened concurrently? i think bdb supports it but didn't know bitcoind would let you
< achow101>
bitcoind doesn't let you
< tryphe>
ahh
< achow101>
we have our own directory lock thing to stop that
< tryphe>
what about multiple daemons running with -wallet=/home/user/wallet.dat?
< achow101>
they shouldn't start
< tryphe>
not that most people would try that...
< luke-jr>
achow101: file locks should work fine?
< achow101>
luke-jr: file locks?
< achow101>
not sure how to detect if a file is opened by another process
< luke-jr>
flock
< achow101>
hmm
< luke-jr>
not even sure how one would lock a directory O.o
< achow101>
we make a .walletlock file and check it's existence before doing anything in that directory
< achow101>
same thing happens for a datadir
< gwillen>
I think portable file locking is a giant nightmare, probably lockfiles are still the way to go in 2020, sadly
< tryphe>
you know what would be nice.. access control list attributes like rwx permissions but with a fileIsLocked state
< tryphe>
all you'd need is 1 bit, right? there's got to be a spare bit somewhere
< bitcoin-git>
[bitcoin] fanquake opened pull request #19068: build: Use a zip instead of dmg for macOS releases (master...macdeploy_zip_instead_of_dmg) https://github.com/bitcoin/bitcoin/pull/19068
< elichai2>
Hi, It looks like if the utxoSet size > max_size it flushes all of it to disk and clears the hashmap, am I understanding correctly? I thought there was some heuristics for that (ie flushing only the oldest coins up to the max limit)
< sipa>
that would leave the cache in an inconsistent state
< sipa>
because we rely very heavily on an optimization: if a utxo is created and spent without being flushed to disk in between, it is just deleted, and will never touch disk
< sipa>
if you only write some changes from the cache to disk, you would ignore things that were created but spent already
< sipa>
so your disk would then not correspond to any well-defined point in time
< sipa>
if you mean we could write to disk, but not wipe those entries from the cache: that would work, but at least when i benchmarked it years ago, that was never worthwhile, because it would leave less memory available for the avoid-writing-entirely optimization i mentioned above
< sipa>
i had a design once that dealt with this, by accepting that the on-disk state corresponds to a mixture of changes from a range of blocks, and could correct for this by replaying at startup... but it's fairly complicated
< sipa>
(especially when there are reorgs in between)
< elichai2>
sipa: I think the "not worth it" is correct for a 500MB cache size, not let's say 8GB, where flushing 1GB to disk and leaving 7GB in RAM vs flushing 8GB to disk and leaving 0 in RAM
< wumpus>
cache flushes will be extremely rare with 8GB of cache though so amortized it's probably not too bad; also after flushing the data might still be in the disk cache so, I'd expect, quickly retrieved during validation in the blocks after it
< wumpus>
I used to think 'flush everything when the cache is full' was a problem for our caching as well but not so convinced anymore
< bitcoin-git>
[bitcoin] theStack opened pull request #19069: refactor: replace pointers by references within tx_verify.{h,cpp} (master...20200526-refactor-replace-pointers-by-refs-in-tx_verify) https://github.com/bitcoin/bitcoin/pull/19069
< bitcoin-git>
[bitcoin] jnewbery opened pull request #19070: p2p: Signal support for compact block filters with NODE_COMPACT_FILTERS (master...2020-05-node-compact-filters) https://github.com/bitcoin/bitcoin/pull/19070
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19071: [WIP RFC DONOTMERGE] meta: Separate repository for the gui (master...2005-splitRepoGui) https://github.com/bitcoin/bitcoin/pull/19071
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19072: doc: Expand section on Getting Started (master...2005-docContribClarif) https://github.com/bitcoin/bitcoin/pull/19072