< 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.
< 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>
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 :/
< 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>
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