From: "'Sean Carlin' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
Date: Fri, 17 Apr 2026 09:11:25 -0700 (PDT) [thread overview]
Message-ID: <740f74db-c7eb-40df-948a-84fc4c821b38n@googlegroups.com> (raw)
In-Reply-To: <CAPR5oBPQQGvanjTFm_RsLiVTtrympkuXkFY3eN-wHeqjnggcbw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 8723 bytes --]
Hi Craig,
Thank you for the detailed feedback and for taking the time to review the
proposal carefully.
Your points, especially around privacy trade-offs and protocol layering are
spot on and very helpful as I iterate.
I have updated the BIP draft’s Session Identification section to accurately
reflect the current relay architecture and 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 sustainable path for interwallet
coordination that avoids creating long-term metadata risks.
2. You're right to call out the inaccurate phrasing in 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 as a privacy proxy for
peers, it remains a "trusted" point for metadata.
I share your preference for strong privacy. However, for multisig signing
(especially with 3+ participants or institutional setups), I view real-time
synchronization as a security feature. Latency creates windows for state
desynchronization, which increases the risk of errors or aborted
ceremonies. Furthermore, I see this model as more scalable than
long-polling for high-throughput environments required by institutional
custodians and automated coordination (AI/Bot trading), where
high-frequency multisig state agreement is a mandate.
To reconcile these views, I’m exploring a dual-track transport for the next
revision:
High-Privacy Track - Utilizing WebTransport over HTTP/3 (QUIC) combined
with MASQUE proxies. This setup allows the relay to act as an oblivious
proxy, hiding the client's IP from the coordination server while preserving
sub 100ms bidirectional streams for real-time state sync. This is now a
Baseline 2026 standard across modern browsers.
Standard Track (The Fallback) - Standard WebSockets, fronted by OHTTP for
the initial room discovery/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 approached 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 extended 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 (which is wiped from memory post-session) is far less
risky than the current practice of emailing full PSBTs, which often linger
on third-party servers indefinitely in my opinion.
While deeper server side wallet integration is the ideal UX, standardized
solutions haven't widely materialized yet. SigningRoom exists because this
friction is painful for users today. My traffic logs show consistent daily
adoption because it enables immediate interoperability between different
wallets (e.g., Sparrow to a hardware device) without server-side changes.
We are solving for the current reality while keeping the door open for
future native integrations.
Path Forward
The hybrid transport approach (OHTTP - room creation + WebTransport/MASQUE
for coordination) seems to thread the needle between protocol-level privacy
and the need for reliable, low-latency agreement.
I am planning to investigate a functional prototype of this stack next.
I’d love your thoughts on whether this direction addresses the relay
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 near
> necessity for any interwallet communication scheme.
>
> 2. Payjoin v2 makes the specific tradeoff of privacy over performance,
> favouring OHTTP and HTTP polling to protect user IPs. Your approach using
> websockets does not protect from the relay learning the IP addresses of the
> participants. The draft says "This ID allows participants to distinguish
> between different connections/sessions in the room and audit log without
> the relay or other peers learning the user's IP address or permanent
> identity" - but in fact the relay does learn the user's IP address. On this
> point I lean towards privacy over performance, as I don't think real time
> response is needed here. Apart from protecting users, a privacy
> preserving approach also lowers the risk of running a relay.
>
> 3. The proposal focuses only on multisig PSBT sharing, but there are other
> interwallet communication use cases such as multisig setup and payment
> confirmations. In my opinion, addressing the challenge of interwallet
> messaging should be done as a series of BIPs to specify the transport
> separately from specific message protocols for various use cases. This
> allows for future extensibility by making each layer independently
> reviewable 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 out-of-band sharing for the room setup - which
> is essentially equivalent in complexity. In the case of multisig wallets,
> there is already private shared state in the multisig wallet setup, and in
> most cases the wallet client is already connected to a server of some kind.
> It seems to me that as it stands, this proposal will be replaced by one in
> future that takes advantage of these facts simply by virtue of being a more
> convenient user experience.
>
> Craig
>
> On Wed, Mar 25, 2026 at 2:21 PM 'Sean Carlin' via Bitcoin Development
> Mailing List <bitco...@googlegroups.com> wrote:
>
>> 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+...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc432a06n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/3f1a1491-06e1-4453-9538-fa66bc432a06n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/740f74db-c7eb-40df-948a-84fc4c821b38n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11745 bytes --]
prev parent reply other threads:[~2026-04-17 17:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 12:00 '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
2026-04-06 20:12 ` STEVEN SLATER
2026-04-10 6:55 ` 'Sean Carlin' via Bitcoin Development Mailing List
2026-04-14 6:27 ` [bitcoindev] " Craig Raw
2026-04-17 16:11 ` 'Sean Carlin' via Bitcoin Development Mailing List [this message]
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=740f74db-c7eb-40df-948a-84fc4c821b38n@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