Summary of Payjoin/Gordian Meeting @ May 1st, 2024

[shannona]

May's Gordian Developer's Meeting including a special presentation on Payjoin, a presentation on Request/Response, and additional info on the newest Gordian developments.

Sponsors

Blockchain Commons' sponsors have been having troubles with funding in the last year or year and half, which means that Blockchain Commons has as well.

Consider becoming a sponsor to support this continuing work.

Contact Blockchain Commons directly to become a company sponsor, but they also are very appreciative of individual sponsors, as it helps to demonstrate to other organizations that Blockchain Commons has developer support.

SSH-Envelope

Blockchain Commons released a preview of ssh-envelope. This is a python integration with the rust envelope CLI

You could always sign & verify with Gordian Envelopes

• But that was beholden to Blockchain Common's specific crypto-choices
• And Envelope is ultimately crypto-agnostic

ssh-envelope demonstrates that!

Other Advances

• New summary & features of Gordian Envelope on Developer web site
• Quarterly report
• Representing Graphs BCR

Representing Graphs

The Represent Graphs doc is BCR-2024-006.

Can you represent a graph using a tree like Gordian Envelope?

Yes!

The BCR has examples and compares to RDF. Looking forward to community feedback!

PayJoin

Thanks to Dan Gould for our feature presentation for May.

We need privacy at all layers of the payment stack. Leaks will add up. Hence, Payjoin.

BIP79 came out of Bustapay, ultimately standardized with HTTP for network.

Dan Gould is now working on new version where receiver doesn't need to have a server.

Why Payjoin?

• The Bitcoin blockchain is slow.
• Today, the sender submits all of the UTXOs.
• Which makes it obvious who's paying who.
• Payjoin instead makes batches, which also helps scaling

Here's what a classic/basic transaction look like:

• Receiver sends address to sender, who creates transaction and puts it on network
• This has privacy problems: assumption is that single person creates all the input
• They're also costly, 1 transaction intent = 1 transaction

Payjoin V1 tried to fix this through interactions between receiver & sender outside of chain using PSBTs.

• Receiver sends not just Address, but Endpoint as well!
• Sender now sends a POST request to Receiver with PSBT
• Receiver can then adjust PSBT to consolidate their own Bitcoin if they want!
• And return it as HTTP response
• If it was changed, Sender now can decide to re-sign transaction & broadcast.
• If that doesn't work, Receiver can just broadcast original PSBT!

Unfortunately, Payjoin v1 is hard to use!

• Wallets have been able to create Sender logic
• But receiver has to run a server
  • They need to be able to communicate to sender that they changed PSBT
  • Those intermediate steps need to be private, else you can undo privacy!
• It's also synchronous, which is a problem for receiver
• Using a Tor server helps, but that restricts usage!

That's where Payjoin v2 comes in.

It introduces a directory (a store and forward server).

• Which accepts PSBTs and forwards them

New procedure is:

1. Request subdirectory on store-and-forward server
2. Enroll a public key
3. Basic PSBT sent
4. Payjoin PSBT sent

The synchronous nature of Payjoin is solved by polling to always-on directory server.

• As long as subdirectory has not expired

This gets rid of need for certificates, again because of directory

• The server deals with certificates

What about IP address leaks?

• They're resolved with Oblivious HTTP (relay)
• It's a solution that gives you 80% of benefit of Tor with 20% of effort
• Run by different people than who is running directory server

As long as the relay and directory don't COLLUDE, you can expect network privacy!

• Without need for heavy dependency of Tor

Ergonomic dependencies

• Bitcoin URIs request Payjoin (BIP21)
• But how best to encode all the elements?

Spec uses Hybrid Pubkey Encryption (HKPE) to share public keys

• No TLS dependency!
• No new cryptographic dependencies from typical Bitcoin software

The encoding issue is still an open concern!

• One of the problems is that standard methods such as Base64Url make QRs that are too dense
• Bec32m is another option, but "=" and "?" aren't in QR alphanumeric coding, requiring mixed mode
• So, URs might be a choice

Improvement over Mixing?

• Mixing costs more money!
• Mixing makes it explicit on blockchain that you're engaging in privacy protocol

TRYING to preserve two types of transactions

1. Third Person
   • Shouldn't know who paid who
   • Or how much they paid
   • Payjoin looks like other transactions
2. Second Person
   • Receiver shouldn't know where inputs came from
   • Sender shouldn't know where they went
   • But it'd require another (third) person!

So current version of Payjoin v2 solves third-person issues, but second-person remains open.

Payjoin v2 can currently be used/tested in a bitcoin-core CLI

• Directory is up and running
• Relays are up and running

But need to make final decisions before this goes out into wild.

See BIP77, PR 1483 for more.

Discussions

Exact problems that Blockchain Commons had with encoding!

• ran into same problems, for example with "=" and "?"
• qrencoder library in Swift
  • supports mixed mode, which basic iOS library does not
• UR ultimately allowed Blockchain Commons to resolve these issues

UR

• keeps things to alphanumeric mode for QRs
  • But also allows mixed mode
• supports animated QRs
  • using fountain codes
• supports very constrained displays & inputs

One of the advantages of UR might be expandability, particularly as multisigs become more common!

Support BIP21 as the lowest case!

• But could reach critical mass to swap to "BIP21+" that uses URs, thanks to existing support from Sparrow, Foundation Devices, and others

Request/Response

The Request/response presentation talked about Envelope's Request/response methodology: how it works and why it's useful.

How Request/Response Works

This is primarily covered in new implementation guide.

Fundamentally:

• a request is build as an expression (function) in Envelope
  • It's then wrapped up with a specific ARID (random id)
• a response is built as an envelope with the requested data as the subject and an isA predicate defining the data
  • It's then wrapped up with the same ARID as the request

There are details, but that's the basis! See the implementation guide for more.

Why to Use Request/Response

Obviously, Request/Response offers advantages of interoperability.

However, its automation capabilities may be more important.

Blockchain Commons recently released a use case taht describes the creation of multisigs, something that can be done using Sparrow as a Transaction Coordinator for a variety of handheld devices.

The problem is that the system is currently too complex for users. It requires considerable knowledge of all the systems involved and considerable human interaction.

A Request/Response system can resolve that by automating the process: the Transaction Coordinator now acts as a conductor for the entire system, with the user retaining their agency through confirmations of major actions or data transfers.

Discussion

There was some question about whether Blockchain Commons has a name for their methodology of decision points, research points, etc, that was used to note the complexity of the multisig creation? And whether they'd used it elsewhere?

It sort of came out of their adversarial work in Smart Custody. These time and complexity difficulties are adversaries that prevent users from achieving Smart Custody.

There was also discussion of the NASCAR problem where there is a "a jumble of branding icons in a user interface", usually as a program like Sparrow lists out all of the options for connectivity with different devices. It's complex for users and requires developers to constantly update their system.