For any asset to operate as a medium of exchange it has to be fungible, meaning that its units have to be easily exchangeable, with the same value placed on every unit. Analysis of the Bitcoin blockchain allows for the possibility that, because of their transaction history, a company may declare certain bitcoin to be ‘tainted’ and labelled as unacceptable as payment. Blockchain analysis companies, who try and trace the provenance and ownership of bitcoin, compromise the privacy of users and inhibit the ability to freely exchange bitcoin without bias. Unless privacy of basic transactions can be maintained, bitcoin loses some of its fungibility.
Attendees of a community work group recently set themselves the goal of improving basic transaction privacy in Bitcoin. We present a summary of the group’s efforts; to provide wallet developers with a common approach to defend against the most common heuristic used by blockchain analysis companies and in doing so, providing Bitcoin with improved fungibility.
The hope of the group is that it encourages community discussion and advances efforts to provide a standardized way for wallets and payment processors to interact more privately.
Breaking blockchain analysis tools
In their 2013 paper, Meiklejohn et al. outlined a key heuristic used to link addresses in the Bitcoin blockchain. They made the observation that a fundamental principle of blockchain analysis considers “different public keys used as inputs to a transaction as being controlled by the same user”
The composition of a regular Bitcoin transaction therefore provides an entry point for analysis companies wishing to track an address and its owner. It is this principle that the workshop was focused on breaking.
It is important to note that in order to invalidate the ‘common input ownership’ assumption, it is not necessary to have every transaction participate in any one proposed solution. Simply ensuring that there exist enough transactions that share inputs from different owners naturally invalidates it. As this is the building block of blockchain analytics, it is not unreasonable to take a step further and assume that the premise of Bitcoin analysis in general could therefore be broken if such a solution was in fairly common use.
This approach gave the group a more defined goal:
To provide a way to ensure that transactions with inputs owned by more than one party are a common enough occurrence that the assumptions of the ‘common input ownership’ heuristic is invalidated.
Identifying essential requirements
Of the various proposals made, many were found to share similar issues. Without detailing each proposal and critiquing them in turn, the issues can be generalized into requiring a valid solution to possess the following characteristics:
- Enables an interactive process to be established between peer to peer participants.
- Prevents or reduces the impact of UTXO ‘snooping’ attacks (where a Sender attempts to learn a Receiver’s UTXO by making repeated, uncompleted requests).
- Reduces the impact of non-responsiveness attacks.
The ‘Pay to EndPoint’ (P2EP) proposal
Iterating through various ideas resulted in the ‘Pay to EndPoint’ (P2EP) proposal. Although not without its own tradeoffs, this appears to meet the goals set out, namely; making the ‘common input ownership’ heuristic an invalid assumption and addressing the requirements for peer to peer interaction with a decent level of attack resistance.
The basic premise of P2EP is that both Sender and Receiver contribute inputs to a transaction via interactions coordinated by an endpoint the Receiver presents using a BIP 21 compliant URI.
P2EP requires no Bitcoin protocol changes and the transactions it creates are not easily identifiable as they have the same ‘fingerprint’ as regular transactions.
It is perhaps best explained in more detail by examining the steps involved in making a transaction using P2EP:
Step 1
The Receiver (a merchant or end user) generates a BIP 21 formatted URI with an additional parameter that specifies their P2EP endpoint. As BIP 21 allows variables that are not currently understood, this will not break existing wallet implementations. The endpoint address does not necessarily have to be a .onion address, just the URI of any compatible endpoint.
An example URI (adapted from examples in BIP 21):
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?p2ep=3j4tau93wkc8mh32.onion
Step 2
The Sender initiates interaction with the Receiver by confirming that the endpoint provided is available. If not, the transaction is broadcast normally, paying to the Receiver’s BIP 21 regular Bitcoin address. If the Receiver’s endpoint is available, the Sender provides a signed transaction to the Receiver as proof of UTXO ownership.
Step 3
The Receiver then sends a number of transactions to the Sender for them to sign. Out of these transactions, only one includes a UTXO that is actually the owned by the Receiver, the rest can be selected from the pool of spendable UTXOs. These transactions can then be sent either in series or in parallel to the Sender. Both approaches have advantages and disadvantages regarding privacy and speed of interaction, and so the actual method is left open for discussion and implementation.
Series: each transaction sent in turn has a probability of being the Receiver’s. The probability depends upon the number of transactions that the Receiver selected and signed and how the sequence has been randomised. The series of exchanges ends when the Sender submits a signed transaction to the Receiver that uses the Receiver’s UTXO.
Parallel: the transactions created by the Receiver are all issued to the Sender at once. The Sender will then have a set of transactions, only one of which they can assume is the Receiver’s. The probability of the Sender guessing the correct one is proportional to the number of transactions selected and sent by the Receiver. The Sender signs and returns all transactions at once.
The proposed number of transactions sent by the Receiver using either method is currently 100, which provides a balance between privacy and data transmission/processing load on either side of the exchange.
It should be noted that there is potential scope to use Bulletproofs to replace the above methods of UTXO exchange.
Step 4
In either case above, when the Receiver obtains a signed transaction that corresponds to their UTXO they can sign and broadcast the transaction, which will now contain inputs from both the Sender and the Receiver.
In the event that the P2EP process fails for whatever reason, the transaction is broadcast as a regular transaction.
Examining an example P2EP transaction
If Alice wants to pay Bob 1 BTC:
- Alice inputs 3 BTC to a transaction.
- Bob inputs 5 BTC to the same transaction.
- Alice receives 2 BTC (as her change).
- Bob receives 6 BTC (as his change, plus the 1 BTC payment from Alice).
The above transaction breaks the ‘common input ownership’ heuristic and can be interpreted in many different ways. It may, for example, be interpreted as Alice paying Bob 6 BTC, inputting a total of 8 BTC herself using inputs of 3 BTC and 5 BTC, and receiving 2 BTC back as change.
Advantages and disadvantages P2EP
Advantages:
- Breaks ‘common wallet ownership’ assumption. Cumulative effect of even minimal adoption grants regular, ‘non-P2EP’ transactions, improved privacy.
- Breaks subset sum analysis.
- The consumption of the Receiver’s UTXO may help reduce ‘UTXO bloat’.
- The Receiver can use P2EP to consolidate their UTXO set.
- Unlike a traditional, fixed-denomination CoinJoin transaction, there is no obvious ‘fingerprint’ for the transaction type, in that it shares the same appearance as a regular transaction.
- Sending wallets can be lightweight wallets.
- Senders and Receivers are provided greater privacy.
Disadvantages:
- The Receiver, as well as the Sender, must be online for the payment to be processed as a P2EP transaction.
- The interactive nature of P2EP will slightly delay transaction broadcast.
- The Receiver needs to have a ‘hot wallet’ in order to sign transactions.
- Fees may by greater for the Sender due to the increase in transaction size. This may be offset by negotiating with the Receiver if they value UTXO consolidation.
- Wallet processing is increased when compared to traditional transactions.
- The Receiver needs to have access to a full node.
What’s next for Pay to EndPoint?
P2EP is in its early stages and community review and refinement is required before a formal proposal can be made.
It is possible that the idea can be extended to include other forms of transactions, such as payment splitting or simple coin swaps.