Add Attacker category descriptions

[kristovatlas]

This would be included in documentation to help the threat model reader understand which concrete instances of attackers may fall into the correct attacker categories.

Network Observer:

A network observer passively collects information about network traffic containing Bitcoin-related data. Examples of network observers include providers of thin client-server wallets, Bitcoin P2P nodes, and Internet Service Providers.

[kristovatlas]

Blockchain Observer:

A blockchain observer downloads blockchain data and analyzes it for probable clusters of co-owned funds and other relationships. The blocks downloaded and retained may include both those included on the current best chain as well as stale blocks. As blockchain data is necessarily retained indefinitely, a blockchain observer can begin collection and analysis of data at any point in time starting with the genesis block's dissemination.

[kristovatlas]

Protocol Peer:

A protocol peer attacker is a Bitcoin P2P node that interacts directly with a victim client. Attacks in this category do not belong to the "Network Observer" category because they do not apply to wallet clients that do not connect directly to the Bitcoin P2P network.

[kristovatlas]

Transaction participant:

Transaction participants send funds to, receive funds from, or co-sign with a victim user in a Bitcoin transaction.

[kristovatlas]

Physical adversary:

A physical adversary uses physical proximity to observer a victim user's Bitcoin-related behavior. Examples of physical adversaries include surveillance cameras, shoulder-surfing humans, and forensic investigators with physical access to a victim user's device.

[kristovatlas]

Wallet provider:

A wallet provider writes and transmits Bitcoin client software to the user. Some attacks that can be carried out by wallet providers with privileged access to data will instead fall under the "Network observer" category.

[kristovatlas]

Meta attacks:

Meta attacks describe wallet client functionality that does not directly impact user privacy but is likely to lead users to make positive or negative privacy decisions.

[dcousens]

Transaction participants send funds to, receive funds from, or co-sign with a victim user in a Bitcoin transaction.

I think the description is obvious enough, but not the implications of what attacks they "could do" (see first 2 descriptions which hint at what they're attacks consist of).

Maybe something like

Transaction participants can use their knowledge of which inputs are theirs to isolate the remaining information in a transaction for further analysing.

But less specific.

Maybe mention CoinJoin participants, etc.

[kristovatlas]

@crwatkins and I met tonight and we signed off on the first 6 reorganized network attacks that I came up with using our decisions from the last meeting.

One problem we’re bumping into is that we need to commit to who the attacker is specifically in the “Network Observer” attacker category. It could include:

1. Passive eavesdroppers like ISPs/ASs
2. Protocol peers
3. Wallet providers for thin client-server wallets

See: https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/issues/140

One important reference point to keep in mind is our model of the average user we're threat modeling for; we’re assuming the average user is going to be using a thin client-server wallet. However, the threat model must be flexible enough to account for a range of kinds of clients including P2P SPV clients and P2P full node clients.

However, for some of the attacks currently listed in the network attacker category, the severity of the compromised data depends on what kind of network attacker is in question.

Previously, we talked about how clustering addresses based on a common IP address for first-hop broadcasted transactions would be low confidence for a server-client wallet as seen by a protocol peer or passive eavesdropper, since the wallet provider would act as a kind of NAT router between the individual client and the Bitcoin P2P network.

That means that we would need to have a separate, similar attack under the wallet provider accounting for the same attack as performed by the wallet provider. This would result in a high confidence instead, since IP addresses would be fairly unique to individual users of that wallet provider.

We have another attack not yet reorganized that is essentially the same attack but for clustering addresses across multiple identities; again, we need to decide which kind of network attacker we’re considering in the Network Attacker category, and duplicate attacks as needed.

[crwatkins]

ACK

[kristovatlas]

Resolution to the above quandary from tonight's meeting with me, @crwatkins, and @dcousens: Network observer category stays the same, but we will note that the network observer attacker will be the kind of network observer that poses the greatest threat to the user given the nature of the attack and the architecture of the wallet client. For example, for an attack that links IP address to a transaction based on seeing that IP as the first hop:

• For a full node or SPV wallet, the network observer is a P2P node or a passive adversary observing unencrypted traffic
• For a thin client-server model, the network observer is the wallet provider through whom the client pushes transactions to the Bitcoin P2P network

For these different kinds of attackers there is a different number of attackers (many P2P nodes, a few ISP/AS's, only one wallet provider) but we're unable to quantify the differences in risk based purely on this difference in number. If we were able to quantify it, we might have to reorganize the model to explicitly encode these various types of network observers separately.

Note in my previous comment I said:

One important reference point to keep in mind is our model of the average user we're threat modeling for; we’re assuming the average user is going to be using a thin client-server wallet.

However, we're not going to be encoding that assuming into the weighting of the network observer attacks, since we want to be able to measure threat for a variety of wallet client architectures and because there is a valid network-based threat for each kind.