< Arvidt>
Did not find a bug in github regarding this.
< sipa>
Arvidt: are you relying on the tor autoconfiguration?
< sipa>
in that case, 0.21 likely upgraded to a v3 onion service, and there are currently very few nodes capable of connecting to those
< Arvidt>
Thanks, Sipa. Yes, I have Tor cookie auth, and IIRC so Bitcoind can automatically announce it's Onion Service (legacy name hidden service). I see in bitcoind log:
< Arvidt>
tor: Got service ID s5om67..., advertising service s5om67....onion:8333
< Arvidt>
AddLocal(s5om67....onion:8333,4)
< Arvidt>
The Onion Service has a v3 looong address
< wumpus>
fanquake: done
< wumpus>
yes, it will take a while to bootstrap torv3 use
< wumpus>
and it's currently hard to 'meet' other torv3 nodes especially if your peer doesn't know any torv3 nodes yet
< wumpus>
PMed you a torv3 node
< wumpus>
is there some new scheme that pays out per commit or something? what's with the one line changes to README.md
< jonatack>
Arvidt: yup, i have had no inbounds on my tor v3 service since a month or so, except for hebasto in both my inbounds and outbounds as we addnode each other
< wumpus>
bah, would it maybe make sense to add some default v3 bootstrap peers, at least temporarily, to bootstrap this, otherwise 0.21+ needs to be widely adopted before peers with addrv2 gossipping find each other randomly at meast moderately often
< wumpus>
maybe this works out organically i don't know
< bitcoin-git>
[bitcoin] hebasto reopened pull request #19832: p2p: Put disconnecting logs into BCLog::NET category (master...200829-log) https://github.com/bitcoin/bitcoin/pull/19832
< jonatack>
sigh
< jonatack>
wumpus: it might make sense, temporarily
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20575: Do not run functions with necessary side-effects in assert() (master...side-effect-free-assert) https://github.com/bitcoin/bitcoin/pull/20575
< bitcoin-git>
[bitcoin] theStack opened pull request #20577: doc: libconsensus: add missing error code description, fix NBitcoin link (master...201212-doc-libbitcoinconsensus-fixes) https://github.com/bitcoin/bitcoin/pull/20577
< bitcoin-git>
[bitcoin] promag opened pull request #20580: wallet: Some cleanups around LegacyScriptPubKeyMan (master...2020-12-wallet-legacy) https://github.com/bitcoin/bitcoin/pull/20580
< luke-jr>
promag: unique wallet IDs allow warning the user if you try to open two copies of the same wallet, maintaining prune locks for them even when unloaded, etc
< pinheadmz>
at the meeting this week there was talk about btcd and libbitcoin disconnecting on unkown p2p message types. i think bcoin does this as well, but that behavior could be changed. does Bitcoin Core have another way to mitigate spam attacks with unknown messages? or is it not a concern because they are simply not processed?
< sipa>
pinheadmz: unknown messages are never worse than spamming with known messages
< pinheadmz>
makes sense, no computational cost
< pinheadmz>
but theres no kind of overall bandwidth rate limit for peers ?
< sipa>
no, but there could be
< sipa>
not a hard limit, but we could always deprioritize processing messages from the most demanding peers when resources are low
< pinheadmz>
and whats the drawback to tying addrv2 to a protocol version bump ?
< sipa>
pinheadmz: central coordination on what every protocol version means
< sipa>
it's so bizarre to me
< pinheadmz>
i see yeah reading up the chatter on bip155 PR as well...
< sipa>
it seems everyone working on bitcoin core feels this is weird and makes things harder for alternative implementations
< sipa>
and all alternative implementations are confused why we do this!
< pinheadmz>
weird / bizarre = using central coordination on protocol versions ?
< sipa>
bitcoin core shouldn't be decided what messages are allowed on the network
< pinheadmz>
yeah i noticed that, i dunno why bcoin didnt implement the same way
< pinheadmz>
its not a ban, but its an assert(false) in message handler which i believe disconencts the peer
< sipa>
i can see why someone would think that it feels "wrong" to allow unknown messages
< sipa>
but there really is no downside
< pinheadmz>
re: coordination though - BIPs are good places to pick service bits, etc at the community level - thats not really "bitcoin core deciding:
< pinheadmz>
still i agree ignoring unkown messages is the simplest way to make the protocl extensible
< sipa>
pinheadmz: service oks, those require coordination
< sipa>
but protocol versions are worse, as they're sequential
< sipa>
and there is no functional difference between "sending an empty message to announce feature support" vs setting a service bit, except that service bits are more limited (only 64), and are rumoured (which only matters for feature discovery)
< bitcoin-git>
[bitcoin] promag closed pull request #20580: wallet: Some cleanups around LegacyScriptPubKeyMan (master...2020-12-wallet-legacy) https://github.com/bitcoin/bitcoin/pull/20580