From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 17 Apr 2026 10:56:43 -0700 Received: from mail-ot1-f56.google.com ([209.85.210.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDnQo-00016W-CL for bitcoindev@gnusha.org; Fri, 17 Apr 2026 10:56:43 -0700 Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-7dbd50dee52sf2192678a34.2 for ; Fri, 17 Apr 2026 10:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776448596; x=1777053396; 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=SETmHpnYOPdeHFHkxWj9Er6qrA1kPgDYhJA+QOYUlAg=; b=pjCoOUdnv3Oi6xa9r6/3VNgYs49fM6K6WJTwixQr1LqNYwTcgqa24MDrA2gDuhoUki NKpfV2zeYszpGJeVq8StP82wm80DJ53ewByP5ArZh/+XQn7fnGB7hdvCZ6M69fQsr9D+ UjG/zO90ZuS3uTFkrtXTRkv1KZzsfELy25meGuH+fAT+dH2L4feRhC91nt7xqxAhaHbp iPWY9HqJStIjLf4SAcjfRiGv0L9hpaz2XVemtS0EKHvE+UdqKmp9+j0GMDkUcuRg754f fg/vBkFxzRSGJ42x9OlcZ9zlNrmxCzsWr/CgGxmIAV1CDHyigGTEGcBoJMOf33asLmVT 89bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776448596; x=1777053396; 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=SETmHpnYOPdeHFHkxWj9Er6qrA1kPgDYhJA+QOYUlAg=; b=PXZXOy4d9RNqaN8LN/9sKs6hvwgThFL3+vLv56hmDYI3mgJfc8b0nfpGW3R7Xt5RC9 jNR75FNmIzE81odBcreknmQ99GsPUwUAXrMg8J4Z9+bEJsz1uqbciAAxK4QjbMsPhx6B /Gza9wOsv75VLf9g8YfCOb5m6ncmwE1x4kDQ+N0Lxr54cZmPEuEDOn7Voj3BCUM3Ycnh bWE/WtfE469sMrel2Tc+SZbJg6jLNd5KExEAjA1I1Sqk7lD2JaE6hroStn7oSMNESQJh BJg7I3/l+VAtqNYYdq9wOBOXMSO1hdWS7+RYMrd5uJIvFWpVkubRbmJSbw6rF29IXS2f etsQ== X-Forwarded-Encrypted: i=1; AFNElJ+cEcF4BKQ3KVyiicOeb1O4dRQy7AwWEnV9uwHn0OAZja1kvLbjS6rf+qJwn+y3mknCNwPNkAAud1Cx@gnusha.org X-Gm-Message-State: AOJu0YxS1Gy1UWNotdnaP34lYM0ON3pC2Nt8ky/2AfOQVETNZiexu9hL XTdnjTU1lSWAxQ8twV4VvrlWFLymyyI3HL7TVHVetpFS8aTkJQgEQDV4 X-Received: by 2002:a05:6820:1787:b0:68e:314a:aee2 with SMTP id 006d021491bc7-69462e6a011mr2239478eaf.22.1776448596094; Fri, 17 Apr 2026 10:56:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKXJ3GVPu05Zde9/juhu+3UrZoognE2KiAq7yxInUWaVg==" Received: by 2002:a05:6820:168a:b0:681:a657:932f with SMTP id 006d021491bc7-6943c0f2fe2ls1222504eaf.1.-pod-prod-09-us; Fri, 17 Apr 2026 10:56:31 -0700 (PDT) X-Received: by 2002:a05:6808:1b12:b0:46a:bbae:d47a with SMTP id 5614622812f47-4799c9bcef7mr2126700b6e.34.1776448591213; Fri, 17 Apr 2026 10:56:31 -0700 (PDT) Received: by 2002:a05:690c:a4cd:10b0:7b3:9cd7:9641 with SMTP id 00721157ae682-7b9ed6ade56ms7b3; Fri, 17 Apr 2026 09:11:27 -0700 (PDT) X-Received: by 2002:a05:690c:e04e:b0:7b8:8d3c:17b7 with SMTP id 00721157ae682-7b9ecfd11cemr28429557b3.42.1776442286375; Fri, 17 Apr 2026 09:11:26 -0700 (PDT) Date: Fri, 17 Apr 2026 09:11:25 -0700 (PDT) From: "'Sean Carlin' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <740f74db-c7eb-40df-948a-84fc4c821b38n@googlegroups.com> In-Reply-To: References: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com> Subject: Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_420388_2130353408.1776442285798" 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_420388_2130353408.1776442285798 Content-Type: multipart/alternative; boundary="----=_Part_420389_1905861813.1776442285798" ------=_Part_420389_1905861813.1776442285798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig, Thank you for the detailed feedback and for taking the time to review the= =20 proposal carefully.=20 Your points, especially around privacy trade-offs and protocol layering are= =20 spot on and very helpful as I iterate. I have updated the BIP draft=E2=80=99s Session Identification section to ac= curately=20 reflect the current relay architecture and clarify the IP visibility=20 boundaries. Addressing your points individually: 1. Glad we're aligned here. Treating the relay as a volatile "mist" rather= =20 than a permanent store feels like the only sustainable path for interwallet= =20 coordination that avoids creating long-term metadata risks. 2. You're right to call out the inaccurate phrasing in the draft regarding= =20 the relay's visibility. In a standard WebSocket setup, the relay does learn= =20 participant IPs, even if peers are blinded from one another. I have updated= =20 the BIP text to clarify that while the relay acts as a privacy proxy for=20 peers, it remains a "trusted" point for metadata. I share your preference for strong privacy. However, for multisig signing= =20 (especially with 3+ participants or institutional setups), I view real-time= =20 synchronization as a security feature. Latency creates windows for state=20 desynchronization, which increases the risk of errors or aborted=20 ceremonies. Furthermore, I see this model as more scalable than=20 long-polling for high-throughput environments required by institutional=20 custodians and automated coordination (AI/Bot trading), where=20 high-frequency multisig state agreement is a mandate. To reconcile these views, I=E2=80=99m exploring a dual-track transport for = the next=20 revision: High-Privacy Track - Utilizing WebTransport over HTTP/3 (QUIC) combined=20 with MASQUE proxies. This setup allows the relay to act as an oblivious=20 proxy, hiding the client's IP from the coordination server while preserving= =20 sub 100ms bidirectional streams for real-time state sync. This is now a=20 Baseline 2026 standard across modern browsers. Standard Track (The Fallback) - Standard WebSockets, fronted by OHTTP for= =20 the initial room discovery/handshake phase. This prevents the relay from=20 easily linking the room creator to the joiners, offering a "moderate=20 privacy" fallback for legacy environments. 3. Completely agree, this probably should be approached as a layered set of= =20 BIPs. A clean separation between a Generic Blind Relay Transport BIP and a= =20 specific PSBT Coordination Application BIP makes the most sense. This=20 allows each layer to be independently reviewed and extended for other use= =20 cases as you mentioned. 4. Regarding the out-of-band step: the key difference is that sharing a=20 short-lived Room ID (which is wiped from memory post-session) is far less= =20 risky than the current practice of emailing full PSBTs, which often linger= =20 on third-party servers indefinitely in my opinion. While deeper server side wallet integration is the ideal UX, standardized= =20 solutions haven't widely materialized yet. SigningRoom exists because this= =20 friction is painful for users today. My traffic logs show consistent daily= =20 adoption because it enables immediate interoperability between different=20 wallets (e.g., Sparrow to a hardware device) without server-side changes.= =20 We are solving for the current reality while keeping the door open for=20 future native integrations. Path Forward The hybrid transport approach (OHTTP - room creation + WebTransport/MASQUE= =20 for coordination) seems to thread the needle between protocol-level privacy= =20 and the need for reliable, low-latency agreement.=20 I am planning to investigate a functional prototype of this stack next. I=E2=80=99d love your thoughts on whether this direction addresses the rela= y=20 privacy risks sufficiently for the BIP to move forward. Best regards, Sean Carlin On Tuesday, 14 April 2026 at 10:18:23 UTC+1 Craig Raw wrote: > Hi Sean, > > My feedback as follows: > > 1. I like the ephemeral approach to handling data, and view this as a nea= r=20 > necessity for any interwallet communication scheme. > > 2. Payjoin v2 makes the specific tradeoff of privacy over performance,=20 > favouring OHTTP and HTTP polling to protect user IPs. Your approach using= =20 > websockets does not protect from the relay learning the IP addresses of t= he=20 > participants. The draft says "This ID allows participants to distinguish= =20 > between different connections/sessions in the room and audit log without= =20 > the relay or other peers learning the user's IP address or permanent=20 > identity" - but in fact the relay does learn the user's IP address. On th= is=20 > point I lean towards privacy over performance, as I don't think real time= =20 > response is needed here. Apart from protecting users, a privacy=20 > preserving approach also lowers the risk of running a relay. > > 3. The proposal focuses only on multisig PSBT sharing, but there are othe= r=20 > interwallet communication use cases such as multisig setup and payment=20 > confirmations. In my opinion, addressing the challenge of interwallet=20 > messaging should be done as a series of BIPs to specify the transport=20 > separately from specific message protocols for various use cases. This=20 > allows for future extensibility by making each layer independently=20 > reviewable and upgradeable. > > 4. This proposal still relies on out-of-band sharing. The BIP draft=20 > specifically notes that out-of-band PSBT sharing is "heavy operational=20 > friction" but still requires out-of-band sharing for the room setup - whi= ch=20 > is essentially equivalent in complexity. In the case of multisig wallets,= =20 > there is already private shared state in the multisig wallet setup, and i= n=20 > most cases the wallet client is already connected to a server of some kin= d.=20 > It seems to me that as it stands, this proposal will be replaced by one i= n=20 > future that takes advantage of these facts simply by virtue of being a mo= re=20 > convenient user experience. > > Craig > > On Wed, Mar 25, 2026 at 2:21=E2=80=AFPM 'Sean Carlin' via Bitcoin Develop= ment=20 > Mailing List wrote: > >> Hi everyone, >> >> I'd like to propose a new BIP for real-time, trust-minimized coordinatio= n=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 PSB= Ts=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 w= ith=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/b= ip-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 improvement= s. >> >> Best regards, >> Sean Carlin=20 >> >> --=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/3f1a1491-06e1-4453-9538-fa6= 6bc432a06n%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/= 740f74db-c7eb-40df-948a-84fc4c821b38n%40googlegroups.com. ------=_Part_420389_1905861813.1776442285798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig,

Thank you for the detailed feedback and for taking the= time to review the proposal carefully.=C2=A0
Your points, especially a= round privacy trade-offs and protocol layering are spot on and very helpful= as I iterate.

I have updated the BIP draft=E2=80=99s Session Id= entification section to accurately reflect the current relay architecture a= nd clarify the IP visibility boundaries.

Addressing your points = individually:

1. Glad we're aligned here. Treating the relay as = a volatile "mist" rather than a permanent store feels like the only sustain= able path for interwallet coordination that avoids creating long-term metad= ata risks.

2. You're right to call out the inaccurate phrasing i= n the draft regarding the relay's visibility. In a standard WebSocket setup= , the relay does learn participant IPs, even if peers are blinded from one = another. I have updated the BIP text to clarify that while the relay acts a= s a privacy proxy for peers, it remains a "trusted" point for metadata.

I share your preference for strong privacy. However, for multisig s= igning (especially with 3+ participants or institutional setups), I view re= al-time synchronization as a security feature. Latency creates windows for = state desynchronization, which increases the risk of errors or aborted cere= monies. Furthermore, I see this model as more scalable than long-polling fo= r high-throughput environments required by institutional custodians and aut= omated coordination (AI/Bot trading), where high-frequency multisig state a= greement is a mandate.

To reconcile these views,= I=E2=80=99m exploring a dual-track transport for the next revision:
<= br />High-Privacy Track - Utilizing WebTransport over HTTP/3 (QUIC) combine= d with MASQUE proxies. This setup allows the relay to act as an oblivious p= roxy, hiding the client's IP from the coordination server while preserving = sub 100ms bidirectional streams for real-time state sync. This is now a Bas= eline 2026 standard across modern browsers.

Standard Track (The = Fallback) - Standard WebSockets, fronted by OHTTP for the initial room disc= overy/handshake phase. This prevents the relay from easily linking the room= creator to the joiners, offering a "moderate privacy" fallback for legacy = environments.

3. Completely agree, this probably should be appro= ached as a layered set of BIPs. A clean separation between a Generic Blind = Relay Transport BIP and a specific PSBT Coordination Application BIP makes = the most sense. This allows each layer to be independently reviewed and ext= ended for other use cases as you mentioned.

4. Regarding the out= -of-band step: the key difference is that sharing a short-lived Room ID (wh= ich is wiped from memory post-session) is far less risky than the current p= ractice of emailing full PSBTs, which often linger on third-party servers i= ndefinitely in my opinion.

While deeper server side wallet integ= ration is the ideal UX, standardized solutions haven't widely materialized = yet. SigningRoom exists because this friction is painful for users today. M= y traffic logs show consistent daily adoption because it enables immediate = interoperability between different wallets (e.g., Sparrow to a hardware dev= ice) without server-side changes. We are solving for the current reality wh= ile keeping the door open for future native integrations.

Path F= orward
The hybrid transport approach (OHTTP - room creation + WebTrans= port/MASQUE for coordination) seems to thread the needle between protocol-l= evel privacy and the need for reliable, low-latency agreement.=C2=A0
<= div>I am planning to investigate a functional prototype of this stack next.=

I=E2=80=99d love your thoughts on whether this direction addres= ses the relay privacy risks sufficiently for the BIP to move forward.
=
Best regards,
Sean Carlin

On Tuesday, 14 April 2026 at 1= 0:18:23 UTC+1 Craig Raw wrote:
Hi Sean,

My= feedback as follows:

1. I like the ephemeral=C2= =A0approach to handling data, and view this as a near necessity for any int= erwallet communication scheme.

2. Payjoin v2 makes= =C2=A0the specific tradeoff of privacy=C2=A0over performance, favouring OHT= TP and HTTP polling to=C2=A0protect user IPs. Your approach using websocket= s does not protect from the relay learning the IP addresses of the particip= ants. The draft says=C2=A0"This ID allows participants to distinguish = between different connections/sessions in the room and audit log without th= e relay or other peers learning the user's IP address or permanent iden= tity" - but in fact the relay does learn the user's IP address. On= this point I lean towards privacy=C2=A0over performance, as I don't th= ink real time response is needed here. Apart from protecting users, a priva= cy preserving=C2=A0approach also lowers the risk of running a relay.
<= div>
3. The proposal focuses only on multisig PSBT sharing, b= ut there are other interwallet communication use cases such as multisig set= up and payment confirmations. In my opinion, addressing the challenge of in= terwallet messaging should be done as a series of BIPs to specify the trans= port separately from specific message protocols for various use cases. This= allows for future extensibility by making each layer independently reviewa= ble and upgradeable.

4. This proposal still relies= on out-of-band sharing. The BIP draft specifically notes that out-of-band = PSBT sharing is "heavy operational friction" but still requires o= ut-of-band sharing for the room setup - which is essentially equivalent in = complexity.=C2=A0In the case of multisig wallets, there is already private = shared state in the multisig wallet setup, and in most cases the wallet cli= ent is already connected to a server of some kind. It seems to me that as i= t stands, this proposal will be replaced by one in future that takes advant= age of these facts simply by virtue of being a more convenient user experie= nce.

Craig

On Wed, Mar 25, 2026 at 2:21=E2=80=AFPM 'Sean Carlin' via Bitc= oin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi everyone,
=
I'd like to propose a new BIP for real-time, trust-minimized coordi= nation of multi-signature PSBTs.

The Problem
Coordinating N-of-M = Bitcoin transactions currently forces users into a binary choice:
- Manu= al out-of-band transfers (USB drives, secure messengers) that preserve priv= acy but introduce high friction and error risk, or
- Stateful coordinati= on servers that offer good UX but act as privacy honeypots, logging metadat= a, signer relationships, and often storing PSBTs on disk.

The Propos= al: Blind Relay
This BIP introduces a "Blind Relay" - an ephem= eral, stateless, zero-knowledge WebSocket relay. All payloads are encrypted= client-side with AES-GCM-256, with decryption keys held exclusively in cli= ent-side URL fragments (never sent to the server). The relay operates entir= ely in RAM with a strict 24-hour TTL and self-destructs upon completion, pr= oviding 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.

Link= s
- BIP Draft: https://github.com/scarlin90/bip-stateless-psbt-coordinat= ion/blob/main/bip-draft.md
- Source Code: https://github.com/scarlin90/signingroom<= /a>
- Live Client: https://signingroom.io- Related Research Paper: http= s://arxiv.org/abs/2601.17875

I look forward to your technical fe= edback - especially on the specification, security model, edge cases, and a= ny 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+...@googlegro= ups.com.
To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc43= 2a06n%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/740f74db-c7eb-40df-948a-84fc4c821b38n%40googlegroups.com.
------=_Part_420389_1905861813.1776442285798-- ------=_Part_420388_2130353408.1776442285798--