< kallewoof> sipa: I had the same error yesterday. Tried restarting the job again today and now it seems to be working.
< promag> #18160 for 0.20?
< gribble> https://github.com/bitcoin/bitcoin/issues/18160 | gui: Avoid Wallet::GetBalance in WalletModel::pollBalanceChanged by promag · Pull Request #18160 · bitcoin/bitcoin · GitHub
< fanquake> promag: can you clarify if that is a bugfix?
< promag> not a bugfix, but rather a GUI improvement
< fanquake> ok
< promag> #15015
< gribble> https://github.com/bitcoin/bitcoin/issues/15015 | slow GUI with large wallets · Issue #15015 · bitcoin/bitcoin · GitHub
< promag> fanquake: fwiw it has 4 acks
< fanquake> promag: ok, I'll take a look this morning
< promag> I also think it could be backport in 0.19.1
< promag> thanks
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5504703a9f83...57a8fa9c3b44
< bitcoin-git> bitcoin/master f0dfac7 Sebastian Falbesoner: test: add executable flag for rpc_estimatefee.py
< bitcoin-git> bitcoin/master 57a8fa9 fanquake: Merge #18406: test: add executable flag for rpc_estimatefee.py
< bitcoin-git> [bitcoin] fanquake merged pull request #18406: test: add executable flag for rpc_estimatefee.py (master...20200322-test-add-executable-flag-for-rpc-estimatefee) https://github.com/bitcoin/bitcoin/pull/18406
< bitcoin-git> [bitcoin] practicalswift opened pull request #18407: tests: Add proof-of-work fuzzing harness (master...fuzzers-proof-of-work) https://github.com/bitcoin/bitcoin/pull/18407
< aj> instagibbs: #13990 if you're bored
< gribble> https://github.com/bitcoin/bitcoin/issues/13990 | Allow fee estimation to work with lower fees by ajtowns · Pull Request #13990 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] hebasto closed pull request #18387: gui: Fix segfault for loading and immediately unloading wallet (master...20200319-fix-modelwallet-segfault) https://github.com/bitcoin/bitcoin/pull/18387
< vasild> kallewoof: wrt #17994 - I assumed that we should first flush the block file to a persistent storage and afterwards flush the undo file (finalization not being relevant for this). Because in the case of a crash/power outage in between flushing both we could end up with a block on disk without undo, or with undo on disk without a block.
< gribble> https://github.com/bitcoin/bitcoin/issues/17994 | validation: flush undo files after last block write by kallewoof · Pull Request #17994 · bitcoin/bitcoin · GitHub
< vasild> and I assume we dont want the latter
< vasild> but now I can't find anything in the code that would brick if we have undo without a block
< vasild> https://github.com/bitcoin/bitcoin/blob/312d27b/src/validation.cpp#L4810 -- this code would get upset if it finds an undo without a block, hmm
< bitcoin-git> [bitcoin] vova557 opened pull request #18408: Bitcoin (master...master) https://github.com/bitcoin/bitcoin/pull/18408
< bitcoin-git> [bitcoin] fanquake closed pull request #18408: Bitcoin (master...master) https://github.com/bitcoin/bitcoin/pull/18408
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/57a8fa9c3b44...d478a737dbdd
< bitcoin-git> bitcoin/master fa01feb MarcoFalke: test: Remove ci timeout restriction in test_runner
< bitcoin-git> bitcoin/master fa92af5 MarcoFalke: ci: Run feature_block and feature_abortnode in valgrind
< bitcoin-git> bitcoin/master d478a73 MarcoFalke: Merge #18392: ci: Run feature_block in valgrind
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18392: ci: Run feature_block in valgrind (master...2003-ciMoreVal) https://github.com/bitcoin/bitcoin/pull/18392
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d478a737dbdd...97b0687501ce
< bitcoin-git> bitcoin/master 7c1ac70 practicalswift: tests: Don't assume presence of __builtin_mul_overflow in MultiplicationOv...
< bitcoin-git> bitcoin/master 97b0687 MarcoFalke: Merge #18393: tests: Don't assume presence of __builtin_mul_overflow(…) in...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18393: tests: Don't assume presence of __builtin_mul_overflow(…) in MultiplicationOverflow(…) fuzzing harness (master...multiplication-overflow-fixup) https://github.com/bitcoin/bitcoin/pull/18393
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #18380: doc: Remove html comment in PULL_REQUEST_TEMPLATE (master...2003-docGitHubTemplateNoComment) https://github.com/bitcoin/bitcoin/pull/18380
< kallewoof> vasild: Damn. I guess having undo without block is bad, even if there weren't any instances of badness happening. I wanted to keep this as simple as possible...
< vasild> just composing a comment on gh...
< kallewoof> vasild: But wait. We do have the block. It's just that we don't flush the block file. Or am I confused now?
< kallewoof> vasild: Block is written when it comes in, and later it is connected to tip and undo data is written.
< kallewoof> I guess no flush essentially means no guarantees that block was actually written or not, though...
< vasild> now, lets figure this out :)
< kallewoof> Thanks, your comment makes perfect sense.
< vasild> so, something like the crude patch in https://github.com/bitcoin/bitcoin/pull/17994/files#r395635091 would restore the order of flushing to blk,undo
< vasild> it can be simplified because at the time FlushBlockFile() is called thisUndoNeedsFlushingAndFinalizing == nLastBlockFile, so we can FlushUndoFile(nLastBlockFile, true).
< vasild> FlushBlockFile() flushes nLastBlockFile
< vasild> hmm
< vasild> there is a mutex protecting nLastBlockFile :/
< kallewoof> vasild: It feels like you can just use a flag. Kinda like https://github.com/bitcoin/bitcoin/pull/17994/commits/84ed7228b69a03c56dfd77bb0df84b39b77b5cea
< kallewoof> vasild: maybe I'm overengineering this
< vasild> yes, my thought, exactly!
< vasild> ^^ replying to your comment about the flag, not about overengineering ;-)
< * kallewoof> nodnods
< vasild> kallewoof: now the patch looks good to me, I will stare at it for some more time and will test it.
< kallewoof> Nice! :) I recompiled my running node and running this code on it now.
< hebasto> promag: mind separating a fix of #18362 from #18338 into its own pr?
< gribble> https://github.com/bitcoin/bitcoin/issues/18362 | gui: segfault unloading and immediately reloading wallet with gui · Issue #18362 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/18338 | Fix wallet unload race condition by promag · Pull Request #18338 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jnewbery opened pull request #18410: Docs: Improve commenting for coins.cpp|h (master...2020-03-coins-comments) https://github.com/bitcoin/bitcoin/pull/18410
< stevenroose> Are genesis txs included in the txindex?
< stevenroose> Is it possible something regarding that changed between 0.17 and 0.18? (I know it's a stretch :p)
< fjahr> stevenroose: You mean the genesis coinbase tx, right? It is not in the utxo set and it should also not be in txindex. It was never indexed by satoshis original software and changing it would be a change in consensus rules, however unlikely it is that that output is spent. So I doubt there were any changes, although I don't know. See also the discussion here: https://github.com/bitcoin/bitcoin/issues/3303
< stevenroose> fjahr: k thanks
< stevenroose> I know it's not in the UTXO set. But it might have been indexed. But so it appears not.
< fjahr> Yeah, it is skipped here: https://github.com/bitcoin/bitcoin/blame/master/src/index/txindex.cpp#L250 The changes you might be referring to are probably the rewrite of the indexing code by jimpo but that should not have changed behavior.
< stevenroose> Hmm, ed12d5df1ba52b5ef3dd3799de26bb5e1d3fc654 seems to have introduced that in 2018
< bitcoin-git> [bitcoin] theStack opened pull request #18412: script: fix SCRIPT_ERR_SIG_PUSHONLY error string (master...20200323-fix-script-err-sig-pushonly-error-message) https://github.com/bitcoin/bitcoin/pull/18412
< fjahr> stevenroose: ah, true, interesting. So it was a bug for some amount of time: https://github.com/bitcoin/bitcoin/pull/14085
< fjahr> and the blockfilter headers where want made the fix actually get in, TIL
< fjahr> s/want/what/
< gleb> We don't have any shared policy for dns seeder implementations for rate-limiting, do we? There's no expectation that "one client ip will send at most 1 request per minute" or whatever? sipa
< sipa> that sounds like a client policy, not a seeder policy.
< sipa> as in: the seeder can't prevent people from querying more than once per minite
< sipa> *minute
< luke-jr> well, it can ignore floods
< luke-jr> no reason for a shared policy on that tho
< luke-jr> gleb: also note that clients don't talk to the seed itself; they talk to DNS servers (typically run by their ISP), and that will query and cache from the seed
< sipa> honest clienta do :)
< gleb> I'm implementing DNS cache invalidation triggering by reachable (thus already known) nodes, and I think it makes sense to query like 10 different services (legacy, segwit, BLOOM), etc.
< luke-jr> sipa: you'd need to go out of your way to bypass it and go direct; and there's no benefit in doing so?
< gleb> And I was wondering if your seeders would be angry if someone from the same endpoint asks 10 requests at once for different service combinations
< sipa> gleb: they wouldn't know
< sipa> luke-jr: if you want to DoS attack the seeders, you'd want to connect to them directly i meam
< luke-jr> I don't understand why you would do that
< luke-jr> sipa: oh, true
< gleb> luke-jr: so that private nodes hit early caches more often
< sipa> gleb: i don't understanx what you're trying to do, though
< gleb> sipa: i think we were discussing this the other day
< luke-jr> gleb: I don't get it.
< sipa> gleb: DNS seeds should only be queried when addrman is low, as a fallback
< sipa> (not as a last resort like hardcoded seeds, but usually nodes shouldn't be contacting them at all if they're run before and have healthy number of connections)
< gleb> sipa: or on the first start.
< luke-jr> "if they've run before"
< sipa> yeah
< sipa> i also don't understand why you're querying for multiple services
< gleb> sipa: Do you understand why I want to do it in the first place? (ignoring multiple services)
< sipa> no
< gleb> luke-jr Managed to explain this to sipa via quoting greg from that day :)
< gleb> "I wonder if listening nodes who are getting incoming connections should randomly query dnsseeds to keep upstream caches primed, but throwing out the results (or comparing to their addrman, logging if there are a bunch of results they don't now about, then throwing away the results). Those nodes are already not anonymous by virtue of sucessfully
< gleb> listening, so they don't gain anything by trying"
< luke-jr> hmm
< luke-jr> I don't know if there's actually value to priming caches tho?
< luke-jr> even a few seconds delay querying isn't going to matter..
< sipa> luke-jr: it's a privacy gain too, as it means private nodes would reveal less to the seeders, if they're coming from a network with public nodes
< gleb> I'd say privacy gain has more value than little latency decrease in this context.
< luke-jr> sipa: reveal what?
< sipa> luke-jr: e.g. the network that the private node is in
< sipa> i wouldn't be surprised if more things can be inferred from the DNS query
< luke-jr> sipa: more queries on that same network won't hide it..
< sipa> queries from nodes that are already public
< luke-jr> the seed doesn't know if they are or aren't..
< sipa> ?
< sipa> the seed has a database of public IPs already, even when it is honest
< luke-jr> what is more queries supposed to do?
< sipa> i don't know what there is to explain
< sipa> or what you're missing
< gleb> sipa: I had the same feeling 10 minute ago with you too :)
< luke-jr> the seed knows <DNS server> made a query. <DNS server> serving more clients doesn't tell or conceal from the seed anything
< sipa> gleb: well "cache invalidation" was very confusing! there is no cache invalidation going on at all :)
< luke-jr> I suppose the querying of more service bit combos might conceal what clients using the DNS server are interested in.. but that's just as easily solved by the client using the DNS seed making multiple queries
< luke-jr> (perhaps even more reliably!)
< sipa> luke-jr: when a DNS seed sees a query from a DNS server, it has a better than average guess that there is a private node in that DNS server's network
< sipa> if the public nodes in that network keep the cache fresh, that changes to "seeing a query has a high probability of there being either private or public nodes in that network"... but the public nodes are already public
< luke-jr> it could already be public or private
< luke-jr> oh, except public nodes are already running
< luke-jr> not sure that matters actually
< sipa> that makes it much stronger (public nodes in general query much less frequently), but I don't think that's actually necessary for the argument
< sipa> i think it's still a privacy improvement to private nodes without that
< luke-jr> I don't
< sipa> imagine some networks have just 1 private node; some have just one public node; some have both; right now, assume both query the seed equally frequently
< sipa> that means if a seed now sees a query from a DNS server, it has a 50/50 guess about whether there is a private or public node behind it
< luke-jr> if there are public nodes on the same DNS-server-network, the seed has no idea if it was one of them already
< luke-jr> 50/50 seems like about the best we could hope for?
< sipa> if we now change the public nodes to query 10x more frequently, the information the seed gets about whether there is a private node when seeing a query goes down to 10% ish
< sipa> luke-jr: no, because the public nodes are already public
< sipa> they don't care about hiding their existence
< luke-jr> 90/10 means the seed can reliably determine if there is a private node querying..
< luke-jr> semi-reliably*
< sipa> how so?
< luke-jr> look at deviations in the query pattern?
< luke-jr> and DNS servers without a public node become very obvious
< sipa> sure
< sipa> but the ones in a network with public ones are very reliably hidden
< luke-jr> hmm, forgot caching is like an hour
< luke-jr> I wonder if the private nodes just querying every hour themselves would have the same effect
< luke-jr> maybe counter-productive if they're not 24/7 tho
< moneyball> hi. fyi only 8 people responded "yes" to the survey for still doing a CoreDev virtually. therefore i didn't do any planning around this. obviously if contributors would like to self-organize in small remote groups, by all means.
< provoostenator> moneyball: thanks for trying to coordinate! Hopefully we can do an in-person meetup again after the apocalypse.
< bitcoin-git> [bitcoin] pierreN opened pull request #18413: script: prevent UB when computing abs value for num opcode serialize (master...fix-script-absolute) https://github.com/bitcoin/bitcoin/pull/18413
< bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/97b0687501ce...ac579ada7e83
< bitcoin-git> bitcoin/master 77e4b06 Russell Yanofsky: refactor: Get rid of Wallet::IsWalletFlagSet method
< bitcoin-git> bitcoin/master 1c2ab1a Russell Yanofsky: refactor: Rename Node::disconnect methods
< bitcoin-git> bitcoin/master 6ceb219 Russell Yanofsky: refactor: Rename Chain::Notifications methods to be consistent with other ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18278: interfaces: Describe and follow some code conventions (master...pr/ipc-conv) https://github.com/bitcoin/bitcoin/pull/18278