From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Apr 2026 14:04:30 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w9r7V-0004hU-2A for bitcoindev@gnusha.org; Mon, 06 Apr 2026 14:04:29 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6861462170asf2966972eaf.0 for ; Mon, 06 Apr 2026 14:04:28 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1775509463; cv=pass; d=google.com; s=arc-20240605; b=WocvHqlYV5vGVOIBcIhR9umPcLDRSCqJBqxk+O5s5/x5idQOEOFa7hz8m5qk4hPsg0 S5xCWv2Pq4KjNdIbN9Y01yyQcjD3Y8apuX7DmvjJKbI8mp/27o/0m6Wa2zsdM6WuWJnk mLmtlWpVibmrw7Fv4q+RuW+mshbM89Fuvl/TeaczvY6b6p/I1SlsT2YHNYqbwGMeY2J7 bj9QIm29uUQbIw58C6MNc1y6dKyFMOegfErQq643YP21jvN3XB5Ab8GTvbbpPHD/bVqf IeNpEMnB5CmY0GYTHGI2xyDW1Bt8o9l5mpo4JiCl5sZb694lLD8voBczqqTGph5XqYn/ PFDw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=9n7j+lOKr+O0AiM8kmcyS6SoN/lDR99v3vu2ddUWHyA=; fh=5oAyyPsEo3B5sD5PZWxFPLemVaAwi+s/zLr9Dl4uY3A=; b=UAc9V2ZFyJhx8pSVBAZFsptOzh7L0eGXAH3FJhoHzOBXyzZ524Po5IgjJOCbaxThhl 8c9wDxjKUZWxkglQRIeo2IPmgYsuuDanfdNngG8Ck02WR6uFVnUthAJM1gp5SL4qvp02 LtlPsJItaCR8M4Hrftmu9hqn389/2Www8aq7T5zEdv4btuzaJiv/e6waaDq1qjBLo+SM FuemZ7YABKul3bjLaRKmojIWRbugAYvehRYpdYZM0K7D1s8Orv3x0MsEnhRMik0OqiL7 maJIrB4TDYUaWZswE/62NsrYjEi/2bUoHmcB8XwiBgTXKsSy3yMX8zltg+o5vJrKViFZ mK3w==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=nF8JRfkC; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775509463; x=1776114263; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=9n7j+lOKr+O0AiM8kmcyS6SoN/lDR99v3vu2ddUWHyA=; b=K4dVsLKrQK1QmXZm8csfuAvCbaNYRWRi+e37C2S4tEeKZ5FynyaNd5wX13Sj0+zlTr Zp1ILPAfRYpqe/ytlBuuoMQSEfOIypDrMQ9gtlCekGNjeRP4sZ+m6PUSM597JoIaielo hAMlqlZCeUa3ZuYtvrvfr9njjHCoXHUlQq8kqGdk1Xe2yvgl6BUi6VTiyX9vmvkRBaXN pmiAWgPFWlwNYdyn9B2JfJeGHZJmS0uoQk0VTnMfTi7LT7ltBxnM7ETKY1p6SW8DqIqN b+EDOXH2Zj/6rnz1tgLGPhxJWy3mutX8i9u5vWQ8YJEDhdC83g1XfT2ygHcz/ni8ZL51 FzUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775509463; x=1776114263; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9n7j+lOKr+O0AiM8kmcyS6SoN/lDR99v3vu2ddUWHyA=; b=UJnGwVham5VFhcozCsaDtAfg3XbRuD2DK5wbXoRu6SX10ZrpImTZo78YOLDOcorhp1 5GOfhbcjLLNF5F2k09/PHb6NhgWoxSjbtUBzT4/NDYJsG8f/GVyotmU4zylFc3MXXJQ7 LcjPFFo6vQ+NDIOv13UJZgkeyM7xLcA+KpffhpBp8KLh0VqLs0yBNq+l0heuidpSm9um HVYFy3q1az4QJ95BvKCo6yx4GoLRllTSqEqmaj2QhGK3nlJVOGMtgr41zgVoDyzc6y4z 2k4NVfQeJWkXfV4ArMTMRF5mbSPvkzjK7rNY/3MhpYxdH0rH7BcguvF5YSJNfw1rIc1g R+Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775509463; x=1776114263; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=9n7j+lOKr+O0AiM8kmcyS6SoN/lDR99v3vu2ddUWHyA=; b=j1PrPeQAloOsZFjDGKc1rJitj3gk7wzD35OQFExzOByWRP+HOr78oMoJf/ABQBwRYN VGqJS/JuyqvVMtd6GZRYhizXZUBN2HEGV6S6MuzPsH6IazCrHjEG3kkKD9HB7J0NTHyq gym7Bzfa4+LEKXQ0+JA458m+2fDfh0j6X1oXvcOPbWZgfRmnWqtGr7quVtvHBBZYEfDN EpIBJ54OAH6YU7LajrtkuoS6ojKXbWgaY+KtXcUW0rOhjyw0tPo19wnfFUJkzvYt4EWD deOtIffnWW0qnvUYps4anxRztNthz4SEncyIhhuR/i70pt+SWy5YlDU1Cx2d2rsZ3Sil fybQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCXbsZkSj/NNoA6ehDu7m1YOxzqPEp4yZHUpforNtRmwhvxbDaCjQcbKL/wyuGC6nv1PXdV0FkMTZ0Bo@gnusha.org X-Gm-Message-State: AOJu0YzcLIxtAWT/lHYNkgqIpJgjYetIrTZx/SjjDhVHXctURG7QMUN2 bkogUB3hEO0k2oGD59OCMeAcTbguODVpFCpTJU85qPpp6HbiKxJ6And4 X-Received: by 2002:a05:6820:f00f:b0:67e:3a2b:922 with SMTP id 006d021491bc7-6822005b031mr7107748eaf.48.1775509462828; Mon, 06 Apr 2026 14:04:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLb87nTRBvtcYjg0dluTrFFSOCfn27rcgmLOQveIiIPsQ==" Received: by 2002:a05:6870:70a7:b0:41c:65ea:68a1 with SMTP id 586e51a60fabf-422ee040a5dls2031236fac.0.-pod-prod-03-us; Mon, 06 Apr 2026 14:04:18 -0700 (PDT) X-Received: by 2002:a05:6808:138e:b0:467:4939:9674 with SMTP id 5614622812f47-46ef57f02a1mr7710176b6e.7.1775509458533; Mon, 06 Apr 2026 14:04:18 -0700 (PDT) Received: by 2002:a05:6808:22c3:b0:467:52e4:df4a with SMTP id 5614622812f47-47040aea7bcmsb6e; Mon, 6 Apr 2026 13:12:48 -0700 (PDT) X-Received: by 2002:a05:6820:8c1:b0:67b:da6d:1672 with SMTP id 006d021491bc7-68220a4c8admr7351033eaf.63.1775506368057; Mon, 06 Apr 2026 13:12:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775506368; cv=pass; d=google.com; s=arc-20240605; b=enKFxMVpgJrmP4urPK9RvuV4wOE7fw2075LjExvuaIw0nFJ1hkRUVguNylz/cvj8gm 3p2wfvAGGVTwuyXoZLfhTmgONxYu3R05iCWe4VpC3eJe7qu2NPU1C9/MRqgv3D3ebJ68 2FGsSZnlHasOcaZK8lzW0o3oj/dkuzX9s9dXOCI66Ln6xGfeoBkJrMyb0ACMKKSKVVoV eB8E5WsUrgnFL+EyfH94jGHvqvPT+AnVQEbQosT+bY4HphPdAMQABHtYLzL8cPJwa/sa 6l/CtZDeLZ2xMU9fDGcLjThpLFOee+CU1hQv7a1Qe2rKV58DWXmgHOtLPj6Z38U0hjL2 LUXg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=2/Pi5pw6OtWHUjlkddBZJI1/stEX8YT/UwpVpTzfFSA=; fh=cRgdtQXkz2SVoRsfQ7/1fXzbcMVC7euMkEXdKPEuXWA=; b=UOP+/9NN9gSE74bkBYBenkgDlR4LYR1veyURfCPtDrOr5g2dRXOiXgcE1xWJMn3pBC DFcCQuZR/NenSG80NKOIV5FKDauPZLz1C3k/tIfdc3bJ/NIt+UF7/CW7nKKgglLs9+o6 sdTYxnl0mcMwQXM1RTNXaMWOQaGVelgs0j6YCdd1kpbZTrErbGUhf2eZnNwPnJ2K5+1F to7Ewm9vDYZKcSqIpewb3xZHqGgT93+Hns62Gyh3HyXM2poeKCC8NexOLY7exmzdausk Fa2RP6j+mATaR7ld7jm0+X6GDz2wldGIjKP/qq2mp0slDg1oTzMU9yTaJSszJq1RBROF 1neA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=nF8JRfkC; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com. [2607:f8b0:4864:20::1129]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-680a9406e37si463965eaf.4.2026.04.06.13.12.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2026 13:12:48 -0700 (PDT) Received-SPF: pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) client-ip=2607:f8b0:4864:20::1129; Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-79495b1aaa7so39748947b3.1 for ; Mon, 06 Apr 2026 13:12:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775506367; cv=none; d=google.com; s=arc-20240605; b=gOdBQSZzPJArvoXbjqW6VAmGDx5xm+bMBP55Ysrx1Mp8aaYi6uEkMohUO8C14om0sK EIXOkRKydqD/O9zpd+36sRN2YZs/KlSRnlJm7YiHKVeHti2TnvOowZaD6XZy446Twu8u mJMh4cCMfVdicYECb56tftawbZIveTpd8bkUJsZDf2DQkzyi2a3ct3izuMqVP25Nvli9 bNL6JE/EMfUSn0AYqYNjlTf7P8FOkGY7wp805mfXwOGTjYGnxqrzm8qzPg8PZKOTsLu3 cQeaNhdvvNSofO4jgo45eHvFcvQzGrvcQe8Y0M1KK+lw5JJ80nROldTfRX1qG1grlrST Z4Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=2/Pi5pw6OtWHUjlkddBZJI1/stEX8YT/UwpVpTzfFSA=; fh=cRgdtQXkz2SVoRsfQ7/1fXzbcMVC7euMkEXdKPEuXWA=; b=R49OWkxt7Jils1ug21gI7D6CfLervOvUkj1jN00SiedraCTkjABB129mFtXVxDFJy3 D9NHGSdfYr0vHZaiowGqzOICZsMIetfzY25QtwTPk2vRNf4LLnhgDHhryQ604IrCcBYI kq83ngztch5QD+kUmhnnN53FOWC+KHcDkzvraQgYhIQcx7I3aqWxG0fyxJ5JByp7Nrcp d5adYtSgMlKxMHXndmi+M8DpQXUXsB0jbty3UDTxWn2vEgmGcQLSytOxCZdroK+A+bxL Jmfj9ls9AbmIHa8KTpLoRSOK8ehNAq89R5wKwqxk8Jh99sYj4G21tqBrR9jYJlTEl5gx sPaw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDiesKCfN+63sll71rxhkfIxEZATdkbeAQiPfd446FGe8iASZo75vgXeAyvadlqOn DO0G4uMC7NM+Im6YZc8KS1zkMqho9kMCXb0wHYISjxhiAYpEfv9a8/xSYHsxAFGuguSy8Y/G3/D nYFBuagVDUYEWTNyhimU83qJbbaO9gx6A9qmcZ1svtvKCyXq2k6s1X0w5fXhzdz8IBKDmsM7Xu2 hzqNIvN2Q2MU7v12aDA3s1eZ/LRDiyD4tu6ItNAlO2BvweRNYLj3lWSYTcm3W3FeFW5WUFKNb7X 8bDuA+re X-Received: by 2002:a05:690c:4011:b0:79d:d23b:4c14 with SMTP id 00721157ae682-7a4d604f226mr102736307b3.47.1775506367182; Mon, 06 Apr 2026 13:12:47 -0700 (PDT) MIME-Version: 1.0 References: <3f1a1491-06e1-4453-9538-fa66bc432a06n@googlegroups.com> In-Reply-To: From: STEVEN SLATER Date: Mon, 6 Apr 2026 21:12:34 +0100 X-Gm-Features: AQROBzACVxtaZDl4_JpHR7QjwmXl06dLGjaRvfIlaXhJyLbfEwqySd9INflktQI Message-ID: Subject: Re: [bitcoindev] Re: [BIP Draft] Blind Relay: Stateless Encrypted WebSocket Coordination for PSBTs To: Sean Carlin Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000004ffc7d064ed04a15" X-Original-Sender: thugm501@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=nF8JRfkC; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --0000000000004ffc7d064ed04a15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99d 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=E2=80=AFpm 'Sean Carlin' via Bitcoin Development M= ailing List, wrote: > Hi everyone, > > Following up on the ongoing development of the Signing Room (and the Blin= d > 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 huma= n > 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 int= o > 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-cal= l > 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=E2=80=99ve been looking through your BTSL playground source code. To m= ake 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 an= d >> minimal dependencies), I could potentially integrate it directly into th= e >> 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 =E2=80=94 ensuring signers can independently validate transaction= invariants >>> before signing, regardless of how the PSBT was relayed =E2=80=94 is wha= t 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 =C3=A0 13:21:39 UTC+1, Sean Carlin a =C3=A9cri= t : >>> >>>> 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 P= SBTs >>>> 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 R= AM >>>> with a strict 24-hour TTL and self-destructs upon completion, providin= g >>>> 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 improveme= nts. >>>> >>>> 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-cb5d= e96208ecn%40googlegroups.com > > . > --=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/= CAP%2B9vXOS2w%2Bhp%2Bq00E2OS%3DJud4vcjX%3DKLfSu79ArqhnuucXxQw%40mail.gmail.= com. --0000000000004ffc7d064ed04a15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Subject: Feedback on Blind Relay & BTSL Integration= =C2=A0=C2=A0

Hi Murch,=C2=A0= =C2=A0

Thanks for engagi= ng with the Blind Relay proposal and the Signing Room updates. I wanted to = highlight a couple of areas where your perspective would be especially valu= able:=C2=A0=C2=A0

- OpSe= c 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 wher= e additional friction might be warranted?=C2=A0=C2=A0

- BTSL Validator Integration: The idea of a s= tandalone @btsl/validator package could allow Signing Room clients to local= ly 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?=C2= =A0=C2=A0

- Blind Relay = Model: Since the relay is stateless and ephemeral, it avoids metadata persi= stence. Do you think this adequately addresses privacy concerns compared to= existing coordination servers, or are there attack surfaces we should stil= l consider?=C2=A0=C2=A0

= I=E2=80=99d really appreciate your thoughts on whether these design choices= align with the broader goals of minimizing trust and maximizing signer ind= ependence.=C2=A0=C2=A0

B= est regards,=C2=A0
Steven

On Mon, 6 Apr 2026, 7:19=E2=80=AFpm 'Sean Carlin' via Bitcoin Dev= elopment Mailing List, <b= itcoindev@googlegroups.com> wrote:
Hi everyone,

Following up on the ongoing development of the S= igning Room (and the Blind Relay coordination model), I've just release= d v1.8.0.

While previous updates focused heavily on the cryptographi= c and protocol layers, this release hardens the Operational Security (OpSec= ) at the human layer.

The Threat Model:
A zero-knowledge server a= rchitecture is compromised if the Coordinator inadvertently shares the room= URL and the decryption key (the #key fragment) over the same insecure chan= nel (e.g., pasting the full link into Slack or a standard email).

Th= e 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: Th= e standard 1-click "Share" button has been replaced. Coordinators= must now explicitly choose between "Maximum Security" (copies th= e base URL without the decryption fragment) and "Standard" (the f= ull combined link) via an interactive modal.

Secure-by-Default QR Co= des: QR codes generated for in-person or video-call coordination now defaul= t 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 Coor= dinator 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 downg= rade for convenience.

Full release notes and UI screenshots can be f= ound here:
https://github.com/scarlin= 90/signingroom/releases/tag/v1.8.0

As always, I welcome any feed= back on the UX/OpSec balance from those of you who regularly coordinate mul= tisig ceremonies.

Best regards,

Sean Carlin

On Thursday, 26 Mar= ch 2026 at 18:07:42 UTC Sean Carlin wrote:
Hi Thomas,=C2=A0
I=E2=80=99ve been looking through= your BTSL playground source code. To make this work seamlessly with the Bl= ind Relay reference implementation (Signing Room), it would be great if the= BTSL parser and validator were available as a standalone, versioned NPM pa= ckage.

If we had an @btsl/validator package that was environment-agn= ostic (no internal fetch calls to Blockstream, just pure PSBT/Schema valida= tion and minimal dependencies), I could potentially integrate it directly i= nto the Signing Room client. This would allow 'Signing Room' to aut= omatically detect an attached schema, run the ASSERT logic locally, and pro= vide the user with a 'Verified by BTSL' green-check before they sig= n.

The STATE_SYNC payload could be modified to something like this t= o pass a schema and type:

=C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2= =A0"type": "STATE_SYNC",=C2=A0
=C2=A0 =C2=A0 = =C2=A0"encryptedPsbt": "base64_encrypted_psbt",=C2=A0
=C2=A0 =C2=A0 =C2=A0"encryptedValidationSchema": "b= ase64_encrypted_btsl_string",=C2=A0 // Optional=C2=A0
=C2=A0= =C2=A0 =C2=A0"schemaType": "BTSL_V1", // Optional: Ide= ntifies the language Or Version ...=C2=A0
}=C2=A0=C2=A0
<= br>
Let me know your thoughts,

All the b= est
Sean Carlin



On= Thursday, 26 March 2026 at 14:21:41 UTC Thomas Suau wrote:
Hello,=C2=A0
The transport layer = problem is well addressed here. The complementary piece =E2=80=94 ensuring = signers can independently validate transaction invariants before signing, r= egardless of how the PSBT was relayed =E2=80=94 is what I've been explo= ring with BTSL: https://delvingbitcoin.or= g/t/btsl-bitcoin-transaction-schema-language-a-declarative-validation-schem= a-for-psbt-workflows/2338

Best regards,=C2=A0
Tho= mas Suau

Le mercredi 25 mars 2026 =C3=A0 13:21:39 UTC+1, Sean Carlin= a =C3=A9crit=C2=A0:
H= i everyone,

I'd like to propose a new BIP for real-time, trust-m= inimized coordination of multi-signature PSBTs.

The Problem
Coord= inating N-of-M Bitcoin transactions currently forces users into a binary ch= oice:
- Manual out-of-band transfers (USB drives, secure messengers) tha= t preserve privacy but introduce high friction and error risk, or
- Stat= eful 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&q= uot; - an ephemeral, stateless, zero-knowledge WebSocket relay. All payload= s are encrypted client-side with AES-GCM-256, with decryption keys held exc= lusively 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 o= r disk storage.

A reference implementation has been running in produ= ction for three months, successfully facilitating real multisig ceremonies.=

Links
- BIP Draft: https://github.com/scarlin90/bip-stateless-psb= t-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 technica= l feedback - especially on the specification, security model, edge cases, a= nd any 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+unsubscribe@googlegroups.com.=
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/acde2e84-15f1-4a15-9fac-cb5de96= 208ecn%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.googl= e.com/d/msgid/bitcoindev/CAP%2B9vXOS2w%2Bhp%2Bq00E2OS%3DJud4vcjX%3DKLfSu79A= rqhnuucXxQw%40mail.gmail.com.
--0000000000004ffc7d064ed04a15--