#proof-of-words — packetised payment requests over the blockchain.

I write these design notes mostly for my own use, and write them as articles because it helps me understand what I was thinking when I get around to working on them, which can often be quite a while after they were written.

We have an unpublished workable specification we’ve written for how an on-chain identity system could be implemented, where Bob wants to contact Alice, but Alice has a “first contact payment” to put a price on gaining her attention, and Bob pays it and then has opened a private and secure communication channel with Alice. I have no intention of publishing that, but this builds on it.

This article explores embedding BIP 270, the system of JSON-based payment requests.

Image for post
Image for post
This is probably the only image you’ll see in this wall of text.

Starting simple

My first approach was intentionally simple and no effort had been put into thinking it out beyond how the identity system would carry it. It was to define two types of message, the first “contact-initiation” and the second “message”.

The “contact initiation” message, includes the identity of the person requesting contact, a payment that may be defined as necessary to do this (extracted from the identity of the recipient, which the sender must have to get this far), and maybe some note.

The “message” message includes a note. No identity is needed, as any messages over the channel can only be between Bob and Alice. If a payment was attached, Alice could choose to accept it.

Bob would send a “contact initiation” message to Alice who would then process or ignore it. If she processed it, she would then ideally proceed to accept further “message” messages from Bob, otherwise she would ignore them.

The obvious problem with this is that payments are tacked on. So how could this work if the channel treated the payment request as part of the protocol?

Getting complicateder

BIP 270 is “the simplified payment protocol”, which encapsulates the process of being asked for a payment, paying it, and getting an acknowledgement of the payment. Why can’t we address the over-simplicity of the simple model, by incorporating it as a basic communication action.

Let’s see how it might go:

  1. Bob sends a Message packet to a contact he does not have an open channel with, Alice, saying “Hi Alice, add me to your contacts as discussed.”

BIP 270 doesn’t quite map to the full set of packets required — for instance PaymentACK might be extended to cover concluded a payment sequence, but optionally with a waived payment. But it does provide an easy way for wallet software to formalise and automate a process, between users over the blockchain, with user-friendly UI.

Still reading?

What other packet types might be useful?

We can look at the payment protocol as a process of wallets coordinating on behalf of users. Another wallet process that might be coordinated this way, is the creation of a multi-signature wallet. Or the signing of a multi-signature transaction.

Any thoughts?

Buehler.. Buehler.. Bueller..

Written by

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store