REElay 😡: BIP 78-compatible Gullible Payjoin PoC (WebSockets)

[DanGould]

This proof of concept demonstrates the ability to receive a payjoin using a relay instead of hosting a public https or onion endpoint. I intend this to be an easy way to receive payjoin in testing environments and potentially as a BIP 78 payjoin v1 compatible fallback for a v2 Serverless Payjoin spec.

BIP 78 Compatibility

The PSBT payload is neither encrypted nor authenticated, so it is compatible with BIP-78 senders without any changes. According spec terminology, the REElay is an unsecured payjoin server, so output substitution must be disabled. Unlike in a v2 Serverless Payjoin, there is no privacy protection from the REElay server.

Protocol Flow

1. The REElay server hosts both WebSockets and HTTP servers with public endpoints.
2. A receiver first makes a WebSockets connection to the REElay to await a BIP 78 Original PSBT POST
3. The receiver shares a bip21 including the REElay's public http endpoint with output substitution disabled e.g. bitcoin:BCRT1QGSKP9RN59L3KXJQPC5RNDC7M50RCH36WUV6232?amount=0.00888888&pj=https://reelay&pjos=0
4. A sender's sends a normal payjoin POST request to the &pj= endpoint containing an Original PSBT body.
5. The REElay marshals the HTTP request to the receiver as a message over the WebSockets connection and awaits response
6. The receiver processes the HTTP request according to BIP 78 and constructs an HTTP response as normal.
7. The receiver marshals the HTTP response to the REElay over WebSockets
8. The REElay returns this response to the sender

The interaction is unchanged BIP 78 from the sender's perspective. The new protocol burden is shared between REElay and receiver.

Design

WebSockets allows a persistent connection so that the REElay may respond with unavailable if no receiver is connected. Using both HTTP and WebSockets allows for compatibility with existing deployments. The REElay server could support a secure, non-REE, asynchronous, version 2 payjoin protocol and offer the synchronous REElay version as a fallback to support senders having only payjoin v1 support. A production version could use any streaming protocol, not limited to WebSockets, and should use the same dependency as a v2 payjoin protocol to minimize network dependency requirements.

What's missing?

Allocation

This PoC only hosts a single endpoint to receive payjoins at root. A production version would require a mechanism for receivers to allocate a subdirectory from which POST requests would be relayed. There has to be some way for the REElay to know who to relay requests to.

DoS Protection

There is no protection from someone connecting to the websocket over and over using up all of the REElay server's resources. There should be some API Token (warning: identifying), PoW (expensive), or other cost associated with making an allocation

[DanGould]

Some subcommits don't build from 4f18204 to 3ed2753. Each subcommit should build