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
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
Development Mailing List wrote:
> 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
> --
> 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
> .