< bitcoin-git> [bitcoin] kallewoof closed pull request #20154: BIP-322 support (master...202010-bip322) https://github.com/bitcoin/bitcoin/pull/20154
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d875bcc8f9ac...069f37c0fd42
< bitcoin-git> bitcoin/master 8f9ca31 Jon Atack: p2p: remove unused legacyWhitelisted variable
< bitcoin-git> bitcoin/master 069f37c MarcoFalke: Merge #20791: p2p: remove unused legacyWhitelisted in AcceptConnection()
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20791: p2p: remove unused legacyWhitelisted in AcceptConnection() (master...rm-unused-legacyWhitelisted) https://github.com/bitcoin/bitcoin/pull/20791
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/069f37c0fd42...f1f26b8d5bae
< bitcoin-git> bitcoin/master 546a076 practicalswift: fuzz: Fill various small fuzzing gaps
< bitcoin-git> bitcoin/master 4ddbcd0 practicalswift: fuzz: Add coverage for CDataStream consumer
< bitcoin-git> bitcoin/master f1f26b8 MarcoFalke: Merge #20377: fuzz: Fill various small fuzzing gaps
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20377: fuzz: Fill various small fuzzing gaps (master...fuzzers-2020-11-12) https://github.com/bitcoin/bitcoin/pull/20377
< bitcoin-git> [bitcoin] jonatack opened pull request #20797: consensus: fix maybe uninitialized CTxMemPool::GetIter() (master...fix-txmempool-maybe-uninitialized-txiter) https://github.com/bitcoin/bitcoin/pull/20797
< bitcoin-git> [bitcoin] BTC100x opened pull request #20798: Seed Creation (master...master) https://github.com/bitcoin/bitcoin/pull/20798
< bitcoin-git> [bitcoin] jnewbery opened pull request #20799: net processing: Only support compact blocks with witnesses (master...2020-12-remove-cmpctblock-v1) https://github.com/bitcoin/bitcoin/pull/20799
< bitcoin-git> [bitcoin] fanquake closed pull request #20798: Seed Creation (master...master) https://github.com/bitcoin/bitcoin/pull/20798
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20800: Revert "Don't send 'sendaddrv2' to pre-70016 software" (master...2012-netRevertSendaddrv2Workaround) https://github.com/bitcoin/bitcoin/pull/20800
< jonatack> \o/
< jamesob> hey maintainers, anything left to be done on #19806? not sure if the tsan failure there is spurious; afaict nothing related has changed since the last successful run
< gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
< TallTim> I know this is a long shot, but anyone know what happened to bitcoinhackers.org Mastodon instance? Its been returning blank pages for a few days. luke-jr - you're on there, do you know?
< luke-jr> TallTim: off-topic here
< luke-jr> but it's working fine for me
< bitcoin-git> [bitcoin] jonatack closed pull request #20797: consensus: fix maybe uninitialized CTxMemPool::GetIter() (master...fix-txmempool-maybe-uninitialized-txiter) https://github.com/bitcoin/bitcoin/pull/20797
< TallTim> luke-jr - wonderful.
< bitcoin-git> [bitcoin] prayank23 closed pull request #20393: error if invalid chars in wallet name (master...wallet-name) https://github.com/bitcoin/bitcoin/pull/20393
< bitcoin-git> [gui] RandyMcMillan opened pull request #167: raise helpMessageDialog (master...help-message-raise) https://github.com/bitcoin-core/gui/pull/167
< ariard> is anyone aware of bitcoin clients not respecting the tx-request sequence and directly broadcasting unrequested txn to their peers ?
< phantomcircuit> ariard, iirc bitcoin never does that but various modified clients do
< phantomcircuit> some are malicious others are just dumb
< ariard> phantomcircuit: thanks, so we should be pretty careful not breaking them, at least give a release cycle of reprieve
< phantomcircuit> im also not sure the core concept of ignoring those transactions makes a lot of sense
< phantomcircuit> messages from peers are handled round robin so the worst an attacker can do is add latency and make one core run at 100%
< ariard> quite agree, if a malicious peer is aiming to CPU DoS you, forcing them to send an inv first to then submit a junk tx isn't that much stretching the barrier
< sipa> i'm not so much worried about such clients on the public network (we'd know, or at least be able to add monitoring for that to figure out), but there could be software communicating locally with bitcoin core (things like joinmarket, lightning clients, indexers, ...), for which we wouldn't really know
< sipa> of course, perhaps one generally sets PF_RELAY for those or so