Advancing Bitcoin

With P2EP, BTC Pay Server steps into the battle for Bitcoin’s privacy

Marbrance -

What is BTC Pay Server?

BTC Pay Server is an open-source payment processor. It allows anyone to become its own uncensorable version of Paypal, Kickstarter or Patreon, in a few minutes and for free. It is therefore a big step towards delivering Bitcoin's original goal of worldwide permission-less payments.

As such, Advancing Bitcoin has been happy to host BTC Pay Server founding developer Nicolas Dorier two years in a row. This year he gave an illuminating presentation of the end-goal behind the BTC Pay Server: bridging the knowledge boundaries within Bitcoin. It’s a highly recommended watch for those who want to make sense of the entire project. You can support his work here.

Now, there are at least two immediate obstacles to achieving truly permissionless payments: one is that of the privacy of the transactions, the other is that of the fungibility of the coins. Indeed, because the Bitcoin blockchain is pseudonymous and not anonymous, if good privacy practices aren’t followed, it isn’t too difficult for people who know how to analyze the blockchain to tell how much a given address owns, sends, receives, to who, from who and when. This is a very serious problem, for customers, for citizens as well as for merchants.

The lack of transaction privacy in turn threatens Bitcoin’s fungibility, i.e. the ability for every bitcoin to remain perfectly interchangeable with any other bitcoin. Some companies, indeed, have made a business of analyzing the blockchain to track the history of transactions deemed suspicious or illegal. They sell their services to custodial exchanges and tell them which coins they think are “tainted” by a dubious previous use, which in turn can get these coins blocked from the exchanges. It’s a bit like if your grocery store couldn’t accept your 20 dollars bill because at some point two years ago it was used to buy weed. During Advancing Bitcoin 2019, Adam Ficsor (aka nopara73) gave a thorough presentation of Bitcoin fungibility problems and techniques (even though his talk was interrupted at some point by the NSA).

Bitcoin’s lack of privacy and fungibility is an existential threat to its ability to function as a medium of exchange. However, a way to partly mitigate both these threats at the same time is currently being implemented: the pay-to-endpoint (P2EP) method.

What is P2EP?

First of all, note that P2EP is also called “PayJoin” but we follow Samson Mow here and use “P2EP” instead, both because it is less politically charged and because it differentiates it from the JoinMarket implementation.

Now, what problem is P2EP trying to solve? It’s actually pretty simple. Take a regular Bitcoin transaction. It looks something like this:

The intuitive way to read it is that Alice moved 600,000 sats, sent 400 000 sats to X’s address, which left her with 200,000 sats worth of change. This is why blockchain analysis companies rely on the “common input ownership” heuristic: if a transaction has more than one input, one can assume that all inputs come from the same user (see Meiklejohn et al.’s 2013 paper).

In order to make this heuristic less reliable, Greg Maxwell proposed the CoinJoin method back in 2013. The idea is that multiple senders and receivers co-sign a transaction in a way such that the end-result is the same as the regular transaction they intended to make but also such that the inputs and outputs are complicated enough for the “common input ownership” heuristic to break down. However, the issue with a number of CoinJoin implementations is that their use is fairly easy to detect on the blockchain (because they require the coordination of a whole group of users). For an introduction to the past, present and future of CoinJoin methods, you can watch the presentation nopara73 gave at Advancing Bitcoin a few months ago.

Mid-2018, Blockstream organized a workshop on Bitcoin privacy, and its target was that very same heuristic. The workshop produced the P2EP method, which is ironically not entirely dissimilar to a feature that was part of Bitcoin at the very beginning: the pay-to-IP address (P2IP) feature. It was then possible to send funds to an IP address. This feature wasn't very secure nor private so it was removed in October 2012 with Bitcoin 0.8.

Instead of IP addresses however, P2EP uses Uniform Resource Identifiers (URI), as introduced in the Bitcoin Improvement Proposal (BIP) 21. One of the advantages of those URI is that they can include not only IP addresses but also domain names. P2EP uses BIP 21 URI and just adds an endpoint to it.

After the original proposals, however, P2EP didn’t go very far in terms of actual use. In August 2018, Ryan Havar proposed Bustapay under the BIP 79 but it was never implemented. After two years of stagnation, Blockstream decided to sponsor Andrew 'Kukks' Camilleri to focus on implementing P2EP into BTC Pay Server to jumpstart P2EP use amongst the thousands of merchants using BTC Pay Server. The detailed documentation provided on their website explains how and why BTC Pay Server’s implementation of P2EP differs from the Bustapay proposal.

How does P2EP work?

- In the invoice he creates, the receiver inserts a BIP21 URI with a P2EP endpoint.

- The sender has to confirm if the endpoint is available. If yes, a P2EP transaction can be initiated, if not, a regular transaction will take place instead. He then creates a Partially Signed Transaction (PBST), this is the original transaction.

- If the P2EP transaction is possible, the receiver adds inputs and outputs and sends back a signed PBST. This is the P2EP transaction proposal.

- The sender can then validate, sign and broadcast the proposal to the network. This makes it a P2EP transaction.

The very point of P2EP transactions is that they are indistinguishable from regular ones, since only the sender and the receiver have to coordinate. Indeed, a P2EP transaction would look something like this:

There is more than one way to analyze this transaction. It could be that Alice moves 600,000 sats, sends 400,000 sats to X’s address and keeps 200,000 sats worth of change while Bob moves 300,000 sats in the same transaction to his receiving address. Or it could be that Alice sent 600 000 sats to X, or 500 000, etc.

It gets even more complicated if the receiver takes advantage of the transaction to merge his UTXOs:

There is no reliable way for a blockchain analyst to tell what is going on in the transaction anymore.

What are the tradeoffs?

The pros are:

  • P2EP transactions protect both parties’ privacy (sender and receiver).
  • P2EP transactions have the same fingerprint as a normal transaction.
  • P2EP can be adopted by light wallets.
  • The merchant can take advantage of the transaction to consolidate its UTXO set (which could help reduce UTXO bloat, and further improve a merchant’s privacy – see Adam Gibson’s article
  • P2EP does not require a protocol change so no soft-fork nor hard-fork are needed for it to be adopted.
  • P2EP breaks the “common wallet ownership” heuristic which is at the center of current blockchain analysis.
  • P2EP can potentially break many other heuristics as it can implement all sorts of unusual and unpredictable transaction patterns, so that most known blockchain analysis heuristic cannot be assumed to be reliable anymore (for more details on the different blockchain analysis heuristics P2EP poisons, check the BTC Pay Server documentation

The cons are:

  • The sender pays more fees.
  • Both parties need to be online at the time of the transaction, which is why P2EP may be more adapted to merchant or charity payments rather than other types of transactions. Nopara73 argues however that this is actually a pro because it means not everyone will be able to use P2EP, and the goal is precisely to make it uncertain whether or not a transaction used the method or not.
  • P2EP requires having hot wallets, which can create security issues.
  • P2EP could delay the transaction slightly.

Finally, a very important aspect of P2EP is that, in order for the transaction to go through, both parties need to use wallets that support it. This is why the fact that a big payment processor like BTC Pay Server implemented it is such a big step: it allows all merchants, charities and individuals who use it to receive P2EP transactions. For P2EP to gain traction however, it is necessary for wallets and exchanges to adopt it too.

After BTCPay’s internal wallet, Wasabi has been the first wallet to implement P2EP. Blockstream Green and Blue Wallet are working on implementing it. In order to help facilitate adoption, Ben Woosley and Justin Moon are working on Snowball, a project that intends to make integrating P2EP effortless for other wallet developers. It is nevertheless every user’s responsibility to ask his preferred wallet or exchange to implement P2EP.

Finally: do you want to give both BTC Pay Server and P2EP a try while giving back to the space? You can do just that by donating to the Human Rights Foundation Bitcoin Development Fund using BTC Pay Server’s P2EP feature here.

And if you feel like supporting but prefer giving some time, Allen Farrington has a challenge for you: if you can find and solve his puzzle, he’ll give 0.25 BTC to BTC Pay Server and 0.25 to share between the winners. Deadline is the 6th of July!