< fanquake> wumpus / sipa: can you block allunderone from the devwiki
< bitcoin-git> [bitcoin] fanquake closed pull request #20570: Logo added to the readme file. (master...master) https://github.com/bitcoin/bitcoin/pull/20570
< bitcoin-git> [bitcoin] SoiledCold5 opened pull request #20574: Update README.md (master...patch-2) https://github.com/bitcoin/bitcoin/pull/20574
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/751ffaabad82...f35e4d906fee
< bitcoin-git> bitcoin/master 667b6a2 Hennadii Stepanov: ci: Adjust Cirrus CI task names (follow up)
< bitcoin-git> bitcoin/master f35e4d9 MarcoFalke: Merge #20572: ci: Adjust Cirrus CI task names (follow up)
< Arvidt> Since I upgraded from 0.20.1-x86_64-linux-gnu to 0.21.0rc2-x86_64-linux-gnu I do not get any inbound connections anymore.
< Arvidt> Is this a known issue?
< Arvidt> (bitcoin.conf: server=1 onlynet=onion onion= listen=1)
< 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
< gwillen> that was awhile ago but I can imagine there are smaller things in the same genre
< Arvidt> Thanks Wumpus, will see how v3 gossip will evolve. Fascinating to observe.
< wumpus> Arvidt: it's a good test :)
< Arvidt> Ah, found the v3 inbound issue report here: https://github.com/bitcoin/bitcoin/issues/20555
< wumpus> gwillen: the infamous hacktoberfest t-shirt
< gwillen> yeah
< bitcoin-git> [bitcoin] laanwj closed pull request #20574: Update README.md (master...patch-2) https://github.com/bitcoin/bitcoin/pull/20574
< jonatack> Arvidt: just PMed you as well
< 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] theStack closed pull request #20537: refactor: replace manual Satoshis-to-BTC conversions with FormatMoney() (master...20201129-use-formatmoney) https://github.com/bitcoin/bitcoin/pull/20537
< hebasto> mind blocking Humblya in git? looks like a spam.
< wumpus> done
< bitcoin-git> [bitcoin] vova557 opened pull request #20578: Добавить лицензию (master...patch-9) https://github.com/bitcoin/bitcoin/pull/20578
< 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
< bitcoin-git> [bitcoin] sipa closed pull request #20578: Добавить лицензию (master...patch-9) https://github.com/bitcoin/bitcoin/pull/20578
< promag> hebasto: what's the motivation for #20205?
< gribble> https://github.com/bitcoin/bitcoin/issues/20205 | wallet: Properly support a wallet id by achow101 · Pull Request #20205 · bitcoin/bitcoin · GitHub
< luke-jr> promag: wrong PR?
< 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
< promag> luke-jr: right, I mean #20243
< gribble> https://github.com/bitcoin/bitcoin/issues/20243 | rpc, wallet: Expose wallet id in getwalletinfo RPC output by hebasto · Pull Request #20243 · bitcoin/bitcoin · GitHub
< promag> seems a bit premature, thats all
< luke-jr> I guess it makes sense to expose it
< 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> aha i see
< sipa> *deciding
< sipa> (also bitcoin core itself has always ignored unknown messages
< 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