* [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs @ 2026-03-25 12:00 'Sean Carlin' via Bitcoin Development Mailing List 2026-03-26 0:15 ` pyth 2026-03-26 14:02 ` [bitcoindev] " Thomas Suau 0 siblings, 2 replies; 5+ messages in thread From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-25 12:00 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --] 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc432a06n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 2262 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-26 0:15 ` pyth 2026-03-26 16:19 ` 'Sean Carlin' via Bitcoin Development Mailing List 2026-03-26 14:02 ` [bitcoindev] " Thomas Suau 1 sibling, 1 reply; 5+ messages in thread From: pyth @ 2026-03-26 0:15 UTC (permalink / raw) To: Sean Carlin, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2616 bytes --] 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+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc432a06n%40googlegroups.com > . -- 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fede50f58f286763106ba143e7530990eb7d86c1.camel%40pythcoiner.dev. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 2026-03-26 0:15 ` pyth @ 2026-03-26 16:19 ` 'Sean Carlin' via Bitcoin Development Mailing List 0 siblings, 0 replies; 5+ messages in thread From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-26 16:19 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3971 bytes --] 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 On Thursday, 26 March 2026 at 14:21:27 UTC pyth wrote: > 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 > > . > -- 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b6af2c43-1bde-4f64-a2aa-42d948b9a1fen%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 6399 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 'Sean Carlin' via Bitcoin Development Mailing List 2026-03-26 0:15 ` pyth @ 2026-03-26 14:02 ` Thomas Suau 2026-03-26 16:02 ` 'Sean Carlin' via Bitcoin Development Mailing List 1 sibling, 1 reply; 5+ messages in thread From: Thomas Suau @ 2026-03-26 14:02 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2493 bytes --] 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 Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit : > 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cb192fdb-e26e-463f-97be-fbb627ce84adn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 4071 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 2026-03-26 14:02 ` [bitcoindev] " Thomas Suau @ 2026-03-26 16:02 ` 'Sean Carlin' via Bitcoin Development Mailing List 0 siblings, 0 replies; 5+ messages in thread From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-26 16:02 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3758 bytes --] 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 On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote: > 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 > > Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit : > >> 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e501ab92-6911-4437-ac06-d7f547c2190dn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 6107 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-03-26 18:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 'Sean Carlin' via Bitcoin Development Mailing List 2026-03-26 0:15 ` pyth 2026-03-26 16:19 ` 'Sean Carlin' via Bitcoin Development Mailing List 2026-03-26 14:02 ` [bitcoindev] " Thomas Suau 2026-03-26 16:02 ` 'Sean Carlin' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox