From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 26 Mar 2026 07:21:48 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w5lal-0005Za-No for bitcoindev@gnusha.org; Thu, 26 Mar 2026 07:21:48 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-67de3f8988csf2791001eaf.1 for ; Thu, 26 Mar 2026 07:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774534901; x=1775139701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=m9TL0cMwkWbdhs4T0xf8jU7ArSHMrPs7fShsyJfDoHk=; b=Ozm4yGXQMdLrSXMEnhSg5b8Jy7KIeyLYUtZa5AMrJHpjkMA3QfXZs7S6N7x2t4ZHot XpFe1UEIxZeyZyosUYKOHN0dLQipCBRLTp0G+BPBnBm63XH7jTcmwaOIfcLy+Fw+Zx7N Nxizf7qwR6poh1TdXtb00pUz1SBHiHpWuzFlffLlIWvS/t8Bc2Ky/8WaCCg4zi8au+9I ZrgBgE9l/Powxj1RNLyGtUD7Ee+2XFZZNh5GiyOBVEZh4VktVjTce4z1jmyucRxPUJvF KDyq5fCXBKE0GGLc3dXPalNWjEU8MZ1FCTe6+qdWGGyVMiSvVPuGGr7LY4XvBFxA3dOg eXdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774534901; x=1775139701; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=m9TL0cMwkWbdhs4T0xf8jU7ArSHMrPs7fShsyJfDoHk=; b=WanDShSZUt/hTv0x1Ay8cjbJAw58qbr5wSRbxlczZ9NDr8WLMZ1VhryOpme58Sds9z H/ZPWzAcM2h4rLNMw8igrK2y/x54C2ncquo5z+bVGTGvSjUNH+j3O9UEx7Hm6Xp4k+Cy 9CCnAVqs4ZnEMsFLRqqhEZ9GvX24+XoJM0JB8MkVHcDYDud9tPeC4U4xKBs3e2Zt/u8n QB1TY8y1ATmVaXIrn11U+8vhyPxOrFKVfFQiZtpd3fLIDy1d3frvrBhC1ZSZKr/dRml2 NtYT8gYunTv6xXxKVvo7EC4gKI/+GQAYTkGc/Wd9BFzBPmrN7f6DAdu124PpPVBssa0r Wyxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774534901; x=1775139701; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=m9TL0cMwkWbdhs4T0xf8jU7ArSHMrPs7fShsyJfDoHk=; b=dvx3cxI47i+M9KYiK296T0RrBX1w47qX5/gQtwURw5J5Bt6e+qNN/fgCZYMLy9J6zt SRZ04dfPQmHfRzEcn8qu4zr3eg0JST4cN7X9Ov6G9QxfcKpr27QZ6XTNdnBbcNHtUaGZ yRtxSYMeb0jGfMKDG2AZLUsWyjVeVMo9/rvpBWXa7mWRGWvuMjeOUGV73ytcAQo2KFh5 kzBk3qLHk6HAtQsNqiHpeU6AUcgCOMoexkQAW89KCINiiPdi06hg1dWOMjR9qqGLStvF 4rH+D01glD9NTeibEZkTZOJGthNR736HSv+eTr8zusQaZKzwlWZj+rfwwiA+0GGwF/Ir Sy/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUs6J4tSwhzEf5PYbKwX3bKyUvBbvO23QEHc9cXm2COa9oIe/tntrp60TPF7p4eINL7vXhOClCXW8rs@gnusha.org X-Gm-Message-State: AOJu0Yylheh1oE7ytEmr7scUS5kxAZpn7LtpG8z11jC9L96Ham3Pi+AF xLIm5//DEmmM9RpFCWvp5M7sp8rExDdIhiHbOiLHybVVKjlGktCmFNzC X-Received: by 2002:a05:6820:1345:b0:67c:2fe3:7edf with SMTP id 006d021491bc7-67dff55f859mr4017584eaf.52.1774534901322; Thu, 26 Mar 2026 07:21:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIl4IRc+Kbkns9pPGmtGOIbBzjETaEre8/FfmLZ+05SVg==" Received: by 2002:a05:6820:2293:b0:67b:b390:cf44 with SMTP id 006d021491bc7-67e0ce4eb84ls541497eaf.0.-pod-prod-06-us; Thu, 26 Mar 2026 07:21:36 -0700 (PDT) X-Received: by 2002:a05:6808:220b:b0:467:cda:f15d with SMTP id 5614622812f47-46a5c66bb5bmr3325469b6e.26.1774534896566; Thu, 26 Mar 2026 07:21:36 -0700 (PDT) Received: by 2002:a05:690c:e3d2:b0:79a:8019:36f5 with SMTP id 00721157ae682-79ad1799d02ms7b3; Thu, 26 Mar 2026 07:02:46 -0700 (PDT) X-Received: by 2002:a05:690c:89:b0:79a:3a79:a488 with SMTP id 00721157ae682-79acf6693bbmr75417537b3.45.1774533766206; Thu, 26 Mar 2026 07:02:46 -0700 (PDT) Date: Thu, 26 Mar 2026 07:02:45 -0700 (PDT) From: Thomas Suau To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com> 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_81608_1048123388.1774533765586" X-Original-Sender: tomeclair@gmail.com 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.5 (/) ------=_Part_81608_1048123388.1774533765586 Content-Type: multipart/alternative; boundary="----=_Part_81609_1679974253.1774533765586" ------=_Part_81609_1679974253.1774533765586 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,=20 The transport layer problem is well addressed here. The complementary piece= =20 =E2=80=94 ensuring signers can independently validate transaction invariant= s before=20 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-dec= larative-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 coordination= =20 > 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 PSBT= s=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 wi= th=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, 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/bi= p-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 improvements= . > > 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/= cb192fdb-e26e-463f-97be-fbb627ce84adn%40googlegroups.com. ------=_Part_81609_1679974253.1774533765586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,=C2=A0
The transport layer problem is well addressed here. The co= mplementary piece =E2=80=94 ensuring signers can independently validate tra= nsaction invariants before signing, regardless of how the PSBT was relayed = =E2=80=94 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,=C2=A0
Thom= as 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 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 messen= gers) that preserve privacy but introduce high friction and error risk, or<= br>- Stateful coordination servers that offer good UX but act as privacy ho= neypots, logging metadata, signer relationships, and often storing PSBTs on= disk.

The Proposal: Blind Relay
This BIP introduces a "Blin= d Relay" - an ephemeral, stateless, zero-knowledge WebSocket relay. Al= l 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-destr= ucts upon completion, providing real-time coordination without persistent m= etadata or disk storage.

A reference implementation has been running= in production for three months, successfully facilitating real multisig ce= remonies.

Links
- BIP Draft: https://github.com/scarlin90/bip-s= tateless-psbt-coordination/blob/main/bip-draft.md
- Source Code: https://github.com/s= carlin90/signingroom
- Live Client: https://sig= ningroom.io
- Related Research Paper: https://arxiv.org/abs/2601.17875

I look forward to yo= ur technical feedback - especially on the specification, security model, ed= ge cases, and any suggested improvements.

Best regards,
Sean Carl= in

--
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/cb192fdb-e26e-463f-97be-fbb627ce84adn%40googlegroups.com.
------=_Part_81609_1679974253.1774533765586-- ------=_Part_81608_1048123388.1774533765586--