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


Last updated June 15, 2020, noon | Posted by Stéphane Marbeau

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:


TX-1.png

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:


TX-2.png

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:


TX-3.png

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:

The cons are:

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!






Thanks for reading!

If you enjoyed it, please share it on Twitter.