When funds residing in multiple Bitcoin addresses or scripts are spent as inputs in the same transaction, this indicates to attackers that the funds are all owned by the same person or organization. Multi-party mixing protocols such as CoinJoin are a common mitigation against this blockchain-based information leak.
Blockchain Observer: A Blockchain Observer is an attacker who downloads information from the Bitcoin blockchain and performs statistical analysis on it to notice patterns that suggest common ownership of funds. It is easy for anyone to become such an attacker since operating a full node is inexpensive and completely open to the public by design.
Easy. It is inexpensive for individuals and organizations download the blockchain and observe transactions that contain multiple inputs. It is often easy to detect transactions that employ mitigations against this weakness, such as CoinJoin.
Common. During 2016, 20.1% of transactions merged multiple inputs in a single spend, [1] and 81% of transactions with more than one input do so. [2]
Easy. Users and auditors of Bitcoin software can identify when funds from the same wallet are merged in a single transaction by looking at transactions authored by their software using local blockchain copies or blockchain explorer websites. (NOTE: Users should be cautious of adverse privacy consequences when using block explorer websites!)
High. Merger of inputs is a robust heuristic for clustering related addresses and transactions and establishing co-ownership. An attacker with additional information acquired outside of the blockchain linking to any one of the addresses or transactions in a cluster may gain intimate knowledge of the finances of a victim individual or organization.
The vast majority of Bitcoin software projects are prone to this form of information disclosure. Some Bitcoin software mitigates this weakness with CoinJoin-like protocols or transaction construction protocols such as that described in BIP 126. A simple way to test this is to perform a few sample transactions and examine the results on a local blockchain copy or explorer website. (NOTE: Users should be cautious of adverse privacy consequences when using block explorer websites!) The following protocol can help you perform this test:
- In an empty wallet, generate a new receiving address and send a small amount of funds to the address.
- Generate a second receiving address, and send funds to it.
- Send an amount of funds greater than the amount you sent individually to either of those two receiving addresses to another address outside of the wallet you’re testing. Observe whether the software shows any warnings or errors. If it allows you to complete the transaction, your software may exhibit this input merging weakness.
- Examine the sending transaction in your software if possible, or use a local blockchain copy or blockchain explorer website. (NOTE: Users should be cautious of adverse privacy consequences when using block explorer websites!) If there are addresses listed in the list of inputs that are in addition to the two receiving addresses you generated earlier, your software may be utilizing a CoinJoin-like protocol to combine funds with other parties to mitigate this weakness.
Bitcoin software can create ownership ambiguity by employing multi-party protocols, or by making transactions resemble those multi-party protocols. When possible, it should avoid select funds for spending in a way that minimizes merging of inputs from different addresses. Additionally, software that permits for multiple identities should not merge funds from multiple identities in a single transaction.
Specifically, these methods will help mitigate this threat:
- Create transactions with multiple owners with multi-party protocols such as CoinJoin
- Make non-mixing transactions resemble mixing transactions (BIP 126)
- Order inputs are in a random or deterministic fashion (BIP 69)
- When spending some funds for a given address, spend all of them
- Warn users about loss privacy when inputs are merged
- Avoid merging funds from multiple identities within the same wallet
- Select funds to spend to minimize the number of source addressed merged as inputs to a transaction
- Peter the privacy attacker downloads the blockchain and uses the merged input heuristic to cluster co-owned addresses. Later, he finds out that his victim Alice owns a specific Bitcoin address. Peter can then look up other addresses clustered with this address to determine all addresses in Alice’s wallet and characterize her payments to and from other parties.
If you write Bitcoin software libraries or have used them, please consider submitting code examples of how to mitigate specific threats using the library of your choice. See: HOWTO-CONTRIBUTE and HOWTO-PROVIDE-FEEDBACK
- Blockchain observer attack #3: Link outputs to a single entity based on them all being included as inputs in the same transaction
- Blockchain observer attack #4: Link identities by observing that addresses associated with both identities are used as inputs in the same transaction
- Transaction participant attack #2: Create transactions which create small outputs to previously-used addresses which tempt wallet clients with poor utxo selection and/or lack of coin control to merge inputs
- Transaction participant attacker #3: Defeat attempts by users to mix their coins by participating in mixing transactions and collecting information which can be used to map inputs to outputs in the mixing transaction
- Meta attack #2: Concern that mixing services can steal funds may give users an incentive to avoid mixing
- Criterion I C 1 a: When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction?
- Criterion I C 1 b: Are inputs and outputs ordered in a deterministic manner based on criteria other than the status of outputs as spends or change (BIP 69)?
- Criterion I C 1 d: When an input is selected which is part of a set of unspent outputs containing identical scripts (multiple deposits to a single address), is every output in the set added to the transaction?
- Criterion I C 2 a: Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction?
- Criterion I D 1 a: Number of clicks required by user for inputs/outputs to be mixed with one or more other users
- Criterion I D 2 a: Average number of other users whose funds are mixed with yours when sending through a mixing process
- Criterion I D 2 b: Are mixing transactions constructed in a manner that makes them indistinguishable from non-mixing transactions?
- Criterion I D 3 a: Warns the user when a proposed mix is easy to reverse?
- Criterion III A 2 a: Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior?
- Criterion III A 3 a: Visually indicates when inputs from different identity containers are merged before the transaction is broadcast, or prohibits this operation entirely?
- Criterion III B 1 a: Mixing is secure against correlation attacks by the facilitator
- Criterion III B 1 b: Mixing is secure against theft of funds
When looking up wallet addresses or transactions on block explorer websites, be cautious that these lookups can compromise your wallet’s privacy. Consider using Tor Browser to hide your machine’s network identity, and create a new Tor Identity in between each piece of blockchain data you look up to avoid correlating them from the perspective of the block explorer website.
- ^ Tweet by LareuntMT, Twitter.com
- ^ Tweet by khannib, Twitter.com
- “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names”. Meiklejohn et al.
- Transaction input. Bitcoin Wiki.
- Bitcoin Privacy Threat Model, 2nd Edition. Open Bitcoin Privacy Project
This work is placed in the public domain.
Title: OBPP Top 4 Privacy Threats for 2016: T1: Merging co-owned funds
Author: Open Bitcoin Privacy Project
Created: 2017-01-12
Last Updated: 2016-02-01