From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Apr 2026 11:19:59 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w9oYI-0002F3-Sj for bitcoindev@gnusha.org; Mon, 06 Apr 2026 11:19:59 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-6839602ee09sf2361902eaf.1 for ; Mon, 06 Apr 2026 11:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775499592; x=1776104392; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=nz6lyz4fZZ1rXKq27jljQfmYUL93mH5XHitkVuDmDjg=; b=IRv278Lt02KV6609MjU/714NfSL64eGntvsIun2dMr8Re0TqfmUa/b1QcTMTkJyiZn Nz36Tf7kjyzrKYm3oFoKiewP3TEGi1hEZA439BUD9pSW6TQlVrXLh/YacT46zAHoLhM8 N73eGpFbO/OY75zXrInmAEqH66oPpxzaboHu5gvNf1Dli13RTD7sdmkrG5qWIxGotmDP 8mbNPfwVac25UIVScOCms/9bkSkWhQNNl/D/AV9pzjWER3iAfDDqI6dvL3Xmx9XvpRkz 4KxnKAaS12StF8BawIejgo/Gke4rkdQ5PZoH++fyHhFDajynQucCY0NQj2iD0y2ZtE8y bzEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775499592; x=1776104392; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nz6lyz4fZZ1rXKq27jljQfmYUL93mH5XHitkVuDmDjg=; b=rwe6fiBWhy/hEBV5mfjfxs3GIbIJIak66GaLTcoWxUuiS33YBVxWF11lKO53jQEzla 4Pac10r6kNpTgv0NqqK4L0nzplcrSHkMZ8W68e5OCZmw9uu8hTmZvo/ntdHq87Ud8uAB oYI0x9j04wWHEXLyaKxrhRwMXWmodek7fx5xffg/+Jt8iVvKDVIsnIT+TqoBgjSrFx/Q yE8WSdmiyXxok6rWeeeQPH9Sp73Hq0mRsKVD6I6n5sQSguzzRR9CfNBuAZ6061ndfYQp firjTXbZLuQgj+jPQb+dgT0lg3JR9Lkl6Psn6KVX4+0U67vwyatGfq65wQchNJwsQayr U72w== X-Forwarded-Encrypted: i=1; AJvYcCXCj/bqPCGPFqB5hUqh2TB/QO7asn4lraEt+RhwKqW5lThO7Kjijvrk/mtzgVCJxK5KMNmZpqwlo8y1@gnusha.org X-Gm-Message-State: AOJu0YyKwjv3uV31pwfrOvFEtMKZ+iHMRWkwO38rTfZzSQKPeNl/qKkE Ush9NCAJy5Y4Lg/I6MGs1pr9dOIGYfdAT5qi48SIa9FWuVd3riGtx/GQ X-Received: by 2002:a05:6820:2004:b0:67e:33fb:221b with SMTP id 006d021491bc7-6821ef7f0d5mr7690357eaf.16.1775499592321; Mon, 06 Apr 2026 11:19:52 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLJdknr2ZCH/zYEiT+N3ZR8WiEk+xvmQPwQTkrb+OXo6Q==" Received: by 2002:a4a:e7c1:0:b0:685:89e0:a6d0 with SMTP id 006d021491bc7-68589e0ac04ls817591eaf.2.-pod-prod-07-us; Mon, 06 Apr 2026 11:19:46 -0700 (PDT) X-Received: by 2002:a54:4e8f:0:b0:466:f60b:19d5 with SMTP id 5614622812f47-46ef54f6a26mr5397164b6e.8.1775499586377; Mon, 06 Apr 2026 11:19:46 -0700 (PDT) Received: by 2002:a05:690c:c3c2:b0:79a:37dc:255a with SMTP id 00721157ae682-7a24e29ec56ms7b3; Fri, 3 Apr 2026 04:03:14 -0700 (PDT) X-Received: by 2002:a05:690c:4806:b0:79a:e027:3b1c with SMTP id 00721157ae682-7a4d663da23mr27756427b3.54.1775214194380; Fri, 03 Apr 2026 04:03:14 -0700 (PDT) Date: Fri, 3 Apr 2026 04:03:13 -0700 (PDT) From: "'Sean Carlin' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com> Subject: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_49398_705784891.1775214193824" X-Original-Sender: SeanCarlin90@googlemail.com X-Original-From: Sean Carlin Reply-To: Sean Carlin Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_49398_705784891.1775214193824 Content-Type: multipart/alternative; boundary="----=_Part_49399_208593153.1775214193824" ------=_Part_49399_208593153.1775214193824 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Following up on the ongoing development of the Signing Room (and the Blind= =20 Relay coordination model), I've just released v1.8.0. While previous updates focused heavily on the cryptographic and protocol=20 layers, this release hardens the Operational Security (OpSec) at the human= =20 layer. The Threat Model: A zero-knowledge server architecture is compromised if the Coordinator=20 inadvertently shares the room URL and the decryption key (the #key=20 fragment) over the same insecure channel (e.g., pasting the full link into= =20 Slack or a standard email). The Solution (v1.8.0): I have introduced strategic UI friction to actively train users to adopt a= =20 "Split-Key" transport model, encouraging them to send the payload and the= =20 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=20 replaced. Coordinators must now explicitly choose between "Maximum=20 Security" (copies the base URL without the decryption fragment) and=20 "Standard" (the full combined link) via an interactive modal. Secure-by-Default QR Codes: QR codes generated for in-person or video-call= =20 coordination now default to "Link Only". The UI actively re-blurs the=20 canvas if the user toggles to include the key, preventing accidental=20 shoulder-surfing. Privilege Friction: Added explicit, color-coded warning modals when a=20 Coordinator attempts to copy the Room Decryption Key or the Backup Admin=20 Token, explaining the specific blast radius of each asset. The goal is to make the secure path the easiest path, and force an active,= =20 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= =20 who regularly coordinate multisig ceremonies. Best regards, Sean Carlin On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrote: > Hi Thomas,=20 > I=E2=80=99ve been looking through your BTSL playground source code. To ma= ke this=20 > work seamlessly with the Blind Relay reference implementation (Signing=20 > Room), it would be great if the BTSL parser and validator were available = as=20 > a standalone, versioned NPM package. > > If we had an @btsl/validator package that was environment-agnostic (no=20 > internal fetch calls to Blockstream, just pure PSBT/Schema validation and= =20 > minimal dependencies), I could potentially integrate it directly into the= =20 > Signing Room client. This would allow 'Signing Room' to automatically=20 > detect an attached schema, run the ASSERT logic locally, and provide the= =20 > 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= =20 > schema and type: > > {=20 > "type": "STATE_SYNC",=20 > "encryptedPsbt": "base64_encrypted_psbt",=20 > "encryptedValidationSchema": "base64_encrypted_btsl_string", //=20 > Optional=20 > "schemaType": "BTSL_V1", // Optional: Identifies the language Or=20 > Version ...=20 > } =20 > > Let me know your thoughts, > > All the best > Sean Carlin > > > > On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote: > >> Hello,=20 >> The transport layer problem is well addressed here. The complementary=20 >> piece =E2=80=94 ensuring signers can independently validate transaction = invariants=20 >> before signing, regardless of how the PSBT was relayed =E2=80=94 is what= I've been=20 >> exploring with BTSL:=20 >> https://delvingbitcoin.org/t/btsl-bitcoin-transaction-schema-language-a-= declarative-validation-schema-for-psbt-workflows/2338 >> >> Best regards,=20 >> Thomas Suau >> >> Le mercredi 25 mars 2026 =C3=A0 13:21:39 UTC+1, Sean Carlin a =C3=A9crit= : >> >>> Hi everyone, >>> >>> I'd like to propose a new BIP for real-time, trust-minimized=20 >>> coordination of multi-signature PSBTs. >>> >>> The Problem >>> Coordinating N-of-M Bitcoin transactions currently forces users into a= =20 >>> binary choice: >>> - Manual out-of-band transfers (USB drives, secure messengers) that=20 >>> preserve privacy but introduce high friction and error risk, or >>> - Stateful coordination servers that offer good UX but act as privacy= =20 >>> honeypots, logging metadata, signer relationships, and often storing PS= BTs=20 >>> on disk. >>> >>> The Proposal: Blind Relay >>> This BIP introduces a "Blind Relay" - an ephemeral, stateless,=20 >>> zero-knowledge WebSocket relay. All payloads are encrypted client-side = with=20 >>> AES-GCM-256, with decryption keys held exclusively in client-side URL= =20 >>> fragments (never sent to the server). The relay operates entirely in RA= M=20 >>> with a strict 24-hour TTL and self-destructs upon completion, providing= =20 >>> real-time coordination without persistent metadata or disk storage. >>> >>> A reference implementation has been running in production for three=20 >>> months, successfully facilitating real multisig ceremonies. >>> >>> *Links* >>> - BIP Draft:=20 >>> 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=20 >>> specification, security model, edge cases, and any suggested improvemen= ts. >>> >>> Best regards, >>> Sean Carlin >> >> --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com. ------=_Part_49399_208593153.1775214193824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone,

Following up on the ongoing development of the Sign= ing Room (and the Blind Relay coordination model), I've just released v1.8.= 0.

While previous updates focused heavily on the cryptographic a= nd protocol layers, this release hardens the Operational Security (OpSec) a= t the human layer.

The Threat Model:
A zero-knowledge serve= r architecture is compromised if the Coordinator inadvertently shares the r= oom URL and the decryption key (the #key fragment) over the same insecure c= hannel (e.g., pasting the full link into Slack or a standard email).
<= br />The Solution (v1.8.0):
I have introduced strategic UI friction to= actively train users to adopt a "Split-Key" transport model, encouraging t= hem to send the payload and the key via separate, out-of-band channels.

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

Secure-by-Default QR Codes: QR codes generat= ed 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, pr= eventing accidental shoulder-surfing.

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

The goal is to make the secure path th= e easiest path, and force an active, conscious downgrade for convenience.
Full release notes and UI screenshots can be found here:
htt= ps://github.com/scarlin90/signingroom/releases/tag/v1.8.0

As alw= ays, I welcome any feedback on the UX/OpSec balance from those of you who r= egularly coordinate multisig ceremonies.

Best regards,

Sean Carlin

On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrot= e:
Hi Thomas,= =C2=A0
I=E2=80=99ve been looking through your BTSL playground source co= de. To make this work seamlessly with the Blind Relay reference implementat= ion (Signing Room), it would be great if the BTSL parser and validator were= available as a standalone, versioned NPM package.

If we had an @bts= l/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. Th= is would allow 'Signing Room' to automatically detect an attached s= chema, run the ASSERT logic locally, and provide the user with a 'Verif= ied by BTSL' green-check before they sign.

The STATE_SYNC payloa= d could be modified to something like this to pass a schema and type:
=C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0"type": "STAT= E_SYNC",=C2=A0
=C2=A0 =C2=A0 =C2=A0"encryptedPsbt"= : "base64_encrypted_psbt",=C2=A0
=C2=A0 =C2=A0 =C2=A0&q= uot;encryptedValidationSchema": "base64_encrypted_btsl_string&quo= t;,=C2=A0 // Optional=C2=A0
=C2=A0 =C2=A0 =C2=A0"schemaType&= quot;: "BTSL_V1", // Optional: Identifies the language Or Version= ...=C2=A0
}=C2=A0=C2=A0

Let me know your = thoughts,

All the best
Sean Carlin
=



On Thursday, 26 March 2026 at 14:= 21:41 UTC Thomas Suau wrote:
Hello,=C2=A0
The transport layer problem is well addressed here.= The complementary piece =E2=80=94 ensuring signers can independently valid= ate transaction invariants before signing, regardless of how the PSBT was r= elayed =E2=80=94 is what I've been exploring with BTSL: https://de= lvingbitcoin.org/t/btsl-bitcoin-transaction-schema-language-a-declarative-v= alidation-schema-for-psbt-workflows/2338

Best regard= s,=C2=A0
Thomas Suau

Le mercredi 25 mars 2026 =C3=A0 13:21:39 UTC= +1, Sean Carlin a =C3=A9crit=C2=A0:
Hi everyone,

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

The P= roblem
Coordinating N-of-M Bitcoin transactions currently forces users i= nto a binary choice:
- Manual out-of-band transfers (USB drives, secure = messengers) that preserve privacy but introduce high friction and error ris= k, or
- Stateful coordination servers that offer good UX but act as priv= acy honeypots, logging metadata, signer relationships, and often storing PS= BTs on disk.

The Proposal: Blind Relay
This BIP introduces a &quo= t;Blind Relay" - an ephemeral, stateless, zero-knowledge WebSocket rel= ay. All payloads are encrypted client-side with AES-GCM-256, with decryptio= n keys held exclusively in client-side URL fragments (never sent to the ser= ver). The relay operates entirely in RAM with a strict 24-hour TTL and self= -destructs upon completion, providing real-time coordination without persis= tent metadata or disk storage.

A reference implementation has been r= unning in production for three months, successfully facilitating real multi= sig ceremonies.

Links
- BIP Draft: https://github.com/scarlin9= 0/bip-stateless-psbt-coordination/blob/main/bip-draft.md
- Source Co= de: https://git= hub.com/scarlin90/signingroom
- Live Client: https://signingroom.io
- Related Research Paper: https://arxiv.org/abs/2601.17875

I loo= k forward to your technical feedback - especially on the specification, sec= urity model, edge cases, and any suggested improvements.

Best regard= s,
Sean Carlin

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com.
------=_Part_49399_208593153.1775214193824-- ------=_Part_49398_705784891.1775214193824--