Hi Jakub,

In my opinion this use case should be addressed as part of a general specification for inter-wallet communication, including similar use cases for PSBT sharing, multisig setup and payment confirmations. I've written some thoughts on this previously in response to a prior BIP proposal: https://groups.google.com/g/bitcoindev/c/GTIO4xDX5MU/m/-MoPJhiTAwAJ. Scope will influence all of the design decisions you've mentioned, so I think that needs to be considered first. Wallet developers won't want to implement a different transport and sync for every current and potential inter-wallet data format.

I think the ideas of deterministic discovery, merge semantics and transport agnosticism all have merit. However, I'm unconvinced Nostr should be the reference transport. Nostr optimizes for censorship resistance over everything else; IMO financial data sharing should optimize for privacy over everything else: see my comments on ephemerality and OHTTP in the linked message as concrete examples of this.

Separately, I'm working on a BIP proposal for canonical output descriptors which may have relevance.

Craig

On Sun, Sep 13, 2026 at 11:47 PM Jakub <mr.tokkino@gmail.com> wrote:

Hello,

BIP-329 solved the data layer for wallet labels, but moving labels between wallets is still a manual export/import cycle. Users running multiple wallets over the same descriptor (a desktop coordinator plus a mobile watch-only, for example) never see a consistent view of their labels, and UTXO labels are the worst case: coin selection decisions that affect privacy get made blind.

Before writing a full specification, I'd like to gauge interest in, and gather feedback on, standardizing synchronization of unmodified BIP-329 records through a shared, untrusted store. The core ideas:

1. Deterministic discovery. Wallets derive a storage location and encryption keys from the wallet descriptor (canonical form: sorted xpubs + script type + network, hashed with domain separation via HKDF). Two wallets holding the same descriptor find the same data with zero configuration and no private keys, so coordinator and watch-only wallets are first-class.

2. Encrypted envelope with merge semantics. Records travel as byte-for-byte BIP-329 JSON inside an AEAD-encrypted envelope carrying an author timestamp and tombstones (BIP-329 has no deletion concept). Merging is last-write-wins per (type, ref), with timestamps taken from inside the ciphertext, never from transport metadata. Periodic full snapshots let a fresh wallet restore without unbounded history and tolerate stores that prune.

3. Transport agnosticism. The envelope and merge rules assume only a dumb store with put/fetch. Nostr relays would be the reference transport (an addressable event for the latest snapshot, regular events for deltas), but a plain HTTPS store or a synced folder satisfies the same interface. The store learns nothing about content and cannot forge records; its availability affects freshness, never correctness, since the wallet's local database stays authoritative.

Prior art: Bitcoin Safe already ships descriptor-rendezvous label sync over Nostr carrying BIP-329 payloads, so this would standardize a pattern with a production existence proof rather than a greenfield design. SLIP-0015 is the cautionary tale: deriving from private keys excluded coordinator wallets entirely.

Questions I'd particularly like input on:

- Key derivation modes. Mode A derives encryption keys from the descriptor itself: zero-interaction restore for a watch-only wallet recreated from the descriptor alone, but every past holder of your xpubs can read your labels. Mode B uses an independent random sync secret (Bitcoin Safe's model): descriptor holders see that sync exists but read nothing, at the cost of one more thing to back up. Which should be the mandated default?

- Identity model. A single shared derived keypair with symmetric encryption is simpler and enables restore-from-descriptor, but any key holder can write as well as read. Bitcoin Safe instead pairs per-device keys with manual approval. Is the pairing step worth keeping in a standard?

- Canonical descriptor form: should the wallet identifier hash the full script template or a coarse script-type tag? The former risks divergence from inconsistent descriptor serialization across wallets; the latter risks colliding wallets that share xpubs under different templates.

Craig, Andreas: you've both thought about this longer than I have, so I'd especially value your reading.

Jakub
--
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/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegroups.com.