From: Craig Raw <craigraw@gmail.com>
To: Jakub <mr.tokkino@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores)
Date: Mon, 14 Sep 2026 12:06:47 +0200 [thread overview]
Message-ID: <CAPR5oBMgNRJQbnkj1-bV7AVpDYB+JKQ2M5_3aKUUJ=zjH9XWzw@mail.gmail.com> (raw)
In-Reply-To: <afe6b286-427b-4bae-b7ba-b0c29623ea41n@googlegroups.com>
[-- 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 --]
prev parent reply other threads:[~2026-09-14 20:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
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='CAPR5oBMgNRJQbnkj1-bV7AVpDYB+JKQ2M5_3aKUUJ=zjH9XWzw@mail.gmail.com' \
--to=craigraw@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=mr.tokkino@gmail.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