00:06 <bitcoin-git> [bitcoin] theStack opened pull request #29390: test: speedup bip324_crypto.py unit test (master...202402-speedup_bip324_cipher_python_tests) https://github.com/bitcoin/bitcoin/pull/29390

00:09 <bitcoin-git> [btcdeb] kallewoof merged pull request #143: fix ‘runtime_error’ is not a member of ‘std’ build error (master...stdexcept) https://github.com/bitcoin-core/btcdeb/pull/143

00:09 <bitcoin-git> [btcdeb] kallewoof pushed 2 commits to master: https://github.com/bitcoin-core/btcdeb/compare/b2f3d4d48c3b...4fd007e57b79

00:09 <bitcoin-git> btcdeb/master a1a686a Ciro Santilli: fix ‘runtime_error’ is not a member of ‘std’ build error

00:09 <bitcoin-git> btcdeb/master 4fd007e kallewoof: Merge pull request #143 from cirosantilli/stdexcept

00:30 <bitcoin-git> [btcdeb] kallewoof pushed 1 commit to master: https://github.com/bitcoin-core/btcdeb/compare/4fd007e57b79...b9288fc3371e

00:30 <bitcoin-git> btcdeb/master b9288fc kallewoof: Create codeql.yml

10:15 <warren> I was wondering if v2 transport automatically falls back to v1, is it easy for a MITM to induce the fallback?

10:26 <sipa_> absolutely

10:27 <sipa_> it still requires thr MitM to be active, but much less so

10:48 <bitcoin-git> [bitcoin] maflcko closed pull request #23352: test: Extend stale_tip_peer_management test (master...2110-testDos) https://github.com/bitcoin/bitcoin/pull/23352

10:53 <bitcoin-git> [bitcoin] glozow pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/9eeee7caa3f9...4572f48fd5a8

10:53 <bitcoin-git> bitcoin/master b198b9c Sebastian Falbesoner: test: p2p: introduce helper for sending prepared VERSION message

10:53 <bitcoin-git> bitcoin/master 7ddfc28 Sebastian Falbesoner: test: p2p: process post-v2-handshake data immediately

10:53 <bitcoin-git> bitcoin/master c340503 Sebastian Falbesoner: test: p2p: adhere to typical VERSION message protocol flow

10:53 <bitcoin-git> [bitcoin] glozow merged pull request #29353: test: p2p: adhere to typical VERSION message protocol flow (master...202401-test-p2p-adhere_to_std_version_handshake_protocol) https://github.com/bitcoin/bitcoin/pull/29353

11:03 <bitcoin-git> [bitcoin] glozow pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4572f48fd5a8...4de84557d6d1

11:03 <bitcoin-git> bitcoin/master e7fd70f stratospher: [test] make v2transport arg in addconnection mandatory and few cleanups

11:03 <bitcoin-git> bitcoin/master 4de8455 glozow: Merge bitcoin/bitcoin#29356: test: make v2transport arg in addconnection m...

11:03 <bitcoin-git> [bitcoin] glozow merged pull request #29356: test: make v2transport arg in addconnection mandatory and few cleanups (master...24748-followups) https://github.com/bitcoin/bitcoin/pull/29356

12:59 <warren> If you don't want to give away the fact that you're running bitcoind is there a mode to accept only v2 transport and don't fallback? (I suppose this is more useful when we later gain authentication)

14:41 <lightlike> warren: not currently. it's not without risk to introduce this, if too many nodes used it, it the network could split into a v1 and a v2 part.

14:47 <sdaftuar> it's also not clear what that gets you, if someone who really cares can still figure it out?

17:20 <vasild> warren: "to accept only...", so your node is listening? In that case it announces its listening IP address and port to the bitcoin network, where your spy can get it from and know you run bitcoind.

17:21 <vasild> if you want to hide the fact that you run bitcoind, you should at least not listen (on clearnet)

17:23 <vasild> warren: also, if you connect to other peers using v2, keep in mind that the spy knows all listening clearnet IP addr:port, so as soon as they see you have TCP connection to some of them, then know it is bitcoin traffic, even if they cannot see the traffic itself (because of v2 encryption)

17:24 <vasild> so, your best bet is to use only tor and i2p

17:49 <sipa> they shouldn't be able to tell it's specifically bitcoin traffic with v2 from just observing the traffic (though certain kinds of analysis can give strong indications, like a spike when a block is found etc)

17:49 <sipa> also, listening on port 8333 is a giveaway, but we could depart from that default at some point

18:00 <bitcoin-git> [bitcoin] brunoerg opened pull request #29393: i2p: log connection was refused due to arbitrary port (master...2024-02-i2p-log-connect) https://github.com/bitcoin/bitcoin/pull/29393

18:03 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4de84557d6d1...03d95cc630c5

18:03 <bitcoin-git> bitcoin/master 2bb25ce furszy: wallet: remove unused 'accept_no_keys' arg from decryption process

18:03 <bitcoin-git> bitcoin/master 03d95cc Ava Chow: Merge bitcoin/bitcoin#29375: wallet: remove unused 'accept_no_keys' arg fr...

18:03 <bitcoin-git> [bitcoin] achow101 merged pull request #29375: wallet: remove unused 'accept_no_keys' arg from decryption process (master...2024_wallet_saturday_garbage_collector) https://github.com/bitcoin/bitcoin/pull/29375

18:36 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/03d95cc630c5...592e01398e76

18:36 <bitcoin-git> bitcoin/master e2ad343 Sebastian Falbesoner: wallet: remove unused `SignatureData` instances in spkm's `FillPSBT` metho...

18:36 <bitcoin-git> bitcoin/master 592e013 Ava Chow: Merge bitcoin/bitcoin#28833: wallet: refactor: remove unused `SignatureDat...

18:36 <bitcoin-git> [bitcoin] achow101 merged pull request #28833: wallet: refactor: remove unused `SignatureData` instances in spkm's `FillPSBT` methods (master...202311-wallet-remove_unused_SignatureData_instances) https://github.com/bitcoin/bitcoin/pull/28833