net: send decoy transactions via private broadcast #35252

The private broadcast feature removes the link between a transaction and its originating node IP or onion address. However, a passive observer with a large number of sybil nodes can still fingerprint transactions that are broadcast via private broadcast. Any recipient of a transaction via a private broadcast connection can be certain that it was deliberately sent via private broadcast.

This PR introduces private broadcast decoy connections. Randomly on average once every 3 hours, any node with Tor or I2P reachable opens an extra private broadcast connection. Instead of one of the node's own pending transactions, the connection announces the most recent transaction in the mempool. Because of normal transaction relay latency, the recipient may not have seen that transaction yet, and from its point of view the connection is indistinguishable from a user-submitted private broadcast. If the recipient already has the transaction, the private broadcast will timeout after 3 minutes. In this case there is still plausible deniability since this mimics user-submitted transactions. We open 3 connections for each submitted transaction. After the first successful connection the other connections may connect to nodes that have already received the transaction from the first recipient.

-blocksonly nodes are excluded. If the mempool is empty, no decoy is sent that round.

Every user-submitted private broadcast now has plausible deniability of being a decoy.

This makes it more difficult for a network-level observer to distinguish the traffic pattern of a user-submitted broadcast from a decoy.

Log lines such as

New private-broadcast peer connected: transport: v2, version: 70016, peer=xxx

still appear, but they no longer distinguish user-submitted transactions from decoys.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35252.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #34628 (p2p: Replace per-peer transaction rate-limiting with global rate limits by ajtowns)
• #31260 (scripted-diff: Type-safe settings retrieval by ryanofsky)
• #30951 (net: option to disallow v1 connection on ipv4 and ipv6 peers by stratospher)
• #17783 (common: Disallow calling IsArgSet() on ALLOW_LIST options by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Concept ACK

Correct me if I'm wrong, but with this change, then that transaction will be forwarded twice from the same node, once via flood and another via private broadcast?

Wouldn't this add additional network load for nodes, albeit small, considering it is one transaction every 6 hours?

I like the idea, just worth considering if it does add more bandwidth usage.

Wouldn't this add additional network load for nodes, albeit small, considering it is one transaction every 6 hours?

On average it would be once every 3 hours. However, since we make feeler connections every 2 minutes, I don't think the bandwidth increase is worth considering. The extra overhead of a private broadcast connection vs a feeler is just an inv -> getdata -> tx and ping + pong.

Because of normal transaction relay latency, the recipient may not have seen that transaction yet, and from its point of view the connection is indistinguishable from a user-submitted private broadcast.

It would be interesting to measure how well this works. If you are not well connected, for example because you only have 8 transaction relaying outbound connections (which receive invs slower than the inbounds you get) as a home node, you might pick decoys a large part of the network already knows about (especially if it's a high feerate transaction, as these propagate faster). Since the other side wouldn't request these if already in mempool, it's able to tell that these are decoys.

This can be measured by running this PR and counting how many of the decoy transactions are actually requested from you. It might make sense to do this both for listening and non-listening nodes. For testing, a higher rate of decoys is probably useful: e.g. send a decoy every 5min.

Wouldn't any attacker interested in the origin of txns so much that they would run a large-scale Sybil attack almost certainly also have a permanent connection to each reachable node (which is easier and cheaper) - so that the proposed solution would be ineffective because the attacker very likely would already know about the last mempool transaction?

Also, I think it would be good to discuss the general issue this is addressing: Why is it bad if an attacker knows that private broadcast was used for a tx if they can't know the sender? Is the concern that this could lead to some kind of stigmatisation in some (even more) dystopian future, or something different?