Initiating contact

#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

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 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 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 packet 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 packet to someone who he does not formally have an open channel with, gets an initial response on the channel containing the . 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 packet 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 packet 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 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 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..