1. 
   vasild commented at 10:49 am on February 2, 2026: contributor

   A meta issue to track the pull requests related to private broadcast

   Initial

   • 🪓 🔥 ⛔ First attempt that tried to put the transaction in the mempool (#27509)
   • 🟢 ✔️ 🥳 Implement the ability to broadcast a transaction via a short lived privacy connection and use that for the sendrawtransaction RPC (#29415)

   Followups and extensions

   Wallet

   • #33671
   • #34359
   • #34457
   • #34533

   Other

   • #34329
   • #34322
   • #34707

   Fixes and improvements

   • #34300
   • #34267
   • #34410
   • #34271
   • #34511
   • #34646
   • #34873
   • #35032
2. fanquake added the label Tracking Issue on Feb 2, 2026
3. 
   Crypt-iQ commented at 6:32 pm on February 4, 2026: contributor

   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?

4. vasild referenced this in commit 41c94739ca on Feb 5, 2026
5. 
   vasild commented at 8:53 am on February 5, 2026: contributor

   non-determinism in the process_message(s) fuzz harnesses

   Addressed in https://github.com/bitcoin/bitcoin/pull/34511

6. vasild referenced this in commit 2cb7e99dee on Feb 5, 2026
7. 
   vasild commented at 5:40 am on February 7, 2026: contributor

   Added #34533 wallet: resubmit transactions with private broadcast if enabled
8. fanquake referenced this in commit 84e826ddc1 on Feb 13, 2026
9. 
   instagibbs commented at 7:16 pm on April 9, 2026: member

   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?)
10. 
    vasild commented at 10:01 am on April 10, 2026: contributor

    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:

    0bitcoin-cli getaddrmaninfo |jq '.i2p.total / (.ipv4.total + .ipv6.total + .onion.total + .i2p.total) * 100'
    

11. 
    instagibbs commented at 12:29 pm on April 10, 2026: member

    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.

Contributors
vasild Crypt-iQ instagibbs

Labels
Tracking Issue