Since v0.21 hidden services use the longer v3 address format.
It may make sense to backport this to the v0.21 branch, although onion nodes can always use the non-onion seeds.
Since v0.21 hidden services use the longer v3 address format.
It may make sense to backport this to the v0.21 branch, although onion nodes can always use the non-onion seeds.
cc @kallewoof
What is this patch doing? Does it somehow embed the v2 onion in a v3 onion? Does this depend on the operator upgrading the node?
Might be smart to add the names of the seed maintainers in comments as per mainnet/testnet DNS seeds.
Ah, I see. So the v2 one is probably not reachable anymore.
Concept ACK 3e6657a14d501c6315ab46ffe7d204684491c710
Concept ACK
Although I would keep both v2 and v3 and skip v2 followup PR when v2 finally fades out. @Sjors tyi, in case the v2 v3 addresses are connected to a node of u , both addresses where down and unreachable over Tor, tested, short before i wrote these lines
I'm also unable to connect to the host
$ nc -v -x 127.0.0.1:9050 v7ajjeirttkbnt32wpy3c6w3emwnfr3fkla7hpxcfokr3ysd3kqtzmqd.onion 38333
…
nc: connection failed, SOCKSv5 error: General SOCKS server failure
ACK otherwise.
It's indeed my own seed node. Didn't want to doxx myself, but it's obvious from context anyway. Indeed the v2 is offline since afaik we don't support running both on the same node.
I'm having difficulty connecting to the service as well, but this is the onion its advertising.
For some reason when I restart it sometimes complains Cannot create socket for ntv3mtqw5wt63red.onion:38333: unsupported network, even though I'm running v0.21.0rc3 and ~/.bitcoin/signet/onion_v3_private_key exists. Actually, that's probably just the node trying to make an outbound connection to the v2 address seed.
I guess it's just a bit flaky, it connects now: Connection to v7ajjeirttkbnt32wpy3c6w3emwnfr3fkla7hpxcfokr3ysd3kqtzmqd.onion 38333 port [tcp/*] succeeded!
@Sjors tyi, @jb55 had a post on Twitter about onion balancing https://onionbalance.readthedocs.io/en/latest/ Maybe that is something u can use to make it more stable.
I had also with node the phenomena that old addresses linger in peer.dat and want to connect at random. A fresh peers,dat solved that.
Had a first thought that load balancing V3 in general for Bitcoin onion services could be a good idea. If there is interest, i could do a draft PR that integrates that into our torcontrol.cpp
It connects for me now. ACK 3e6657a14d501c6315ab46ffe7d204684491c710
Backported in #20669