From: "'Sean Carlin' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
Date: Fri, 3 Apr 2026 04:03:13 -0700 (PDT) [thread overview]
Message-ID: <acde2e84-15f1-4a15-9fac-cb5de96208ecn@googlegroups.com> (raw)
In-Reply-To: <e501ab92-6911-4437-ac06-d7f547c2190dn@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 5899 bytes --]
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
On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrote:
> 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/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8494 bytes --]
next prev parent reply other threads:[~2026-04-06 18:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 12:00 [bitcoindev] " '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
2026-04-03 11:03 ` 'Sean Carlin' via Bitcoin Development Mailing List [this message]
2026-04-06 20:12 ` STEVEN SLATER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acde2e84-15f1-4a15-9fac-cb5de96208ecn@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=seancarlin90@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox