* [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores)
@ 2026-09-13 19:47 Jakub
2026-09-14 10:06 ` Craig Raw
0 siblings, 1 reply; 2+ messages in thread
From: Jakub @ 2026-09-13 19:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores)
2026-09-13 19:47 [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores) Jakub
@ 2026-09-14 10:06 ` Craig Raw
0 siblings, 0 replies; 2+ messages in thread
From: Craig Raw @ 2026-09-14 10:06 UTC (permalink / raw)
To: Jakub; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5692 bytes --]
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
> <https://groups.google.com/d/msgid/bitcoindev/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPR5oBMgNRJQbnkj1-bV7AVpDYB%2BJKQ2M5_3aKUUJ%3DzjH9XWzw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6907 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-14 20:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-13 19:47 [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores) Jakub
2026-09-14 10:06 ` Craig Raw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox