From: Craig Raw <craigraw@gmail.com>
To: Sean Carlin <seancarlin90@googlemail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
Date: Tue, 14 Apr 2026 08:27:16 +0200 [thread overview]
Message-ID: <CAPR5oBPQQGvanjTFm_RsLiVTtrympkuXkFY3eN-wHeqjnggcbw@mail.gmail.com> (raw)
In-Reply-To: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 4668 bytes --]
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 <bitcoindev@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+unsubscribe@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/CAPR5oBPQQGvanjTFm_RsLiVTtrympkuXkFY3eN-wHeqjnggcbw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5986 bytes --]
prev parent reply other threads:[~2026-04-14 9:18 UTC|newest]
Thread overview: 9+ 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 ` Craig Raw [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=CAPR5oBPQQGvanjTFm_RsLiVTtrympkuXkFY3eN-wHeqjnggcbw@mail.gmail.com \
--to=craigraw@gmail.com \
--cc=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