< bitcoin-git> [bitcoin] fanquake pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/7ae86b3c6845...2e1336dbfe8a
< bitcoin-git> bitcoin/master 2dde557 fanquake: depends: build bdb with -std=c++17
< bitcoin-git> bitcoin/master 2374f2f fanquake: depends: build Boost with -std=c++17
< bitcoin-git> bitcoin/master e2c5006 fanquake: depends: build zeromq with -std=c++17
< bitcoin-git> [bitcoin] fanquake merged pull request #20471: build: use C++17 in depends (master...depends_c++17) https://github.com/bitcoin/bitcoin/pull/20471
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2e1336dbfe8a...817aeca57a4c
< bitcoin-git> bitcoin/master 830ddf4 Hennadii Stepanov: Drop noop gcc version checks
< bitcoin-git> bitcoin/master 817aeca fanquake: Merge #20491: refactor: Drop noop gcc version checks
< bitcoin-git> [bitcoin] fanquake merged pull request #20491: refactor: Drop noop gcc version checks (master...201125-gcc) https://github.com/bitcoin/bitcoin/pull/20491
< willcl_ark> luke-jr: I've been trying out ripgrep recently. It can handle multiple directories and seems to be pretty fast. e.g. `rg CTxDestination bitcoin*` will search all directories in current dir starting with bitcoin.
< willcl_ark> There's also an interesting writeup of a 'speedtest' here FYI https://blog.burntsushi.net/ripgrep/
< sipa> i've never had a situation where "git grep" in the bitcoin repo wasn't fast enough
< willcl_ark> Agreed. I imagined Luke might be trying to grep bitcoin and bitcoin-gui repos at the same time, and using some small script to bolt together two git searches? Not familiar with git-grep-all tbh :)
< luke-jr> willcl_ark: git-grep-all searches all objects in the repo
< luke-jr> sipa: ^
< willcl_ark> Ah I see luke-jr, thanks. Then ripgrep will not be able to help you as it can't search all repo objects.
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/817aeca57a4c...81d5af42f4db
< bitcoin-git> bitcoin/master 4848e71 practicalswift: scripted-diff: Use [[nodiscard]] (C++17) instead of NODISCARD
< bitcoin-git> bitcoin/master 79bff8e practicalswift: Remove NODISCARD
< bitcoin-git> bitcoin/master 81d5af4 MarcoFalke: Merge #20499: Remove obsolete NODISCARD ifdef forest. Use [[nodiscard]] (C...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20499: Remove obsolete NODISCARD ifdef forest. Use [[nodiscard]] (C++17). (master...remove-nodiscard-cruft) https://github.com/bitcoin/bitcoin/pull/20499
< hebasto> sipa: does your ip address crawler see tor v3 addresses in the main network due to rc2 has been published last week?
< sipa> hebasto: no
< sipa> hebasto: PRs welcome
< hebasto> sipa: thanks
< sipa> oh wait
< sipa> it can't even expose them over DNS
< hebasto> DNS restrictions?
< sipa> well there is no space for onion addresses in IPv6
< sipa> *v3
< luke-jr> TXT?
< luke-jr> SRV might be a good fit actually
< luke-jr> or URI record
< pinheadmz> pretty clever
< sipa> can standard resolvers query SRV records?
< pinheadmz> what do you mean? the rfc is 20 years old, i think if the nameserver has an SRV record you can dig it
< pinheadmz> trying to find a live example
< pinheadmz> actually the exmple in bolt 10 works
< pinheadmz> dig lseed.bitcoinstats.com SRV
< sipa> pinheadmz: i mean, you can't just use getaddrinfo to retrieve it, can you?
< sipa> you actually need a DNS client library
< pinheadmz> ah i see
< luke-jr> well, presuambly we're not using getaddrinfo with Tor
< luke-jr> so the real question is if Tor can do it ;)
< sipa> we don't use DNS at all over Tor
< luke-jr> …wasn't that the topic?
< sipa> instead we use getaddr peers (just connect by name to a DNS seed, using the P2P protocol, do a getaddr, and wait for an addr response)
< sipa> luke-jr: what currently works for torv2 but not torv3 is learning about them over IPv4/IPv6 from seed nodes
< sipa> but maybe that's not all that important a use case
< pinheadmz> sipa when we use DNS seeds, we don't make a DNS request to the seed?
< sipa> pinheadmz: no, we *resolve* the seed
< sipa> and it resolves to one or more IP addresses
< pinheadmz> ah, TIL so there is no `dig bitcoin.sipa.de` or whatever. I always thought we use A records from the seed to bootstrap
< sipa> doing so likely makes your OS's/ISP's resolver connect to the DNS seed server, but that's transparent from bitcoin core's perspective
< sipa> all it sees is looking up a name, and getting IP addresses back, using your OS's name resolving functionality
< pinheadmz> actually im not getting anything from seed.bitcoin.sipa.be but I am from `dig dnsseed.bluematt.me`
< pinheadmz> so when we bootstrap we use DNS to get a bunch of A records, then add those IPs to addrman and start connecting
< sipa> yeah
< sipa> but from bitcoin core's perspective there is no such thing as A or AAAA or CNAME or whatever records or DNS involved
< pinheadmz> yeah
< sipa> it asks for a name, and get IPv4 and IPv6 addresses back from the OS
< sipa> they could be coming from your local /etc/hosts file instead
< pinheadmz> but over tor we connect directly to the "seed" and do a getaddr
< sipa> yes, because you can't do DNS resolving over Tor (that'd require a DNS implementation in bitcoin core, and route it over tor)
< sipa> instead we just "connect" to the seed, which makes the Tor exit node do the resolving - *not* tell us the result of that resolving - but instead forwarding our connection to it
< pinheadmz> oh I see, so it still may not be the full node at bitcoin.sipa.be that we conenct to, but any one of the nodes returned in A records to the exit node, which thinks we are just resolving a single service by name
< sipa> seed.bitcoin.sipa.be may not even *have* a full node
< pinheadmz> gotcha
< sipa> or maybe it's more accurate to say it "has" many full nodes, namely all the IPs it resolves to
< sipa> but none of them are particularly likely to be operated by the operator of the DNS seed itself
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20535: test: Fix intermittent feature_taproot issue (master...2011-testTapInt) https://github.com/bitcoin/bitcoin/pull/20535
< phantomcircuit> sipa, because they don't fit in ipv6 records i don't think there's anyway to return them that will be cached by intermediate servers, which is probably what really matters
< phantomcircuit> otherwise could just use the bootstrap peer mechanism
< sipa> phantomcircuit: right
< bitcoin-git> [bitcoin] achow101 opened pull request #20536: wallet: Error with "Transaction too large" if the funded tx will end up being too large after signing (master...fundtx-error-large-tx) https://github.com/bitcoin/bitcoin/pull/20536