Demystifying BSV’s peer-to-peer transaction protocols


11 months ago by libs

For a while now, I’ve been trying to enable consumer BSV wallets to broadcast data and non-standard transactions by daisy chaining transactions together. My first stab at this was Proxypay but I’ve since turned my efforts to Paypresto - a service built on peer-to-peer transaction protocols.

In doing this I’ve had to dive deep in to the various P2P protocols the BSV wallet ecosystem supports. And it turns out the landscape is a somewhat confusing one, so I thought I’d share a few of the things I’ve discovered.

The standard(s)

How standards proliferate

There are currently three distinct protocols different wallets are using for sending transactions peer to peer. On top of this, between the wallets’ own implementations there are some quirks and discrepancies that can make it tricky to support all wallets, even those following the same protocol.

In short, it’s quite a minefield for any app or service that wants to accept P2P transactions. So it’s a good job I built Paypresto so you don’t have to worry about it. But in case you do have masochistic tendencies, maybe the following will help you enjoy the process as much as I did.

Simplified Payment Protocol (BIP270)

Any look into the BSV’s P2P transaction protocols naturally starts with the Simplified Payment Protocol, otherwise known as BIP270 (or more accurately, BIP270 through to BIP274).

The Simplified Payment Protocol spec came our of a wallet workshop event at the start of 2019. It is itself based on the older BIP70 spec with a few simplifications made for developers’ sanity.

The concept is a pretty simple one to grasp:

  1. When an app wants a user to pay for something, it creates a “payment request” and presents a URL to the user which they enter in to their wallet - usually via a QR code.
  2. The wallet loads the payment request from the URL and presents the details to the user for confirmation.
  3. Once confirmed, the wallet sends a “payment” object, complete with raw transaction directly back to the host application.
  4. The app responds to confirm it received the transaction. Both parties are then free to broadcast the transaction as soon as they want.

BIP270 Protocol Sequence

The specification is a reasonable one. It’s easy enough to read, although does have the slight whiff of “design by standards committee” to it. But because all BSV’s P2P protocols follow this same basic flow, once you’ve grokked BIP270 you are well on your way to mastering P2P transactions. Kind of.

Handcash’s P2P implementation

One of the first wallets to announce support of BIP270 was Handcash. They’ve written some great dev docs which you can read here. In implementing the spec, it’s fair to say they’ve gone “off piste” slightly.

Things they’ve changed:

  • Uses JSON content types instead of the unfamiliar bitcoin/* content types that are introduced in BIP271. This is a relatively non-problematic change to be honest - but one to be aware of in case your service is strict about content types.
  • Repurposes the merchantData attribute as a means to give the wallet the name and logo of the merchant, instead of a way of passing any arbitrary data between merchant and wallet. It’s nice for the wallet to show a logo of the merchant, but this will be a problem if you actually intended to use the merchantData attribute for its intended purpose.
  • Introduces a new URL format that is different from the BIP272 URL format. I don’t really understand why they’ve done this. If the aim of a standard is to create a single experience that users can benefit from no-matter what wallet they use, then to introduce a different URL that requires a different QR code seems backwards. Thankfully other BIP270-supporting wallets seem to be following Handcash’s lead, so if you want maximum compatibility with a single QR code, the Handcash URL format is the way to go.

Paymail P2P capabilities

Paymail has its own P2P BRFC specifications. There are two relevant specs to read through:

Because Paymail involves resolving email-like addresses to Bitcoin addresses and depends on DNS, it’s a fundamentally different approach so it’s understandable that we need a different spec.

I like the Paymail P2P specs. They are well written, easy to work with, and are flexible enough to allow most of the same core functionality that can be delivered through BIP270. In my testing, the Paymail wallets that have implemented the P2P specs have all done so consistently and so it works well and reliably across the board.

Open Payment Protocol

The Open Payment Protocol was created by the folks building the Maxthon browser and is used by their built-in wallet, VBox. It has also been implemented by both Volt and DotWallet which makes this a protocol well worth paying attention to.

The OPP specs describe it as an “extension to BIP270”. In addition to BIP270’s features, it allows apps to specify which UTXOs should be spent in a transaction, and also provides a way to let wallets sign arbitrary bits of data. Both pretty interesting and useful features.

However, whilst OPP follows the same basic flow of BIP270, it’s actually very different. The JSON objects that are sent as messages are entirely different and the way of encoding a URL in a QR code is different.

As an English speaker, I found the spec a little tricky to follow. There’s a few ambiguities that have crept in through translation. I also found some discrepancies between the VBox and Volt implementations that required some hacky server-side jiggery-pokery to ensure OPP “just works” across both wallets. I unfortunately haven’t been able to get it to work in DotWallet at all yet.


So there we have it - three P2P specs each claiming to be the greatest and most flexible standards. And we might as well call it four as we effectively have vanilla BIP270 vs Handcash flavoured BIP270.

I’m not sure the user wins in this situation, but for now I’m glad we at least have competing standards. It’s probably true that the people trying new things and innovating the most are not necessarily those sat in technical standards committees, so to that end I’m sympathetic to Handcash making a few changes and Maxthon doing their own thing entirely.

Maxthon’s OPP brings some novel and potentially very useful concepts to the table but I wish it could have been built on top of the standard BIP270 JSON objects and URLs, instead of rewriting everything.

If studying the Web tells us anything, it’s that users will demand standards and so it will be in wallet ecosystem’s interest to naturally revolve around one solid standard. My money is on BIP270, but it will take time to get there and we’re early enough in all of this to allow a bit of enthusiastic experimentation along the way.