Hello,<br /><br />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.<br /><br />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:<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Questions I'd particularly like input on:<br /><br />- 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?<br /><br />- 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?<br /><br />- 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.<br /><br />Craig, Andreas: you've both thought about this longer than I have, so I'd especially value your reading.<br /><br />Jakub

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegroups.com</a>.<br />