From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 13 Apr 2026 12:21:55 -0700 Received: from mail-qk1-f189.google.com ([209.85.222.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCMr3-0007HE-M0 for bitcoindev@gnusha.org; Mon, 13 Apr 2026 12:21:54 -0700 Received: by mail-qk1-f189.google.com with SMTP id af79cd13be357-8d5010ea730sf1091701585a.0 for ; Mon, 13 Apr 2026 12:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776108107; x=1776712907; 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=CD02SVuM0HWDZXcdWAUrwxRz43q7bLVN+6AETZKsyUI=; b=EP5M6U86ykFQaFXIwhzaGsf7Zm+YBQF3/pK/tzoI+HgBmzProTsg5FuOG7X2KDfOAH 2gvGxN1+wTMvfAC5V9/5mWqR+vf5Jac9vme3i1Sgjn4sL3kZnH9Bk8163HSAvxOC+ueE orldHDxA7GR2JoIlz6GjR/P4jL3p/V6yibO32IZS0Ad0rBr9mIQ7p+LnwTkPL5U3SRJT k0uZQkIawBbm1qgfsYfU6PSfwyBc+tsjM+MaezbLMt6M7ud8+s/4B/fwh7TihQSMGnfb qtFkcNQFVHuIb1KzpmQbAvmSOy7caST+MOtsXwfINI5a4lCdKG/kZzouQeA+s7jfOStM sHrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776108107; x=1776712907; 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=CD02SVuM0HWDZXcdWAUrwxRz43q7bLVN+6AETZKsyUI=; b=BY26HUyZHnK02TNPn2aEeC15oOl0xkbPAej4pUr968WHEkdX4OGCcX3lH0PPBFraqR t0VjK+iYfOo4BE8uhlNPpcW1MgNVlj6CXh3VSEuICe3s90Mf0dsvEH+lgaFRMkH03QXp rVSioVX3UfTJqFbuAnyloH5+iUmKMTj6LHGGU2MJRaGMhO9lDfKtIApeVtrMQyfPtgIY 0avB4mOEmQ9cQRV1p6iwrHyuBrxIChXYxwbyOOVsIh6cLiPViWkBBhut7GWkEq6SW7md lVZZjhoHVhkCVC4eS8xl7U52h9Z9u9lyZvNyBkxEnBsTSt5jx2ousNfw0e8Djtg6ubiv XhJQ== X-Forwarded-Encrypted: i=1; AFNElJ+Ub4BvM3DBNgEkOrcyPYQtQBKCnsNiNOVVmwfZdoxaAAaGlyRItH/vtCgNelpWZmpGGJgiq3U9FAEP@gnusha.org X-Gm-Message-State: AOJu0YxbRTzqelIxTSl2Hz2E3HOlNgn6+d8VDkPTKa4TK7JVc0Vwga7M 2sODI4n/ggbs4GBXgplAeASVsLbRVkE0rEdWLF+pu5MfMTg70vNOteY2 X-Received: by 2002:a05:620a:4542:b0:8cd:b317:d69f with SMTP id af79cd13be357-8dc444ad209mr2461740885a.17.1776108106718; Mon, 13 Apr 2026 12:21:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKvdhTJVsfLejk+B9balefkaOOwUa6Lq7ZqWDaR4w64eA==" Received: by 2002:a05:6214:20a9:b0:89c:d390:6162 with SMTP id 6a1803df08f44-8ac83502d2cls86872976d6.2.-pod-prod-07-us; Mon, 13 Apr 2026 12:21:40 -0700 (PDT) X-Received: by 2002:a0c:f102:0:b0:89c:dc57:326d with SMTP id 6a1803df08f44-8ac862a5fa6mr177432466d6.38.1776108100246; Mon, 13 Apr 2026 12:21:40 -0700 (PDT) Received: by 2002:a05:690c:fa:b0:79a:37dc:255a with SMTP id 00721157ae682-7ae1f2a0d56ms7b3; Thu, 9 Apr 2026 23:55:50 -0700 (PDT) X-Received: by 2002:a05:690c:e0d7:b0:79a:d393:f8b1 with SMTP id 00721157ae682-7af7166ea0dmr16034507b3.26.1775804150148; Thu, 09 Apr 2026 23:55:50 -0700 (PDT) Date: Thu, 9 Apr 2026 23:55:49 -0700 (PDT) From: "'Sean Carlin' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <86c7e3cc-1cc6-4492-ac56-132550665d2en@googlegroups.com> In-Reply-To: References: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_64818_633544772.1775804149589" 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_64818_633544772.1775804149589 Content-Type: multipart/alternative; boundary="----=_Part_64819_1152328841.1775804149589" ------=_Part_64819_1152328841.1775804149589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Thanks Steven for engaging and specifically for reaching out to Murch to=20 review our edge cases and friction modals.=20 I am looking forward to his and others=E2=80=99 perspectives as we try to= =20 standardize an approach to coordination. In direct response to those discussions on edge cases and signer risk, I=20 have released v2.0.0 of Siging Room which introduces several architectural= =20 and UX hardening updates: 1. Expanded Friction Modals & Signer Guidance We have doubled down on "guided friction" modals. We added more explicit=20 warning modals throughout the application, specifically before downloading= =20 raw PSBTs, audit logs, or sharing keys. These modals don't just ask "Are=20 you sure?", they explain the specific privacy leaks (e.g. UTXO/balance=20 metadata) or security risks (plaintext keys) associated with the action,=20 ensuring the signer is making an informed decision. 2. Enhanced Audit Events (Transparency on Human Actions) To provide even more clarity during the signing ceremony, the client-side= =20 audit log now tracks sensitive human interactions that don't touch the=20 blockchain but impact the security of the room. This includes logging=20 exactly when (and by which participant) a decryption key, admin token, Room= =20 ID, or share link was copied to the clipboard. This provides a clear trail= =20 of who accessed or shared sensitive metadata during the session. 3. Official Release of the Web Component SDK (@signing-room/embed) A major goal of this BIP is interoperability. To that end, we have released= =20 a framework-agnostic Web Component. This allows any Bitcoin wallet or=20 platform to drop the Signing Room coordination engine into their own=20 application as a simple HTML tag (). The SDK uses an isolated iframe and Shadow DOM boundary to ensure the host= =20 application cannot snoop on the PSBT data, preserving the zero-knowledge=20 security model while making the Stateless Blind Relay coordination pattern= =20 easy to adopt across the ecosystem. I would like to get some technical feedback on this approach and the=20 current events that are accessible through the embeddable web component.=20 Specifically: Is the event payload (containing the final TX hex, TXID, and raw room=20 state) sufficient for host applications to handle settlement, or is it too= =20 much/too little? What other state transitions or audit events would the community like to=20 see exposed to the host environment? Release Notes (v2.0.0): https://github.com/scarlin90/signingroom/releases/tag/v2.0.0 NPM Package: https://www.npmjs.com/package/@signing-room/embed Interactive Sandbox & Documentation: https://signingroom.io/webcomponent-demo.html I=E2=80=99m looking forward to hearing more thoughts and any further feedba= ck from=20 the list on whether these expanded friction points and the web component=20 SDK architecture properly address the risks inherent in application-layer= =20 coordination. All the best, Sean Carlin On Monday, 6 April 2026 at 22:04:22 UTC+1 STEVEN SLATER wrote: > Subject: Feedback on Blind Relay & BTSL Integration =20 > > Hi Murch, =20 > > Thanks for engaging with the Blind Relay proposal and the Signing Room=20 > updates. I wanted to highlight a couple of areas where your perspective= =20 > would be especially valuable: =20 > > - OpSec Friction in v1.8.0: The release introduces explicit split-key=20 > sharing and secure-by-default QR codes. Do you see this balance of UX vs.= =20 > security as sufficient for real-world multisig ceremonies, or are there= =20 > edge cases where additional friction might be warranted? =20 > > - BTSL Validator Integration: The idea of a standalone @btsl/validator=20 > package could allow Signing Room clients to locally verify transaction=20 > invariants before signing. From your experience with PSBT workflows, do y= ou=20 > think this approach would meaningfully reduce signer risk, or does it=20 > introduce complexity that might discourage adoption? =20 > > - Blind Relay Model: Since the relay is stateless and ephemeral, it avoid= s=20 > metadata persistence. Do you think this adequately addresses privacy=20 > concerns compared to existing coordination servers, or are there attack= =20 > surfaces we should still consider? =20 > > I=E2=80=99d really appreciate your thoughts on whether these design choic= es align=20 > with the broader goals of minimizing trust and maximizing signer=20 > independence. =20 > > Best regards,=20 > Steven > > On Mon, 6 Apr 2026, 7:19=E2=80=AFpm 'Sean Carlin' via Bitcoin Development= Mailing=20 > List, wrote: > >> Hi everyone, >> >> Following up on the ongoing development of the Signing Room (and the=20 >> Blind 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 hum= an=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 in= to=20 >> Slack or a standard email). >> >> The Solution (v1.8.0): >> I have introduced strategic UI friction to actively train users to adopt= =20 >> a "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=20 >> video-call coordination now default to "Link Only". The UI actively=20 >> re-blurs the canvas if the user toggles to include the key, preventing= =20 >> accidental 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=20 >> 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= =20 >> 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,=20 >>> I=E2=80=99ve been looking through your BTSL playground source code. To = make this=20 >>> work seamlessly with the Blind Relay reference implementation (Signing= =20 >>> Room), it would be great if the BTSL parser and validator were availabl= e 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 a= nd=20 >>> minimal dependencies), I could potentially integrate it directly into t= he=20 >>> Signing Room client. This would allow 'Signing Room' to automatically= =20 >>> detect an attached schema, run the ASSERT logic locally, and provide th= e=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= =20 >>> a 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 transactio= n invariants=20 >>>> before signing, regardless of how the PSBT was relayed =E2=80=94 is wh= at 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=A9cr= it : >>>> >>>>> 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 = PSBTs=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-sid= e 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 = RAM=20 >>>>> with a strict 24-hour TTL and self-destructs upon completion, providi= ng=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/mai= n/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 improvem= ents. >>>>> >>>>> Best regards, >>>>> Sean Carlin >>>> >>>> --=20 >> > You received this message because you are subscribed to the Google Groups= =20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9fac-cb5= de96208ecn%40googlegroups.com=20 >> >> . >> > --=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/= 86c7e3cc-1cc6-4492-ac56-132550665d2en%40googlegroups.com. ------=_Part_64819_1152328841.1775804149589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Thanks Steven for engaging and specifically fo= r reaching out to Murch to review our edge cases and friction modals.=C2=A0=
I am looking forward to his and others=E2=80=99 perspectives as = we try to standardize an approach to coordination.

In direct res= ponse to those discussions on edge cases and signer risk, I have released v= 2.0.0 of Siging Room which introduces several architectural and UX hardenin= g updates:

1. Expanded Friction Modals & Signer Guidance
We have doubled down on "guided friction" modals. We added more explicit = warning modals throughout the application, specifically before downloading = raw PSBTs, audit logs, or sharing keys. These modals don't just ask "Are yo= u sure?", they explain the specific privacy leaks (e.g. UTXO/balance metada= ta) or security risks (plaintext keys) associated with the action, ensuring= the signer is making an informed decision.

2. Enhanced Audit Ev= ents (Transparency on Human Actions)
To provide even more clarity duri= ng the signing ceremony, the client-side audit log now tracks sensitive hum= an interactions that don't touch the blockchain but impact the security of = the room. This includes logging exactly when (and by which participant) a d= ecryption key, admin token, Room ID, or share link was copied to the clipbo= ard. This provides a clear trail of who accessed or shared sensitive metada= ta during the session.

3. Official Release of the Web Component = SDK (@signing-room/embed)
A major goal of this BIP is interoperability= . To that end, we have released a framework-agnostic Web Component. This al= lows any Bitcoin wallet or platform to drop the Signing Room coordination e= ngine into their own application as a simple HTML tag (<signing-room>= ).

The SDK uses an isolated iframe and Shadow DOM boundary to en= sure the host application cannot snoop on the PSBT data, preserving the zer= o-knowledge security model while making the Stateless Blind Relay coordinat= ion pattern easy to adopt across the ecosystem.

I would like to = get some technical feedback on this approach and the current events that ar= e accessible through the embeddable web component.=C2=A0
Specific= ally:

Is the event payload (containing the final TX hex, TXID, a= nd raw room state) sufficient for host applications to handle settlement, o= r is it too much/too little?

What other state transitions or aud= it events would the community like to see exposed to the host environment?<= br />
Release Notes (v2.0.0):
https://github.com/scarlin90/signin= groom/releases/tag/v2.0.0

NPM Package:
https://www.npmjs.co= m/package/@signing-room/embed

Interactive Sandbox & Document= ation:
https://signingroom.io/webcomponent-demo.html

I=E2= =80=99m looking forward to hearing more thoughts and any further feedback f= rom the list on whether these expanded friction points and the web componen= t SDK architecture properly address the risks inherent in application-layer= coordination.

All the best,
Sean Carlin

<= div class=3D"gmail_quote">
On Monday,= 6 April 2026 at 22:04:22 UTC+1 STEVEN SLATER wrote:
Subject: Feedback= on Blind Relay & BTSL Integration=C2=A0=C2=A0

Hi Murch,=C2=A0=C2=A0

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

- OpSec Friction in v1.8.0: The release intro= duces 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 cere= monies, or are there edge cases where additional friction might be warrante= d?=C2=A0=C2=A0

- BTSL Va= lidator 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 appro= ach would meaningfully reduce signer risk, or does it introduce complexity = that might discourage adoption?=C2=A0=C2=A0

- Blind Relay Model: Since the relay is stateless and e= phemeral, it avoids metadata persistence. Do you think this adequately addr= esses privacy concerns compared to existing coordination servers, or are th= ere attack surfaces we should still consider?=C2=A0=C2=A0

I=E2=80=99d really appreciate your though= ts on whether these design choices align with the broader goals of minimizi= ng trust and maximizing signer independence.=C2=A0=C2=A0

Best regards,=C2=A0
Steven

On Mon, 6 Apr 2026, 7:19=E2= =80=AFpm 'Sean Carlin' via Bitcoin Development Mailing List, <bitco...@googlegroups.com> = wrote:
Hi everyone,

Following up on the ongoing development of the Sig= ning 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 arc= hitecture is compromised if the Coordinator inadvertently shares the room U= RL and the decryption key (the #key fragment) over the same insecure channe= l (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 t= rain users to adopt a "Split-Key" transport model, encouraging th= em to send the payload and the key via separate, out-of-band channels.
<= br>Key updates in this release include:
Explicit Split-Key Sharing: The = standard 1-click "Share" button has been replaced. Coordinators m= ust now explicitly choose between "Maximum Security" (copies the = base URL without the decryption fragment) and "Standard" (the ful= l combined link) via an interactive modal.

Secure-by-Default QR Code= s: 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 t= oggles to include the key, preventing accidental shoulder-surfing.

P= rivilege Friction: Added explicit, color-coded warning modals when a Coordi= nator attempts to copy the Room Decryption Key or the Backup Admin Token, e= xplaining the specific blast radius of each asset.

The goal is to ma= ke the secure path the easiest path, and force an active, conscious downgra= de for convenience.

Full release notes and UI screenshots can be fou= nd here:
https://github.com/scarlin9= 0/signingroom/releases/tag/v1.8.0

As always, I welcome any feedb= ack on the UX/OpSec balance from those of you who regularly coordinate mult= isig ceremonies.

Best regards,

Sean Carlin

On Thursday, 26 Mar= ch 2026 at 18:07:42 UTC Sean Carlin wrote:
Hi Thomas,=C2=A0
I=E2=80=99ve been looking through= your BTSL playground source code. To make this work seamlessly with the Bl= ind Relay reference implementation (Signing Room), it would be great if the= BTSL parser and validator were available as a standalone, versioned NPM pa= ckage.

If we had an @btsl/validator package that was environment-agn= ostic (no internal fetch calls to Blockstream, just pure PSBT/Schema valida= tion and minimal dependencies), I could potentially integrate it directly i= nto the Signing Room client. This would allow 'Signing Room' to aut= omatically detect an attached schema, run the ASSERT logic locally, and pro= vide the user with a 'Verified by BTSL' green-check before they sig= n.

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

=C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2= =A0"type": "STATE_SYNC",=C2=A0
=C2=A0 =C2=A0 = =C2=A0"encryptedPsbt": "base64_encrypted_psbt",=C2=A0
=C2=A0 =C2=A0 =C2=A0"encryptedValidationSchema": "b= ase64_encrypted_btsl_string",=C2=A0 // Optional=C2=A0
=C2=A0= =C2=A0 =C2=A0"schemaType": "BTSL_V1", // Optional: Ide= ntifies the language Or Version ...=C2=A0
}=C2=A0=C2=A0
<= br>
Let me know your thoughts,

All the b= est
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 validate transaction invariants before signing, r= egardless of how the PSBT was relayed =E2=80=94 is what I've been explo= ring with BTSL: https://delvingbitcoin.org/t/btsl-bitcoin-= transaction-schema-language-a-declarative-validation-schema-for-psbt-workfl= ows/2338

Best regards,=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,
<= br>I'd like to propose a new BIP for real-time, trust-minimized coordin= ation of multi-signature PSBTs.

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

The Proposa= l: Blind Relay
This BIP introduces a "Blind Relay" - an epheme= ral, stateless, zero-knowledge WebSocket relay. All payloads are encrypted = client-side with AES-GCM-256, with decryption keys held exclusively in clie= nt-side URL fragments (never sent to the server). The relay operates entire= ly in RAM with a strict 24-hour TTL and self-destructs upon completion, pro= viding real-time coordination without persistent metadata or disk storage.<= br>
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/s= carlin90/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 speci= fication, security model, edge cases, and any suggested improvements.
Best regards,
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 bitcoindev+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9f= ac-cb5de96208ecn%40googlegroups.com.

--
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/86c7e3cc-1cc6-4492-ac56-132550665d2en%40googlegroups.com.
------=_Part_64819_1152328841.1775804149589-- ------=_Part_64818_633544772.1775804149589--