PSBT Coordination over Nostr Relays · Sentinel Intelligence

A Working Note on Non-Custodial Transport for Multi-Party Bitcoin Signing

Rafael Turon — Custody Agents SL, Barcelona GitHub: rafaelturon · Vinteum Bitcoin Dev Launchpad alumnus · bitcoindevkit/bdk contributor Contact: rafael@custodyagents.com

Version 1.0 — industry-distributable working note. Shared for engineering critique ahead of formal specification.

TL;DR

Most multi-party Bitcoin custody — 2-of-3 multisig, MuSig2 Taproot aggregates, covenant-free time-locked vault designs — currently relies on a centralised coordinator to ferry Partially Signed Bitcoin Transactions (PSBTs, BIP-174) between signers. The coordinator never holds key material, but it sees who signs what and when; it can censor or delay; and under MiCA Recital 83 its transport-layer obstruction capability is the weakest link in the non-custodial defence.

This note sketches an architectural alternative: PSBT and MuSig2 signing coordination over Nostr relays as the messaging substrate, building on NIP-46 (“Nostr Connect”) and composing with MuSig2 (BIP-327) and BSMS (BIP-129). The resulting transport is non-custodial in a strict sense — no participating relay can forge a signature, steal funds, or learn the spending graph; the only failure mode is denial of service. The construction is intentionally vault-agnostic and composes cleanly with descriptor-based vault designs (Liana, AnchorWatch, Blockstream miniscript-templates) as well as the recent family of covenant-free Taproot vaults with delay-enforcing co-signers (e.g., B-SSL).

The work is open-source and standards-track. This note circulates the architecture sketch, the four substantive engineering problems, and the composability story for industry critique.

1. The transport-layer problem in multi-party custody

Bitcoin’s multi-party schemes assume the existence of some communication channel between signers. In practice that channel is almost always a centralised server operated by a wallet vendor, an exchange, or a vault provider. The architectural consequences are familiar:

Metadata leak. The coordinator observes which parties signed, in what order, against which descriptor — i.e., the entire spending graph of the custody arrangement and, by extension, the organisational structure behind it.
Censorship and delay. The coordinator can refuse to forward partial signatures or selectively delay them. The signers retain their keys but lose liveness; in adversarial conditions, this is operationally indistinguishable from custody seizure.
Single-operator failure. If the coordinator is compromised, taken offline, or legally compelled, every customer of that coordinator is simultaneously affected.

A regulatory consequence has emerged that compounds these technical ones. MiCA Recital 83 carves out non-custodial services from the Crypto-Asset Service Provider regime on the basis that the provider does not control user funds. A strict reading of “control” includes the ability to obstruct user-initiated transactions. A centralised coordinator that can delay or censor is, in that reading, exercising control — and may re-classify a non-custodial service as a custodial one despite no key access. This matters specifically for the EU market and for any service whose architecture must satisfy the regulator’s interpretation, not just the cryptographer’s.

The pattern repeats across the multi-party-custody design space. Whether the construction is a 2-of-3 multisig on legacy descriptors, a MuSig2 Taproot aggregate, or a covenant-free vault using CSV/CLTV-gated paths with backup keys and a delay-enforcing co-signer, the transport between signers remains a vendor-controlled channel. The construction’s elegance on-chain does not propagate to the coordination layer.

2. The proposal

We propose treating coordination as a protocol rather than a service. Concretely: PSBT exchange and MuSig2 nonce/partial-signature exchange ride on Nostr relays as the messaging substrate, with the relay role specified narrowly enough that no participating relay can forge a signature, steal funds, or learn the spending graph. The only failure mode an adversarial relay can produce is denial of service — which, under MuSig2’s aggregator model, is precisely the non-custodial property we want at the transport layer.

The building blocks are all standardised today:

BIP-174 (PSBT) — the data structure that flows through the transport.
BIP-327 (MuSig2) — when the wallet uses Taproot (BIP-341), the transport carries MuSig2 nonce and partial-signature exchanges rather than raw witness fragments. The resulting on-chain signature is a single Schnorr signature (BIP-340) indistinguishable from a single-signer Taproot output.
BIP-129 (BSMS — Bitcoin Secure Multisig Setup) — the standardised initial-setup protocol, used to bootstrap the multisig descriptor before the operational coordination phase begins. BSMS handles setup; the proposed work handles per-transaction operation. The two are sequential phases of the same custody lifecycle.
NIP-46 (Nostr Connect) — the standardised remote-signer transport pattern over decentralised relays.

None of these standards is individually novel. Their composition under adversarial-relay assumptions is — to our knowledge — not yet formally specified for PSBT-shaped multi-party transactions where the spending policy is itself a Miniscript object subject to satisfiability constraints.

The closest published academic work is SmartBLock (Rahmanikivi, Pérez-Solà, Garcia-Font, 2025), a Bitcoin-anchored smart-lock access-control protocol in which the coordinating layer holds no key material. SmartBLock establishes the coordination-without-custody pattern that this work extends from physical access control to high-stakes Bitcoin custody governance. The fundamental difference is the substrate: SmartBLock uses on-chain transactions as the coordination signal (paying confirmation latency and on-chain fees in exchange for permanent global auditability); this work substitutes off-chain Nostr relays (sub-second latency, zero on-chain cost, but ephemeral and locally-auditable only).

3. Architecture sketch

A minimal architectural diagram, with three Signers and a redundant relay mesh:

                  [Signer S1]   [Signer S2]   [Signer S3]
                        \           |            /
                         \          |           /
                    ┌─────┴──────────────────────┴─────┐
                    │   Distributed Relay Mesh (DRM)   │
                    │                                  │
                    │     R1   ←   R2   →   R3         │
                    │                                  │
                    │   encrypted PSBT/MuSig2          │
                    │   fragments, ephemeral           │
                    └────────────────┬─────────────────┘
                                     │
                                     ▼
                            [Bitcoin Network]

Each Signer connects to one or more relays in the mesh. PSBT fragments and MuSig2 nonce / partial-signature messages are encrypted end-to-end between Signers using NIP-46-style remote-signer envelopes; the relays carry ciphertext only. The redundant topology — multiple independent relays in parallel — provides liveness even if any single relay is compromised, slow, or under attack. No relay possesses key material; no relay can decrypt fragments; no relay can independently validate the underlying Bitcoin transaction.

What the architecture provides

Property	Status-quo coordinator	DRM (proposed)
Latency	sub-second	sub-second
On-chain fee	none	none
Metadata visibility to operator	full	none
Censorship resistance	weak (single operator)	strong (multi-relay)
Single point of failure	yes	no
MiCA Recital 83 posture	contested	clean
Key custody	none	none

The latency parity matters. Prior decentralised coordination work has used Bitcoin itself as the signalling layer (SmartBLock-style on-chain coordination). That gives global-consensus auditability but pays the cost in confirmation latency and on-chain fees. For institutional custody operations the latency budget is sub-second; an off-chain ephemeral substrate is the only credible substrate at that bound.

4. Four open engineering problems

Four problems sit between the architectural sketch and a deployable specification. They are listed here as the substantive work ahead, not as solved questions.

Problem 1 — Local accountability without global consensus

The status-quo coordinator at least produces operator-controlled logs; SmartBLock-style on-chain coordination produces a globally verifiable audit trail. An ephemeral relay substrate produces neither by default. The engineering question is what cryptographic structure on individual messages preserves enough local accountability — proofs of misbehaviour verifiable by signers or by a third-party auditor — without re-introducing a global observer.

Concretely: under what relay-trust assumptions (single relay, k-of-n relay redundancy, fully Byzantine relays) does the accountability property hold, and how does it degrade?

Problem 2 — Policy-aware transport without privileged validation

Real institutional custody runs on Miniscript: thresholds, timelocks, hash preimages, nested conditions. A naïve relay forwards anything; a sophisticated relay refuses to forward fragments inconsistent with the descriptor. The latter sounds appealing — until it becomes a censorship point.

The question is whether a relay can perform partial policy validation (refuse obviously-malformed fragments) without learning enough about the transaction to act as a gatekeeper. This is where the division of validation labour between client-side proof engines and transport-layer relays gets designed. The honest answer may be that the validator must remain entirely client-side and the relay must remain entirely content-blind; we want to verify this with formal analysis rather than asserting it.

Problem 3 — Threat model commensurate with eight-figure stakes

SmartBLock’s threat model concerns adversaries seeking unauthorised physical access; the value behind the lock bounds the attack budget. Institutional Bitcoin custody routinely secures eight-figure positions, and the adversary set is correspondingly more sophisticated: supply-chain attacks against hardware signers, physical-coercion attacks against signing parties (the recent surge in documented “wrench attacks” is the surface manifestation of this trend), and protocol-level balance-availability attacks analogous to LockDown’s Lightning-channel results (Pérez-Solà et al., FC 2020).

The question is what additional protocol invariants — perhaps borrowed from the threshold-cryptography literature or from the LockDown methodology — must the coordination layer enforce to be safe at this value-at-risk?

Problem 4 — MuSig2 state management under adversarial relay delivery

This is the most cryptographically sharp problem. BIP-327 mandates that the Sign algorithm must not be executed twice with the same secnonce; reuse permits secret-key extraction from the two partial signatures. The MuSig2 specification assumes the aggregator and signers can establish ordered, reliable communication. A Nostr-relay substrate breaks all three of those assumptions in distinct ways:

Multiple-relay redundancy may deliver a single logical message via several physical paths, with reordering and duplication.
Adversarial relays may withhold, delay, or selectively deliver messages.
Stateless signers — a MuSig2-supported pattern — under at-least-once delivery may retry on timeout without knowing whether their previous attempt succeeded.

The core security-critical invariant — secnonce-uniqueness — must be enforced not only by the signer’s local state machine but by the combined behaviour of signer + transport layer. A retry-on-timeout client interacting with an unreliable relay environment is exactly the failure mode that produces re-execution of Sign with the same secnonce — and therefore secret-key extraction.

Two specific sub-questions:

What is the minimum set of protocol invariants on the Nostr transport layer required to guarantee secnonce-uniqueness end-to-end across all MuSig2 signing sessions, under at-least-once message delivery semantics?
Does the BIP-327 PartialSigVerify mechanism — designed to identify malicious signers — extend cleanly to the case where signers receive an aggregated aggnonce from a relay rather than directly observing each others’ pubnonces? Or does this introduce identifiability gaps?

This is the axis where property-based testing (proptest in Rust) is non-negotiable. The state space of an asynchronous multi-party protocol under at-least-once-delivery retry semantics is too large for manual case analysis; race conditions around secnonce reuse will be found by proptest-style adversarial-scheduler testing or they will be found by attackers.

5. Composability with vault designs

The DRM substrate is intentionally vault-agnostic. Any multi-party Bitcoin construction that needs to coordinate PSBT signing benefits from a non-custodial transport — including the family of descriptor-based multisig designs (Liana, AnchorWatch, self-hosted multisig on Sparrow/Specter) and the recent family of covenant-free Taproot vault designs with delay-enforcing co-signers (e.g., B-SSL).

Two observations sharpen the composability claim:

5.1 Orthogonal layers

A vault design specifies what spending paths exist and under what conditions they can be exercised on-chain. A coordination protocol specifies how the parties holding shares of those spending paths exchange the bytes required to produce the signatures. The two are independent design choices, and a single coordination protocol can serve many vault designs. The same coordination substrate that operates a 2-of-3 multisig today should be able to operate a covenant-free time-locked vault with mirrored backup keys and a delay-enforcing co-signer tomorrow, without architectural change.

5.2 Delay-enforcing co-signers are particularly transport-sensitive

Vault designs that include an off-chain delay-enforcing co-signer — variously called a “convenience service”, a “co-signing oracle”, or a “trust-minimised custodian” — make the transport layer’s adversarial properties operationally load-bearing. The delay enforcer is itself a coordination peer; if the transport between user and delay enforcer is centralised, the very intermediation the on-chain design eliminated is re-introduced one layer up. A non-custodial coordination layer keeps the delay-enforcer’s role narrow — co-signing on a time schedule, nothing else — which is the only configuration in which “trust-minimised custodian” is a meaningful claim.

The same observation applies to any inheritance or deadman-switch construction whose recovery custodians communicate with the user (or with each other) to produce the recovery PSBT. The coordination substrate is the natural place for those custodian relationships to be cryptographically narrowed.

5.3 What this looks like end-to-end

For a vault design with signers (e.g.) {A, A₁, B, B₁, C} distributed across user, backup user, custodian, backup custodian, and a delay-enforcing co-signer, the lifecycle becomes:

  BSMS (BIP-129)  →  DRM Transport  →  On-chain settlement
    [setup]          [per-tx ops]     [Bitcoin network]

BSMS handles the initial agreement on the descriptor — XPUB exchange, descriptor agreement, tamper-resistant persistence across heterogeneous vendors. The DRM Transport handles the per-transaction coordination — gathering nonces, exchanging partial signatures, enforcing secnonce-uniqueness, finalising the PSBT. The Bitcoin network handles settlement.

A future BIP describing the DRM Transport would cite BIP-129 as a structurally aligned complementary protocol. The shared encryption discipline (PBKDF2-SHA512 + AES-256-CTR + HMAC-SHA256) is directly inheritable.

6. Prior engineering and project status

This work is anchored on three concrete artefacts:

An asynchronous streaming PoC for the Bitcoin Development Kit — github.com/rafaelturon/bdk-electrum-streaming-poc — implementing the event-driven subscription substrate that a Nostr-relay client requires. The README explicitly identifies this as the prerequisite engineering milestone for a Nostr-based remote signer.
An accepted Pull Request in bitcoindevkit/bdk upstream.
The author’s prior architectural work on PIX, the Brazilian Central Bank’s instant-payment messaging infrastructure — directly relevant operational experience with high-stakes, low-latency, adversarial-aware financial messaging at scale, recognised by the Bank for International Settlements.

The author is a graduate of the Vinteum Bitcoin Dev Launchpad and an active member of Bitdevs Barcelona.

Roadmap

The 18-month plan, sequenced as discrete deliverables:

D1 (months 1–4) — Formal threat model and protocol specification covering all four engineering problems, with explicit reference to BIP-174, BIP-327, BIP-129, and NIP-46 and explicit articulation of where each upstream protocol’s guarantees hold or require additional invariants under the Nostr-substrate assumptions.
D2 (months 3–9) — Reference implementation in Rust, layered on rust-bitcoin, rust-miniscript, and a Rust MuSig2 implementation (e.g., secp256k1-zkp bindings). Nostr-client transport built on the bdk-electrum-streaming-poc async streaming substrate. MuSig2 session-state management with explicit secnonce-uniqueness enforcement. Property-based testing harness using proptest. Open-source release under MIT or Apache-2.0 on GitHub and crates.io.
D3 (months 6–12) — Empirical evaluation: latency, throughput, and relay-trust degradation under varying network and adversarial conditions, against both the on-chain coordination baseline and the centralised-coordinator baseline.
D4 (months 12–18) — Peer-reviewed publication. Target venues: ESORICS workshops (Data Privacy Management; Cryptocurrencies and Blockchain Technology) and the Financial Cryptography Bitcoin Workshop.

7. How to engage

This is shared for engineering critique. The kinds of feedback most likely to advance the work:

Implementers building multi-party signing flows who can point at where the relay-substrate assumptions break against real wallet UX — especially mobile clients with intermittent connectivity, hardware-signer integration constraints, and the operational realities of human signers across time zones.
Designers of vault constructions whose architecture assumes specific properties of the inter-signer transport that this note may not satisfy. The composition is the load-bearing claim; we want to know where it fails.
Cryptographers willing to look at the MuSig2 secnonce-uniqueness problem (Problem 4) and indicate whether existing analyses extend or whether a new proof obligation is required for the Nostr-substrate setting.
Engineers familiar with the NIP-46 ecosystem who can assess the gap between general-purpose Nostr signing (designed primarily for social-network events) and high-stakes financial coordination.

Direct contact: rafael@custodyagents.com. Custody Agents is Barcelona-domiciled (CIF B24890931). A fuller research outline including the formal threat model is available on request.

Reading list

Rahmanikivi, Pérez-Solà, Garcia-Font (2025). SmartBLock: a smart lock protocol over the Bitcoin blockchain. Blockchain: Research and Applications. DOI: 10.1016/j.bcra.2025.100350.
Pérez-Solà, Ranchal-Pedrosa, Herrera-Joancomartí, Navarro-Arribas, García-Alfaro (2020). LockDown: Balance Availability Attack against Lightning Network Channels. Financial Cryptography and Data Security (FC).
Nick, Ruffing, Jin (2023). BIP-327: MuSig2 for BIP340-compatible Multi-Signatures. Bitcoin Improvement Proposal 327. Status: Deployed.
Nguyen, Gray, Bencun, Chen, Novak (2020). BIP-129: Bitcoin Secure Multisig Setup (BSMS). Bitcoin Improvement Proposal 129. Status: Complete.
NIP-46: Nostr Connect (Nostr Implementation Possibilities, remote signer specification).
BIP-174: Partially Signed Bitcoin Transactions.
BIP-340: Schnorr Signatures for secp256k1.
BIP-341: Taproot: SegWit version 1 spending rules.
Poelstra, Towns, et al. rust-miniscript.

Status: working note v1.0 for industry circulation. Companion document to the full v2 research outline (academic register, NLnet / OpenSats / ACCIÓ grant framing), available on request. Author: Rafael Turon, Custody Agents SL, Barcelona.