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.

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.