[BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs

[Sean Carlin]

Hi everyone,

I'd like to propose a new BIP for real-time, trust-minimized coordination of multi-signature PSBTs.

The Problem
Coordinating N-of-M Bitcoin transactions currently forces users into a binary choice:
- Manual out-of-band transfers (USB drives, secure messengers) that preserve privacy but introduce high friction and error risk, or
- Stateful coordination servers that offer good UX but act as privacy honeypots, logging metadata, signer relationships, and often storing PSBTs on disk.

The Proposal: Blind Relay
This BIP introduces a "Blind Relay" - an ephemeral, stateless, zero-knowledge WebSocket relay. All payloads are encrypted client-side with AES-GCM-256, with decryption keys held exclusively in client-side URL fragments (never sent to the server). The relay operates entirely in RAM with a strict 24-hour TTL and self-destructs upon completion, providing real-time coordination without persistent metadata or disk storage.

A reference implementation has been running in production for three months, successfully facilitating real multisig ceremonies.

Links
- BIP Draft: https://github.com/scarlin90/bip-stateless-psbt-coordination/blob/main/bip-draft.md
- Source Code: https://github.com/scarlin90/signingroom
- Live Client: https://signingroom.io
- Related Research Paper: https://arxiv.org/abs/2601.17875

I look forward to your technical feedback - especially on the specification, security model, edge cases, and any suggested improvements.

Best regards,
Sean Carlin

[pyth]

Hi Sean, this is interesting, but note that bitcoin core doesn't have
dependencies for AES-GCM-256, while it have dependencies for CHACHA20-
POLY1305.

Best,
Pyth

On Wed, 2026-03-25 at 05:00 -0700, 'Sean Carlin' via Bitcoin

> --
> You received this message because you are subscribed to the Google
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc432a06n%40googlegroups.com
> .

[Thomas Suau]

Hello, 

The transport layer problem is well addressed here. The complementary piece — ensuring signers can independently validate transaction invariants before signing, regardless of how the PSBT was relayed — is what I've been exploring with BTSL: https://delvingbitcoin.org/t/btsl-bitcoin-transaction-schema-language-a-declarative-validation-schema-for-psbt-workflows/2338

Best regards, 
Thomas Suau

[Sean Carlin]

Hi Pyth,

That is a fair point regarding Bitcoin Core's existing dependencies. I chose AES-GCM-256 specifically because this BIP targets Application Layer coordination, with a focus on cross-platform ubiquity (Web PWAs, Mobile, and Desktop).

For these environments, AES-GCM is a core primitive of the Web Crypto API, meaning it is implemented natively and audited by browser/OS vendors. Standardizing on ChaCha20-Poly1305 would force web and mobile developers to bundle external, unoptimized JavaScript cryptographic libraries. In the context of a browser-based or mobile coordinator, I believe relying on native, hardware-accelerated OS primitives provides a smaller and more secure attack surface than importing third-party JS dependencies.

If the protocol were strictly node-to-node (Transport Layer), I would agree on ChaCha20. But for client-to-relay coordination, the Web Crypto API support makes AES-GCM the safer choice for the average user's device in my opinion.

Happy to discuss further if you see a reason why supporting ChaCha20 is a benefit other than ecosystem alignment.
I updated the BIPs rationale section with this earlier today.

All the best,
Sean Carlin

[Sean Carlin]

Hi Thomas, 

I’ve been looking through your BTSL playground source code. To make this work seamlessly with the Blind Relay reference implementation (Signing Room), it would be great if the BTSL parser and validator were available as a standalone, versioned NPM package.

If we had an @btsl/validator package that was environment-agnostic (no internal fetch calls to Blockstream, just pure PSBT/Schema validation and minimal dependencies), I could potentially integrate it directly into the Signing Room client. This would allow 'Signing Room' to automatically detect an attached schema, run the ASSERT logic locally, and provide the user with a 'Verified by BTSL' green-check before they sign.

The STATE_SYNC payload could be modified to something like this to pass a schema and type:

  { 

     "type": "STATE_SYNC", 

     "encryptedPsbt": "base64_encrypted_psbt", 

     "encryptedValidationSchema": "base64_encrypted_btsl_string",  // Optional 

     "schemaType": "BTSL_V1", // Optional: Identifies the language Or Version ... 

}  

Let me know your thoughts,

All the best

Sean Carlin

[Sean Carlin]

Hi everyone,

Following up on the ongoing development of the Signing Room (and the Blind Relay coordination model), I've just released v1.8.0.

While previous updates focused heavily on the cryptographic and protocol layers, this release hardens the Operational Security (OpSec) at the human layer.

The Threat Model:
A zero-knowledge server architecture is compromised if the Coordinator inadvertently shares the room URL and the decryption key (the #key fragment) over the same insecure channel (e.g., pasting the full link into Slack or a standard email).

The Solution (v1.8.0):
I have introduced strategic UI friction to actively train users to adopt a "Split-Key" transport model, encouraging them to send the payload and the key via separate, out-of-band channels.

Key updates in this release include:
Explicit Split-Key Sharing: The standard 1-click "Share" button has been replaced. Coordinators must now explicitly choose between "Maximum Security" (copies the base URL without the decryption fragment) and "Standard" (the full combined link) via an interactive modal.

Secure-by-Default QR Codes: QR codes generated for in-person or video-call coordination now default to "Link Only". The UI actively re-blurs the canvas if the user toggles to include the key, preventing accidental shoulder-surfing.

Privilege Friction: Added explicit, color-coded warning modals when a Coordinator attempts to copy the Room Decryption Key or the Backup Admin Token, explaining the specific blast radius of each asset.

The goal is to make the secure path the easiest path, and force an active, conscious downgrade for convenience.

Full release notes and UI screenshots can be found here:
https://github.com/scarlin90/signingroom/releases/tag/v1.8.0

As always, I welcome any feedback on the UX/OpSec balance from those of you who regularly coordinate multisig ceremonies.

Best regards,

Sean Carlin

[STEVEN SLATER]

Subject: Feedback on Blind Relay & BTSL Integration  

Hi Murch,  

Thanks for engaging with the Blind Relay proposal and the Signing Room updates. I wanted to highlight a couple of areas where your perspective would be especially valuable:  

- OpSec Friction in v1.8.0: The release introduces explicit split-key sharing and secure-by-default QR codes. Do you see this balance of UX vs. security as sufficient for real-world multisig ceremonies, or are there edge cases where additional friction might be warranted?  

- BTSL Validator Integration: The idea of a standalone @btsl/validator package could allow Signing Room clients to locally verify transaction invariants before signing. From your experience with PSBT workflows, do you think this approach would meaningfully reduce signer risk, or does it introduce complexity that might discourage adoption?  

- Blind Relay Model: Since the relay is stateless and ephemeral, it avoids metadata persistence. Do you think this adequately addresses privacy concerns compared to existing coordination servers, or are there attack surfaces we should still consider?  

I’d really appreciate your thoughts on whether these design choices align with the broader goals of minimizing trust and maximizing signer independence.  

Best regards, 

Steven

--

You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com.