It appears that one can specify multiple -externalip= -- for example, to specify multiple tor HS addresses, as it's a std::map and the access element  operator creates a new entry if one does not exist; Is this the case? The logic is splayed out a bit.
(Asking because I think adding torv3 addresses to my nodes would be more palatable if I can retain my (ancient, mined) v2 addresses still.
won't be useful until they can be rumoured using BIP155
< * luke-jr>
assumes midnight means after it's merged :p
sipa: I like these changes. +1 vasild <3
midnight: also, yes, you can set multiple local addresses with -externalip; the one that will be rumoured to peer X is the most compatible one (using some heuristics; if there are multiple ones, the one which we've seen the most incoming connections to)
I saw that logic too. I failed to verify on top of that that rumouring would include a torv3. I'm okay with it in either event. Yeh, I like these changes going in. Neat stuff.
has anyone taken a look at #19598? i think i kind of understand what he's saying and it looks important
Command to reproduce the "./fs.h:14:10: fatal error: filesystem: No such file or directory" error is: `~/work/bitcoin$ ./autogen.sh && ./configure --enable-zmq --with-gui=qt5 --enable-glibc-back-compat --enable-reduce-exports --enable-c++17 --enable-debug CFLAGS="-g0 -O2 -funsigned-char" CXXFLAGS="-g0 -O2 -funsigned-char" --with-boost-process && make`
The goal is just to verify whether `-lstdc++fs` has an effect or not to document it and thus move the PR an inch forward.
wumpus, ^ friendly ping
Not sure if this was brought up, but the GUI repo is lagging by about a week.
Which causes PR's to have a whole bunch of old commits in them (at least when they're rebased on the main repo's master, which is what I do)
Wrt the next bip155/torv3 PR, assuming #19845 gets merged - #19031 has two more commits "net: CAddress & CAddrMan: (un)serialize as ADDRv2" (+193/-15) and "net: advertise support for ADDRv2 via new message" (+129/-8). Then we will have done BIP155 - will gossip torv3/i2p/cjdns addresses if we receive them (even though we may not be able to make use of them yet). After that we need one more change
to create torv3 hidden service instead of torv2 one, which is the topmost commit in #19954 (+27/-6). This will conclude TORv3 support. I plan (planned) to open 3 PRs for those to ease reviews (one for each commit). However I noticed that it takes lots of time after a PR is opened for reviewers to start looking at it. Once reviewers are engaged it starts rolling (either big or small). So I wonder