_Parts of this PR are isolated in independent smaller PRs to ease review:_ * [x] _https://github.com/bitcoin/bitcoin/pull/29420_ * [x] _https://github.com/bitcoin/bitcoin/pull/33454_ * [x] _https://github.com/bitcoin/bitcoin/pull/33567_ * [x] _https://github.com/bitcoin/bitcoin/pull/33793_ --- To improve privacy, broadcast locally submitted transactions (from the `sendrawtransaction` RPC) to the P2P network only via Tor or I2P short-lived connections, or to IPv4/IPv6 peers but through the Tor network. * Introduce a new connection type for private broadcast of transactions with the following properties: * started whenever there are local transactions to be sent * opened to Tor or I2P peers or IPv4/IPv6 via the Tor proxy * opened regardless of max connections limits * after handshake is completed one local transaction is pushed to the peer, `PING` is sent and after receiving `PONG` the connection is closed * ignore all incoming messages after handshake is completed (except `PONG`) * Broadcast transactions submitted via `sendrawtransaction` using this new mechanism, to a few peers. Keep doing this until we receive back this transaction from one of our ordinary peers (this takes about 1 second on mainnet). * The transaction is stored in peerman and does not enter the mempool. * Once we get an `INV` from one of our ordinary peers, then the normal flow executes: we request the transaction with `GETDATA`, receive it with a `TX` message, put it in our mempool and broadcast it to all our existent connections (as if we see it for the first time). * After we receive the full transaction as a `TX` message, in reply to our `GETDATA` request, only then consider the transaction has propagated through the network and remove it from the storage in peerman, ending the private broadcast attempts. The messages exchange should look like this: ``` tx-sender >--- connect -------> tx-recipient tx-sender >--- VERSION -------> tx-recipient (dummy VERSION with no revealing data) tx-sender <--- VERSION -------< tx-recipient tx-sender <--- WTXIDRELAY ----< tx-recipient (maybe) tx-sender <--- SENDADDRV2 ----< tx-recipient (maybe) tx-sender <--- SENDTXRCNCL ---< tx-recipient (maybe) tx-sender <--- VERACK --------< tx-recipient tx-sender >--- VERACK --------> tx-recipient tx-sender >--- INV/TX --------> tx-recipient tx-sender <--- GETDATA/TX ----< tx-recipient tx-sender >--- TX ------------> tx-recipient tx-sender >--- PING ----------> tx-recipient tx-sender <--- PONG ----------< tx-recipient tx-sender disconnects ``` Whenever a new transaction is received from `sendrawtransaction` RPC, the node will send it to a few (`NUM_PRIVATE_BROADCAST_PER_TX`) recipients right away. If after some time we still have not heard anything about the transaction from the network, then it will be sent to 1 more peer (see `PeerManagerImpl::ReattemptPrivateBroadcast()`). A few considerations: * The short-lived private broadcast connections are very cheap and fast wrt network traffic. It is expected that some of those peers could blackhole the transaction. Just one honest/proper peer is enough for successful propagation. * The peers that receive the transaction could deduce that this is initial transaction broadcast from the transaction originator. This is ok, they can't identify the sender. ---

How to test this?

Thank you, @stratospher and @andrewtoth! Start `bitcoind` with `-privatebroadcast=1 -debug=privatebroadcast`. Create a wallet and get a new address, go to the Signet faucet and request some coins to that address: ```bash build/bin/bitcoin-cli -chain="signet" createwallet test build/bin/bitcoin-cli -chain="signet" getnewaddress ``` Get a new address for the test transaction recipient: ```bash build/bin/bitcoin-cli -chain="signet" loadwallet test new_address=$(build/bin/bitcoin-cli -chain="signet" getnewaddress) ``` Create the transaction: ```bash # Option 1: `createrawtransaction` and `signrawtransactionwithwallet`: txid=$(build/bin/bitcoin-cli -chain="signet" listunspent | jq -r '.[0] | .txid') vout=$(build/bin/bitcoin-cli -chain="signet" listunspent | jq -r '.[0] | .vout') echo "txid: $txid" echo "vout: $vout" tx=$(build/bin/bitcoin-cli -chain="signet" createrawtransaction "[{\"txid\": \"$txid\", \"vout\": $vout}]" "[{\"$new_address\": 0.00001000}]" 0 false) echo "tx: $tx" signed_tx=$(build/bin/bitcoin-cli -chain="signet" signrawtransactionwithwallet "$tx" | jq -r '.hex') echo "signed_tx: $signed_tx" # OR Option 2: `walletcreatefundedpsbt` and `walletprocesspsbt`: # This makes it not have to worry about inputs and also automatically sends back change to the wallet. # Start `bitcoind` with `-fallbackfee=0.00003000` for instance for 3 sat/vbyte fee. psbt=$(build/bin/bitcoin-cli -chain="signet" walletcreatefundedpsbt "[]" "[{\"$new_address\": 0.00001000}]" | jq -r '.psbt') echo "psbt: $psbt" signed_tx=$(build/bin/bitcoin-cli -chain="signet" walletprocesspsbt "$psbt" | jq -r '.hex') echo "signed_tx: $signed_tx" ``` Finally, send the transaction: ```bash raw_tx=$(build/bin/bitcoin-cli -chain="signet" sendrawtransaction "$signed_tx") echo "raw_tx: $raw_tx" ```

---

High-level explanation of the commits

* New logging category and config option to enable private broadcast * `log: introduce a new category for private broadcast` * `init: introduce a new option to enable/disable private broadcast` * Implement the private broadcast connection handling on the `CConnman` side: * `net: introduce a new connection type for private broadcast` * `net: implement opening PRIVATE_BROADCAST connections` * Prepare `BroadcastTransaction()` for private broadcast requests: * `net_processing: rename RelayTransaction to better describe what it does` * `node: extend node::TxBroadcast with a 3rd option` * `net_processing: store transactions for private broadcast in PeerManager` * Implement the private broadcast connection handling on the `PeerManager` side: * `net_processing: reorder the code that handles the VERSION message` * `net_processing: move the debug log about receiving VERSION earlier` * `net_processing: modernize PushNodeVersion()` * `net_processing: move a debug check in VERACK processing earlier` * `net_processing: handle ConnectionType::PRIVATE_BROADCAST connections` * `net_processing: stop private broadcast of a transaction after round-trip` * `net_processing: retry private broadcast` * Engage the new functionality from `sendrawtransaction`: * `rpc: use private broadcast from sendrawtransaction RPC if -privatebroadcast is ON` * New tests: * `test: add functional test for private broadcast` * `test: add unit test for the private broadcast storage`

--- **This PR would resolve the following issues:** https://github.com/bitcoin/bitcoin/issues/3828 Clients leak IPs if they are recipients of a transaction https://github.com/bitcoin/bitcoin/issues/14692 Can't configure bitocoind to only send tx via Tor but receive clearnet transactions https://github.com/bitcoin/bitcoin/issues/19042 Tor-only transaction broadcast onlynet=onion alternative https://github.com/bitcoin/bitcoin/issues/24557 Option for receive events with all networks, but send transactions and/or blocks only with anonymous network[s]? https://github.com/bitcoin/bitcoin/issues/25450 Ability to broadcast wallet transactions only via dedicated oneshot Tor connections https://github.com/bitcoin/bitcoin/issues/32235 Tor: TX circuit isolation **Issues that are related, but (maybe?) not to be resolved by this PR:** https://github.com/bitcoin/bitcoin/issues/21876 Broadcast a transaction to specific nodes https://github.com/bitcoin/bitcoin/issues/28636 new RPC: sendrawtransactiontopeer --- Further extensions: * Have the wallet do the private broadcast as well, https://github.com/bitcoin/bitcoin/issues/11887 would have to be resolved. * Have the `submitpackage` RPC do the private broadcast as well, [draft diff in the comment below](https://github.com/bitcoin/bitcoin/pull/29415#pullrequestreview-2972293733), thanks ismaelsadeeq! * Add some stats via RPC, so that the user can better monitor what is going on during and after the broadcast. Currently this can be done via the debug log, but that is not convenient. * Make the private broadcast storage, currently in peerman, persistent over node restarts. * Add (optional) random delay before starting to broadcast the transaction in order to avoid correlating unrelated transactions based on the time when they were broadcast. Suggested independently of this PR [here](https://github.com/bitcoin/bitcoin/issues/30471). * Consider periodically sending transactions that did not originate from the node as decoy, discussed [here](https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2035414972). * Consider waiting for peer's FEEFILTER message and if the transaction that was sent to the peer is below that threshold, then assume the peer is going to drop it. Then use this knowledge to retry more aggressively with another peer, instead of the current 10 min. See [comment below](https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3258611648). * It may make sense to be able to override the default policy -- eg so submitrawtransaction can go straight to the mempool and relay, even if txs are normally privately relayed. See [comment below](https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3427086681). * As a side effect we have a new metric available - the time it takes for a transaction to reach a random node in the network (from the point of view of the private broadcast recipient the tx originator is a random node somewhere in the network). This can be useful for monitoring, unrelated to privacy characteristics of this feature. --- _A previous incarnation of this can be found at https://github.com/bitcoin/bitcoin/pull/27509. It puts the transaction in the mempool and (tries to) hide it from the outside observers. This turned out to be too error prone or maybe even impossible._

Broadcast own transactions only via short-lived Tor or I2P connections