* [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
@ 2026-03-25 12:00 'Sean Carlin' via Bitcoin Development Mailing List
2026-03-26 0:15 ` pyth
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-25 12:00 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 2262 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs '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-04-14 6:27 ` [bitcoindev] " Craig Raw
2 siblings, 1 reply; 9+ messages in thread
From: pyth @ 2026-03-26 0:15 UTC (permalink / raw)
To: Sean Carlin, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]
Hi Sean, this is interesting, but note that bitcoin core doesn't have
dependencies for AES-GCM-256, while it have dependencies for CHACHA20-
POLY1305.
Best,
Pyth
On Wed, 2026-03-25 at 05:00 -0700, 'Sean Carlin' via Bitcoin
Development Mailing List 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
> .
--
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/fede50f58f286763106ba143e7530990eb7d86c1.camel%40pythcoiner.dev.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 'Sean Carlin' via Bitcoin Development Mailing List
2026-03-26 0:15 ` pyth
@ 2026-03-26 14:02 ` Thomas Suau
2026-03-26 16:02 ` 'Sean Carlin' via Bitcoin Development Mailing List
2026-04-14 6:27 ` [bitcoindev] " Craig Raw
2 siblings, 1 reply; 9+ messages in thread
From: Thomas Suau @ 2026-03-26 14:02 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2493 bytes --]
Hello,
The transport layer problem is well addressed here. The complementary piece
— ensuring signers can independently validate transaction invariants before
signing, regardless of how the PSBT was relayed — 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,
Thomas Suau
Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit :
> 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/cb192fdb-e26e-463f-97be-fbb627ce84adn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4071 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
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
0 siblings, 1 reply; 9+ messages in thread
From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-26 16:02 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3758 bytes --]
Hi Thomas,
I’ve been looking through your BTSL playground source code. To make this
work seamlessly with the Blind Relay reference implementation (Signing
Room), it would be great if the BTSL parser and validator were available as
a standalone, versioned NPM package.
If we had an @btsl/validator package that was environment-agnostic (no
internal fetch calls to Blockstream, just pure PSBT/Schema validation and
minimal dependencies), I could potentially integrate it directly into the
Signing Room client. This would allow 'Signing Room' to automatically
detect an attached schema, run the ASSERT logic locally, and provide the
user with a 'Verified by BTSL' green-check before they sign.
The STATE_SYNC payload could be modified to something like this to pass a
schema and type:
{
"type": "STATE_SYNC",
"encryptedPsbt": "base64_encrypted_psbt",
"encryptedValidationSchema": "base64_encrypted_btsl_string", //
Optional
"schemaType": "BTSL_V1", // Optional: Identifies the language Or
Version ...
}
Let me know your thoughts,
All the best
Sean Carlin
On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote:
> Hello,
> The transport layer problem is well addressed here. The complementary
> piece — ensuring signers can independently validate transaction invariants
> before signing, regardless of how the PSBT was relayed — 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,
> Thomas Suau
>
> Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit :
>
>> 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/e501ab92-6911-4437-ac06-d7f547c2190dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6107 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
2026-03-26 0:15 ` pyth
@ 2026-03-26 16:19 ` 'Sean Carlin' via Bitcoin Development Mailing List
0 siblings, 0 replies; 9+ messages in thread
From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-03-26 16:19 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3971 bytes --]
Hi Pyth,
That is a fair point regarding Bitcoin Core's existing dependencies. I
chose AES-GCM-256 specifically because this BIP targets Application Layer
coordination, with a focus on cross-platform ubiquity (Web PWAs, Mobile,
and Desktop).
For these environments, AES-GCM is a core primitive of the Web Crypto API,
meaning it is implemented natively and audited by browser/OS vendors.
Standardizing on ChaCha20-Poly1305 would force web and mobile developers to
bundle external, unoptimized JavaScript cryptographic libraries. In the
context of a browser-based or mobile coordinator, I believe relying on
native, hardware-accelerated OS primitives provides a smaller and more
secure attack surface than importing third-party JS dependencies.
If the protocol were strictly node-to-node (Transport Layer), I would agree
on ChaCha20. But for client-to-relay coordination, the Web Crypto API
support makes AES-GCM the safer choice for the average user's device in my
opinion.
Happy to discuss further if you see a reason why supporting ChaCha20 is a
benefit other than ecosystem alignment.
I updated the BIPs rationale section with this earlier today.
All the best,
Sean Carlin
On Thursday, 26 March 2026 at 14:21:27 UTC pyth wrote:
> Hi Sean, this is interesting, but note that bitcoin core doesn't have
> dependencies for AES-GCM-256, while it have dependencies for CHACHA20-
> POLY1305.
>
> Best,
> Pyth
>
> On Wed, 2026-03-25 at 05:00 -0700, 'Sean Carlin' via Bitcoin
> Development Mailing List 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
> > .
>
--
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/b6af2c43-1bde-4f64-a2aa-42d948b9a1fen%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6399 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
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
0 siblings, 1 reply; 9+ messages in thread
From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-04-03 11:03 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5899 bytes --]
Hi everyone,
Following up on the ongoing development of the Signing Room (and the Blind
Relay coordination model), I've just released v1.8.0.
While previous updates focused heavily on the cryptographic and protocol
layers, this release hardens the Operational Security (OpSec) at the human
layer.
The Threat Model:
A zero-knowledge server architecture is compromised if the Coordinator
inadvertently shares the room URL and the decryption key (the #key
fragment) over the same insecure channel (e.g., pasting the full link into
Slack or a standard email).
The Solution (v1.8.0):
I have introduced strategic UI friction to actively train users to adopt a
"Split-Key" transport model, encouraging them to send the payload and the
key via separate, out-of-band channels.
Key updates in this release include:
Explicit Split-Key Sharing: The standard 1-click "Share" button has been
replaced. Coordinators must now explicitly choose between "Maximum
Security" (copies the base URL without the decryption fragment) and
"Standard" (the full combined link) via an interactive modal.
Secure-by-Default QR Codes: QR codes generated for in-person or video-call
coordination now default to "Link Only". The UI actively re-blurs the
canvas if the user toggles to include the key, preventing accidental
shoulder-surfing.
Privilege Friction: Added explicit, color-coded warning modals when a
Coordinator attempts to copy the Room Decryption Key or the Backup Admin
Token, explaining the specific blast radius of each asset.
The goal is to make the secure path the easiest path, and force an active,
conscious downgrade for convenience.
Full release notes and UI screenshots can be found here:
https://github.com/scarlin90/signingroom/releases/tag/v1.8.0
As always, I welcome any feedback on the UX/OpSec balance from those of you
who regularly coordinate multisig ceremonies.
Best regards,
Sean Carlin
On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrote:
> Hi Thomas,
> I’ve been looking through your BTSL playground source code. To make this
> work seamlessly with the Blind Relay reference implementation (Signing
> Room), it would be great if the BTSL parser and validator were available as
> a standalone, versioned NPM package.
>
> If we had an @btsl/validator package that was environment-agnostic (no
> internal fetch calls to Blockstream, just pure PSBT/Schema validation and
> minimal dependencies), I could potentially integrate it directly into the
> Signing Room client. This would allow 'Signing Room' to automatically
> detect an attached schema, run the ASSERT logic locally, and provide the
> user with a 'Verified by BTSL' green-check before they sign.
>
> The STATE_SYNC payload could be modified to something like this to pass a
> schema and type:
>
> {
> "type": "STATE_SYNC",
> "encryptedPsbt": "base64_encrypted_psbt",
> "encryptedValidationSchema": "base64_encrypted_btsl_string", //
> Optional
> "schemaType": "BTSL_V1", // Optional: Identifies the language Or
> Version ...
> }
>
> Let me know your thoughts,
>
> All the best
> Sean Carlin
>
>
>
> On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote:
>
>> Hello,
>> The transport layer problem is well addressed here. The complementary
>> piece — ensuring signers can independently validate transaction invariants
>> before signing, regardless of how the PSBT was relayed — 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,
>> Thomas Suau
>>
>> Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit :
>>
>>> 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/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8494 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
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
0 siblings, 1 reply; 9+ messages in thread
From: STEVEN SLATER @ 2026-04-06 20:12 UTC (permalink / raw)
To: Sean Carlin; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8017 bytes --]
Subject: Feedback on Blind Relay & BTSL Integration
Hi Murch,
Thanks for engaging with the Blind Relay proposal and the Signing Room
updates. I wanted to highlight a couple of areas where your perspective
would be especially valuable:
- OpSec Friction in v1.8.0: The release introduces explicit split-key
sharing and secure-by-default QR codes. Do you see this balance of UX vs.
security as sufficient for real-world multisig ceremonies, or are there
edge cases where additional friction might be warranted?
- BTSL Validator Integration: The idea of a standalone @btsl/validator
package could allow Signing Room clients to locally verify transaction
invariants before signing. From your experience with PSBT workflows, do you
think this approach would meaningfully reduce signer risk, or does it
introduce complexity that might discourage adoption?
- Blind Relay Model: Since the relay is stateless and ephemeral, it avoids
metadata persistence. Do you think this adequately addresses privacy
concerns compared to existing coordination servers, or are there attack
surfaces we should still consider?
I’d really appreciate your thoughts on whether these design choices align
with the broader goals of minimizing trust and maximizing signer
independence.
Best regards,
Steven
On Mon, 6 Apr 2026, 7:19 pm 'Sean Carlin' via Bitcoin Development Mailing
List, <bitcoindev@googlegroups.com> wrote:
> Hi everyone,
>
> Following up on the ongoing development of the Signing Room (and the Blind
> Relay coordination model), I've just released v1.8.0.
>
> While previous updates focused heavily on the cryptographic and protocol
> layers, this release hardens the Operational Security (OpSec) at the human
> layer.
>
> The Threat Model:
> A zero-knowledge server architecture is compromised if the Coordinator
> inadvertently shares the room URL and the decryption key (the #key
> fragment) over the same insecure channel (e.g., pasting the full link into
> Slack or a standard email).
>
> The Solution (v1.8.0):
> I have introduced strategic UI friction to actively train users to adopt a
> "Split-Key" transport model, encouraging them to send the payload and the
> key via separate, out-of-band channels.
>
> Key updates in this release include:
> Explicit Split-Key Sharing: The standard 1-click "Share" button has been
> replaced. Coordinators must now explicitly choose between "Maximum
> Security" (copies the base URL without the decryption fragment) and
> "Standard" (the full combined link) via an interactive modal.
>
> Secure-by-Default QR Codes: QR codes generated for in-person or video-call
> coordination now default to "Link Only". The UI actively re-blurs the
> canvas if the user toggles to include the key, preventing accidental
> shoulder-surfing.
>
> Privilege Friction: Added explicit, color-coded warning modals when a
> Coordinator attempts to copy the Room Decryption Key or the Backup Admin
> Token, explaining the specific blast radius of each asset.
>
> The goal is to make the secure path the easiest path, and force an active,
> conscious downgrade for convenience.
>
> Full release notes and UI screenshots can be found here:
> https://github.com/scarlin90/signingroom/releases/tag/v1.8.0
>
> As always, I welcome any feedback on the UX/OpSec balance from those of
> you who regularly coordinate multisig ceremonies.
>
> Best regards,
>
> Sean Carlin
>
> On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrote:
>
>> Hi Thomas,
>> I’ve been looking through your BTSL playground source code. To make this
>> work seamlessly with the Blind Relay reference implementation (Signing
>> Room), it would be great if the BTSL parser and validator were available as
>> a standalone, versioned NPM package.
>>
>> If we had an @btsl/validator package that was environment-agnostic (no
>> internal fetch calls to Blockstream, just pure PSBT/Schema validation and
>> minimal dependencies), I could potentially integrate it directly into the
>> Signing Room client. This would allow 'Signing Room' to automatically
>> detect an attached schema, run the ASSERT logic locally, and provide the
>> user with a 'Verified by BTSL' green-check before they sign.
>>
>> The STATE_SYNC payload could be modified to something like this to pass a
>> schema and type:
>>
>> {
>> "type": "STATE_SYNC",
>> "encryptedPsbt": "base64_encrypted_psbt",
>> "encryptedValidationSchema": "base64_encrypted_btsl_string", //
>> Optional
>> "schemaType": "BTSL_V1", // Optional: Identifies the language Or
>> Version ...
>> }
>>
>> Let me know your thoughts,
>>
>> All the best
>> Sean Carlin
>>
>>
>>
>> On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote:
>>
>>> Hello,
>>> The transport layer problem is well addressed here. The complementary
>>> piece — ensuring signers can independently validate transaction invariants
>>> before signing, regardless of how the PSBT was relayed — 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,
>>> Thomas Suau
>>>
>>> Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit :
>>>
>>>> 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/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9fac-cb5de96208ecn%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/CAP%2B9vXOS2w%2Bhp%2Bq00E2OS%3DJud4vcjX%3DKLfSu79ArqhnuucXxQw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10441 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
2026-04-06 20:12 ` STEVEN SLATER
@ 2026-04-10 6:55 ` 'Sean Carlin' via Bitcoin Development Mailing List
0 siblings, 0 replies; 9+ messages in thread
From: 'Sean Carlin' via Bitcoin Development Mailing List @ 2026-04-10 6:55 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 11342 bytes --]
Hi everyone,
Thanks Steven for engaging and specifically for reaching out to Murch to
review our edge cases and friction modals.
I am looking forward to his and others’ perspectives as we try to
standardize an approach to coordination.
In direct response to those discussions on edge cases and signer risk, I
have released v2.0.0 of Siging Room which introduces several architectural
and UX hardening updates:
1. Expanded Friction Modals & Signer Guidance
We have doubled down on "guided friction" modals. We added more explicit
warning modals throughout the application, specifically before downloading
raw PSBTs, audit logs, or sharing keys. These modals don't just ask "Are
you sure?", they explain the specific privacy leaks (e.g. UTXO/balance
metadata) or security risks (plaintext keys) associated with the action,
ensuring the signer is making an informed decision.
2. Enhanced Audit Events (Transparency on Human Actions)
To provide even more clarity during the signing ceremony, the client-side
audit log now tracks sensitive human interactions that don't touch the
blockchain but impact the security of the room. This includes logging
exactly when (and by which participant) a decryption key, admin token, Room
ID, or share link was copied to the clipboard. This provides a clear trail
of who accessed or shared sensitive metadata during the session.
3. Official Release of the Web Component SDK (@signing-room/embed)
A major goal of this BIP is interoperability. To that end, we have released
a framework-agnostic Web Component. This allows any Bitcoin wallet or
platform to drop the Signing Room coordination engine into their own
application as a simple HTML tag (<signing-room>).
The SDK uses an isolated iframe and Shadow DOM boundary to ensure the host
application cannot snoop on the PSBT data, preserving the zero-knowledge
security model while making the Stateless Blind Relay coordination pattern
easy to adopt across the ecosystem.
I would like to get some technical feedback on this approach and the
current events that are accessible through the embeddable web component.
Specifically:
Is the event payload (containing the final TX hex, TXID, and raw room
state) sufficient for host applications to handle settlement, or is it too
much/too little?
What other state transitions or audit events would the community like to
see exposed to the host environment?
Release Notes (v2.0.0):
https://github.com/scarlin90/signingroom/releases/tag/v2.0.0
NPM Package:
https://www.npmjs.com/package/@signing-room/embed
Interactive Sandbox & Documentation:
https://signingroom.io/webcomponent-demo.html
I’m looking forward to hearing more thoughts and any further feedback from
the list on whether these expanded friction points and the web component
SDK architecture properly address the risks inherent in application-layer
coordination.
All the best,
Sean Carlin
On Monday, 6 April 2026 at 22:04:22 UTC+1 STEVEN SLATER wrote:
> Subject: Feedback on Blind Relay & BTSL Integration
>
> Hi Murch,
>
> Thanks for engaging with the Blind Relay proposal and the Signing Room
> updates. I wanted to highlight a couple of areas where your perspective
> would be especially valuable:
>
> - OpSec Friction in v1.8.0: The release introduces explicit split-key
> sharing and secure-by-default QR codes. Do you see this balance of UX vs.
> security as sufficient for real-world multisig ceremonies, or are there
> edge cases where additional friction might be warranted?
>
> - BTSL Validator Integration: The idea of a standalone @btsl/validator
> package could allow Signing Room clients to locally verify transaction
> invariants before signing. From your experience with PSBT workflows, do you
> think this approach would meaningfully reduce signer risk, or does it
> introduce complexity that might discourage adoption?
>
> - Blind Relay Model: Since the relay is stateless and ephemeral, it avoids
> metadata persistence. Do you think this adequately addresses privacy
> concerns compared to existing coordination servers, or are there attack
> surfaces we should still consider?
>
> I’d really appreciate your thoughts on whether these design choices align
> with the broader goals of minimizing trust and maximizing signer
> independence.
>
> Best regards,
> Steven
>
> On Mon, 6 Apr 2026, 7:19 pm 'Sean Carlin' via Bitcoin Development Mailing
> List, <bitco...@googlegroups.com> wrote:
>
>> Hi everyone,
>>
>> Following up on the ongoing development of the Signing Room (and the
>> Blind Relay coordination model), I've just released v1.8.0.
>>
>> While previous updates focused heavily on the cryptographic and protocol
>> layers, this release hardens the Operational Security (OpSec) at the human
>> layer.
>>
>> The Threat Model:
>> A zero-knowledge server architecture is compromised if the Coordinator
>> inadvertently shares the room URL and the decryption key (the #key
>> fragment) over the same insecure channel (e.g., pasting the full link into
>> Slack or a standard email).
>>
>> The Solution (v1.8.0):
>> I have introduced strategic UI friction to actively train users to adopt
>> a "Split-Key" transport model, encouraging them to send the payload and the
>> key via separate, out-of-band channels.
>>
>> Key updates in this release include:
>> Explicit Split-Key Sharing: The standard 1-click "Share" button has been
>> replaced. Coordinators must now explicitly choose between "Maximum
>> Security" (copies the base URL without the decryption fragment) and
>> "Standard" (the full combined link) via an interactive modal.
>>
>> Secure-by-Default QR Codes: QR codes generated for in-person or
>> video-call coordination now default to "Link Only". The UI actively
>> re-blurs the canvas if the user toggles to include the key, preventing
>> accidental shoulder-surfing.
>>
>> Privilege Friction: Added explicit, color-coded warning modals when a
>> Coordinator attempts to copy the Room Decryption Key or the Backup Admin
>> Token, explaining the specific blast radius of each asset.
>>
>> The goal is to make the secure path the easiest path, and force an
>> active, conscious downgrade for convenience.
>>
>> Full release notes and UI screenshots can be found here:
>> https://github.com/scarlin90/signingroom/releases/tag/v1.8.0
>>
>> As always, I welcome any feedback on the UX/OpSec balance from those of
>> you who regularly coordinate multisig ceremonies.
>>
>> Best regards,
>>
>> Sean Carlin
>>
>> On Thursday, 26 March 2026 at 18:07:42 UTC Sean Carlin wrote:
>>
>>> Hi Thomas,
>>> I’ve been looking through your BTSL playground source code. To make this
>>> work seamlessly with the Blind Relay reference implementation (Signing
>>> Room), it would be great if the BTSL parser and validator were available as
>>> a standalone, versioned NPM package.
>>>
>>> If we had an @btsl/validator package that was environment-agnostic (no
>>> internal fetch calls to Blockstream, just pure PSBT/Schema validation and
>>> minimal dependencies), I could potentially integrate it directly into the
>>> Signing Room client. This would allow 'Signing Room' to automatically
>>> detect an attached schema, run the ASSERT logic locally, and provide the
>>> user with a 'Verified by BTSL' green-check before they sign.
>>>
>>> The STATE_SYNC payload could be modified to something like this to pass
>>> a schema and type:
>>>
>>> {
>>> "type": "STATE_SYNC",
>>> "encryptedPsbt": "base64_encrypted_psbt",
>>> "encryptedValidationSchema": "base64_encrypted_btsl_string", //
>>> Optional
>>> "schemaType": "BTSL_V1", // Optional: Identifies the language Or
>>> Version ...
>>> }
>>>
>>> Let me know your thoughts,
>>>
>>> All the best
>>> Sean Carlin
>>>
>>>
>>>
>>> On Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote:
>>>
>>>> Hello,
>>>> The transport layer problem is well addressed here. The complementary
>>>> piece — ensuring signers can independently validate transaction invariants
>>>> before signing, regardless of how the PSBT was relayed — 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,
>>>> Thomas Suau
>>>>
>>>> Le mercredi 25 mars 2026 à 13:21:39 UTC+1, Sean Carlin a écrit :
>>>>
>>>>> 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/acde2e84-15f1-4a15-9fac-cb5de96208ecn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9fac-cb5de96208ecn%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/86c7e3cc-1cc6-4492-ac56-132550665d2en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15766 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs
2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs 'Sean Carlin' via Bitcoin Development Mailing List
2026-03-26 0:15 ` pyth
2026-03-26 14:02 ` [bitcoindev] " Thomas Suau
@ 2026-04-14 6:27 ` Craig Raw
2 siblings, 0 replies; 9+ messages in thread
From: Craig Raw @ 2026-04-14 6:27 UTC (permalink / raw)
To: Sean Carlin; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-04-14 9:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-25 12:00 [bitcoindev] [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs '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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox