A meta issue to track the pull requests related to private broadcast
sendrawtransaction RPC (#29415)
Looks like the private broadcast changes introduced non-determinism in the process_message(s) fuzz harnesses. They re-use the same Connman across iterations, and the m_outbound_tor_ok_at_least_once may have already been flipped true by a previous iteration. The non-determinism shows up here: https://github.com/bitcoin/bitcoin/blob/d4bc620ad8cf6b7975be55d5ae27dc943cceef3f/src/net.cpp#L4066-L4071
Ideally, this check would not be hit if private broadcast is disabled?
non-determinism in the process_message(s) fuzz harnesses
Addressed in https://github.com/bitcoin/bitcoin/pull/34511
should CConnman::PrivateBroadcast::PickNetwork not be picking uniformly? If a user has both Tor and I2P configured, seems like it would bias you to pick from a much smaller bucket of nodes, about half the time (and you'd be announcing that you're from a much smaller anonymity set?)
much smaller anonymity set
Do you mean that the number of I2P nodes on the network is less than the number of Tor nodes?
Lets see, if both Tor and I2P are accessible, then CConnman::PrivateBroadcast::PickNetwork() will select:
IPv4 peer (will connect via the Tor network), 25% of the time
IPv6 peer (will connect via the Tor network), 25% of the time
Tor peer, 25% of the time
I2P peer, 25% of the time
In the first 3 cases, the recipient will get an information that "Somebody with access to the Tor network is sending this transaction", that is 75% of the time. In the 4th case - "Somebody with access to the I2P network is sending this transaction", 25% of the time.
Now, would it be better if the selection is not 25% uniform, but based on the number of entries in addrman? Wanting to do that somehow implies that the number of entries for a given network in addrman is proportional to the number of nodes from that network. E.g. if there are 100 Tor and 50 I2P entries in addrman, then the Bitcoin network has two times more Tor nodes than I2P nodes. Is that the case though? The way addrman bucketing works - it uses the first 4 bits from the address for both Tor and I2P to select a bucket to place a new address to...
Anyway, if that is to be done, the change would be relatively small - return the set of networks from CConnman::PrivateBroadcast::PickNetwork() instead of just one network, then pass this set to AddrMan::Select() which picks a random entry and checks if it belongs to one of the given networks. That would favor networks with more entries in addrman.
In my addrman the number of I2P entries is about 5% of the number of IPv4+IPv6+Tor+I2P entries:
bitcoin-cli getaddrmaninfo |jq '.i2p.total / (.ipv4.total + .ipv6.total + .onion.total + .i2p.total) * 100'
but based on the number of entries in addrman?
maybe? but that could be influenced by flooding the network with sybils, so if there's a mismatch between measured counts and known actual user counts, you'd still be exposing yourself.
I am closing this - it served its purpose to track the initial wave of followup PRs after #29415 was merged. The wallet support has not been implemented yet. That maybe deserves a separate tracking or brainstorming issue.
Now we have the Private Broadcast label on PRs and issues, so they can be tracked via:
https://github.com/bitcoin/bitcoin/issues?q=state%3Aopen%20label%3A%22Private%20Broadcast%22