< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/24f70290642c...14f844777746
< 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] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/14f844777746...7d32cce3e75b
< bitcoin-git> bitcoin/master 3bdc7c2 John Newbery: [doc] Add comment for m_headers_cache
< bitcoin-git> bitcoin/master f6b58c1 Jim Posen: [net processing] Message handling for getcfheaders.
< bitcoin-git> bitcoin/master 5308c97 Jim Posen: [test] Add test for cfheaders
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19010: net processing: Add support for getcfheaders (master...2020-05-cfheaders) https://github.com/bitcoin/bitcoin/pull/19010
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7d32cce3e75b...d3b0ef80f653
< bitcoin-git> bitcoin/master f9b22e3 practicalswift: tests: Add fuzzing harness for CCoinsViewCache
< bitcoin-git> bitcoin/master d3b0ef8 MarcoFalke: Merge #18867: tests: Add fuzzing harness for CCoinsViewCache
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18867: tests: Add fuzzing harness for CCoinsViewCache (master...fuzzers-coins_view) https://github.com/bitcoin/bitcoin/pull/18867
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d3b0ef80f653...13397dc78fd6
< bitcoin-git> bitcoin/master fa7fc5a MarcoFalke: rpc: factor out RpcInterruptionPoint from dumptxoutset
< bitcoin-git> bitcoin/master fa75692 MarcoFalke: rpc: Make gettxoutsetinfo/GetUTXOStats interruptible
< bitcoin-git> bitcoin/master 13397dc MarcoFalke: Merge #19056: rpc: Make gettxoutsetinfo/GetUTXOStats interruptible
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19056: rpc: Make gettxoutsetinfo/GetUTXOStats interruptible (master...2005-rpcInterrupt) https://github.com/bitcoin/bitcoin/pull/19056
< bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/13397dc78fd6...fe1357a03af1
< bitcoin-git> bitcoin/master 458992b Hennadii Stepanov: Prevent UB in DeleteLock() function
< bitcoin-git> bitcoin/master 8d8921a Hennadii Stepanov: refactor: Add LockStackItem type alias
< bitcoin-git> bitcoin/master f511f61 Hennadii Stepanov: refactor: Add LockPair type alias
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18881: Prevent UB in DeleteLock() function (master...200505-cofu) https://github.com/bitcoin/bitcoin/pull/18881
< andrewtoth> I did some rudimentary benchmarking on the connecting blocks with a cleared cache and it does seem to have a performance impact https://github.com/bitcoin/bitcoin/pull/18941#issuecomment-633684774
< elichai2> wumpus: thanks
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/fe1357a03af1...dcacea096e02
< bitcoin-git> bitcoin/master 65c589e Pieter Wuille: Convert Qt to new serialization
< bitcoin-git> bitcoin/master ef17c03 Pieter Wuille: Convert wallet to new serialization
< bitcoin-git> bitcoin/master 92beff1 Pieter Wuille: Convert LimitedString to formatter
< bitcoin-git> [bitcoin] laanwj merged pull request #19032: Serialization improvements: final step (master...202005_noncastserial_final) https://github.com/bitcoin/bitcoin/pull/19032
< troygiorshev> ping
< troygiorshev> whoops, wrong window
< 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
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/dcacea096e02...4af01b37d402
< bitcoin-git> bitcoin/master fab4737 MarcoFalke: test: pep-8 p2p_getdata.py
< bitcoin-git> bitcoin/master 999922b MarcoFalke: test: Default mininode.wait_until timeout to 60s
< bitcoin-git> bitcoin/master fa80b47 MarcoFalke: test: Remove global wait_until from p2p_getdata
< bitcoin-git> [bitcoin] laanwj merged pull request #19060: test: Remove global wait_until from p2p_getdata (master...2005-testWaitUntilGetdata) https://github.com/bitcoin/bitcoin/pull/19060
< bitcoin-git> [bitcoin] elichai opened pull request #19073: Remove outdated comment about DER encoding (master...2020-05-remove-der-comment) https://github.com/bitcoin/bitcoin/pull/19073
< bitcoin-git> [bitcoin] dongcarl closed pull request #18644: net: Reduce `TransportDeserializer` interface to 2 methods (master...2020-04-transport-readmessages) https://github.com/bitcoin/bitcoin/pull/18644
< bitcoin-git> [bitcoin] practicalswift opened pull request #19074: tests: Use BasicTestingSetup to initialise fuzzing environment (master...fuzzers-2020-05-26) https://github.com/bitcoin/bitcoin/pull/19074
< bitcoin-git> [bitcoin] za-kk closed pull request #18313: gui: fix font inconsistency on send coins form (master...march-gui-font) https://github.com/bitcoin/bitcoin/pull/18313