#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.

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

Starting simple

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

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.”
  2. Alice’s wallet receives the Message packet from someone who she does not have an open channel with, and because she has set an “attention fee” of $5 USD, it responds with a PaymentRequestpacket asking for ~$5 USD and including a memo of “Alice’s whitelisting process requires a payment”.
  3. Bob’s wallet knowing it’s sent a Message packet to someone who he does not formally have an open channel with, gets an initial response on the channel containing the PaymentRequest. It shows the incoming message from Alice as a payment form embedded in the conversation dialog. It has a expiration date, as payment requests do, which if Bob does not pay by Alice will discard it and junk the channel.
  4. Bob clicks “Pay” on the form and his wallet sends a Paymentpacket to Alice. Alice’s wallet checks the included transaction is valid, and then notifies Alice, showing her the initial message from Bob and the accompanying payment. Alice can opt to open the channel formally and accept the payment, in which case her wallet sends it to the P2P network and sends Bob a PaymentACKpacket which his wallet uses to update what he sees. Alice can also opt to not take the payment, and open the channel with Bob who she might know — although there’s no BIP 270 packet for that.
  5. At this point Bob and Alice can send each other Message and other packet types freely, and when their wallet syncs, they will get notification of new messages.

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?

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..

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