PSBT/MuSig2 coordination over Nostr relays: transport invariants for nonce safety under at-least-once delivery

Central coordination, typically handled by a wallet vendor's coordinator, presents potential risks including central points of failure or surveillance. However, recent developments suggest that Nostr relays could decentralize this aspect effectively. Platforms like Joinstr, Munstr, Smart Vaults, and Nunchuk have already started integrating Nostr relays to handle parts of their transaction traffic. A notable publication from August has explored the use of Nostr relays for coordinating PSBT and MuSig2, leveraging the remote-signer pattern from NIP-46 and integrating with BSMS (BIP-129) to prevent relay access to key material or the ability to decrypt fragments. This model primarily faces risks from denial of service attacks perpetrated by adversarial relays. Additionally, nonce safety remains a critical concern under adversarial conditions, highlighting the need for robust handling of nonce states and message sequencing. The examination of these systems raises questions about the sufficiency of client-side controls and the feasibility of constructing garbage-resistant transport layers that do not impose censorship. For further insights, refer to PSBT Coordination over Nostr Relays and Vault Construction and Coordination Transport.

From a user perspective, the reliability of wallet applications during failures is crucial. Users must understand whether the wallet can autonomously recover from issues like offline relays or duplicate messages. Transparent communication regarding wallet recovery processes is essential for user trust, especially when substantial funds are involved. Recovery processes are largely dependent on the local session state and predefined timeouts rather than on diagnosing the exact cause of the failure. Wallets handle various states of connection loss and message duplication through mechanisms that prevent re-signing within the same session, ensuring security.

Further discussions clarify the procedures users should follow if they need to close and reopen their wallets during recovery phases. It is safe for users to close their wallets at any stage, provided that closing equates to aborting the session. However, the implications of closing vary based on whether it occurs before or after the Sign command. Actions like restoring wallet state from a backup or syncing across devices could potentially resurrect compromised nonce states, posing significant risks. Therefore, session state should be managed to be device-local and excluded from backups or syncs to prevent unintended session resurrection. The conservative approach would involve structuring the wallet so that closing the application ends the session, which maintains security by design. Adding warnings for live sessions and specifying normative requirements can further mitigate risks associated with user actions during active signing sessions.