countermeasure: coinjoins can confound network analysis

[kristovatlas]

Existing attack: "Link addresses belonging to a single user by observing source IP address for first relay of transactions"

By using CoinJoin or creating a transaction indistinguishable from a CoinJoin, a network attacker who is not a transaction participant has weakened certainty that an address in the inputs belongs to IP address observed as a first hop. From An Analysis of Anonymity in Bitcoin Using P2P Network Traffic:

Our biggest source of potential noise were multi-input transactions. In this work, we assume that each transaction has only one owner. A multi-input transaction can be created by one or multiple, unrelated entities with no way to distinguish the difference [16]. Other academic works do not acknowledge this possibility. We argue that not excluding multi-input transactions could lead to incorrect assumptions being made about the ownership of a Bitcoin address. To be conservative, we removed all 1,544,509 multi-input transactions from our dataset, leaving us with 3,901,206 transactions to analyze.

[kristovatlas]

Summary of attack: A Protocol peer or Network observer attacker can observe a transaction broadcast to the network and tie the input(s) to the first hop IP address observed.

I can't find any applicable attacks under these two attacker categories. In the last version of the threat model, this attack worked:

"Link addresses belonging to a single user by observing source IP address for first relay of transactions"

However, I think that may have been reworded since, such that it no longer applies:

Link addresses belonging to a single user by observing that multiple transactions enter the network from an origin point likely to belong to a single user.

Here's a proposed wording for a new attack under the Network observer category:

Link a transaction's input address(es) to a specific IP address by observing the first relay of a broadcasted transaction.

Yes, there is no such thing as an "input address," but the meaning is clear enough. I'm happy to rephrase if it does not get too wordy.

I think this should be in the Network observer category instead of Protocol peer because it could also apply to a thin client such as a web wallet prior to reaching the Bitcoin P2P network.

The existing countermeasure that falls under the Blockchain observer attacker category is relevant:

Use mixing when sending transactions, and make non-mixed transactions resemble mixed transactions

This existing countermeasure also applies:

Route outgoing transactions via a method that does not reveal the IP address of the sender

[kristovatlas]

The same four criteria for OBPPV3/CM11 in the blockchain observer can be used here:

1. "id": "OBPPV3/CR09", "description": "When an outgoing transaction must merge inputs, and when mixing is not being used, the transaction constructed in a way that plausibly resembles a mixing transaction"
2. "id": "OBPPV3/CR18", "description": "Number of clicks required by user for inputs/outputs to be mixed with one or more other users"
3. "id": "OBPPV3/CR19", "description": "Average number of other users whose funds are mixed with the client user's when sending through a mixing process"
4. "id": "OBPPV3/CR20", "description": "Mixing transactions are constructed in a manner that makes them indistinguishable from non-mixing transactions"