From: Jakub <mr.tokkino@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores)
Date: Sun, 13 Sep 2026 12:47:39 -0700 (PDT) [thread overview]
Message-ID: <afe6b286-427b-4bae-b7ba-b0c29623ea41n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3753 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 4097 bytes --]
next reply other threads:[~2026-09-13 21:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 19:47 Jakub [this message]
2026-09-14 10:06 ` [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores) Craig Raw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afe6b286-427b-4bae-b7ba-b0c29623ea41n@googlegroups.com \
--to=mr.tokkino@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox