From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 13 Sep 2026 14:48:07 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x5s3S-0008V7-Eo for bitcoindev@gnusha.org; Sun, 13 Sep 2026 14:48:07 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-4485c1944e8sf556182fac.2 for ; Sun, 13 Sep 2026 14:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789336080; x=1789940880; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=VpZIrjHtn45Jshc4FuModiMb5eC/FbYM3fGryRc07Ts=; b=vWQuqyx4q6WyFH3dFv5llH2IIGNWWk8Bx0Ai+NXNtBqp3FFCxvXUNcTwP0mv1L40BA GPejhSfrE7l/MvovCCW4YbbDr4oM8bjW4cxvspZyclINeE96Hj4uEQokpgn8RMmPSXqz 4s7Ypfv0zpUb8lznSnhGoYuEhUJrkPatzvyPOHHUBR9IPTsceDBjynjiKp37FtSrz5D9 WvyO+nsmYkUHj1u47jdZZvjcfy1+QxqeHg/w5DxHqtDpLarvyBso6c1qlI65p3wTe+zD PaY+HNawEtWpwdZgQy7QzMt1Aey/JGLtte9pFEvnAR+LWV0wZ5F3nT3ShKk3T2Unv7xi 2Maw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789336080; x=1789940880; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=VpZIrjHtn45Jshc4FuModiMb5eC/FbYM3fGryRc07Ts=; b=neB0suKhVqfExSMqhirAjBaxhrqv28VQRAbcxQV67dZj//PfFq0MCNAxlQ5i5GIRuM 6eDX6k5Z4hBm0JZ5AHVXBO65G3GhtCugD2+fPmi9y98QLRoDYAjbk+eBY2rIBnP/fpzR D8bNmXRrJxQPgb/tO5dNM4ESvfNaQ6F6kWrbyfxlBrbRYn2EIhcQAF9eXWWjxq3WEOmk /XxnLTar83JsY8O60rBVU8/wCibYpC5wb01kAAh1U1Z5TseDXYZtWGb4O+gt3q4/ScLn iMPe6IZOOV5Jjv0cjdw3+kuPkEDNEQOkHfzLZI4dLczEuQFMlXQXHu3j3pw3FiQFpnzx ivBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789336080; x=1789940880; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=VpZIrjHtn45Jshc4FuModiMb5eC/FbYM3fGryRc07Ts=; b=DKM/eMGXtBv1uT9X4xpd4SmboHCFMvT6m0qOgp/9pg9QcSdDAN7W5/kl5v9lXgIUmv N7GC7Se6g9V3ssclZv4nVLY1MCUVZbpT7IpkIWspBm9cPd8S12fwzJVSMccizOrMyGbk TOg/eWeOJ/b7uIbX+Y/5CYurdnQ6jLv6oA/OJZzHeyOBWS+dcyVAV1HxNWjFUcQTbiwk EAWbXL6uMoCLIiSQjhHEGUgcMSwhecJI52WeE+crLOBOxPeAjZvp65vCfzaClf1j5lOS ysiqH6Hqy5Oj5KEKjGsVQPvKhtMxB9ANSmUGqTqncFR3N32V5blpRRY0RROid/EinDOV SwXw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvByD1jJ0+LGkdDZD82ob373a7CoV02r5bg5M6adtHqhxIEgcujbz/Tgc9b08zMF5IPymnvOBkvxCw38/@gnusha.org X-Gm-Message-State: AFuF++nvW/KixOSyDTQD0Z3SM+rQ1iC1+9+T90WfD1PT7ZPhLFere08B owH1jg3p2eFPGXq+1vb5O/YAYYXF+TTkdNGVOcyJ8KTj2kui3P1kAblI X-Received: by 2002:a05:6870:c188:b0:447:4cf0:eb19 with SMTP id 586e51a60fabf-47deac65b38mr8877076fac.4.1789336079561; Sun, 13 Sep 2026 14:47:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfQnvi4lNKrFGC1HzLzvxXD1vKkWhletvy7/aM3M2UsYg==" Received: by 2002:a05:6870:1764:b0:479:bbe:a700 with SMTP id 586e51a60fabf-47c8212ce1als3455695fac.0.-pod-prod-06-us; Sun, 13 Sep 2026 14:47:52 -0700 (PDT) X-Received: by 2002:a05:6808:c413:b0:4b9:e5fa:8a13 with SMTP id 5614622812f47-4c4a9098b55mr4890512b6e.24.1789336072397; Sun, 13 Sep 2026 14:47:52 -0700 (PDT) Received: by 2002:a05:690c:4346:b0:848:c909:19b5 with SMTP id 00721157ae682-8850c86216fms7b3; Sun, 13 Sep 2026 12:47:41 -0700 (PDT) X-Received: by 2002:a05:690c:91:b0:871:8a81:a2c9 with SMTP id 00721157ae682-887a87bfbb2mr15411497b3.22.1789328860275; Sun, 13 Sep 2026 12:47:40 -0700 (PDT) Date: Sun, 13 Sep 2026 12:47:39 -0700 (PDT) From: Jakub To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_136682_1677935832.1789328859982" X-Original-Sender: mr.tokkino@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_136682_1677935832.1789328859982 Content-Type: multipart/alternative; boundary="----=_Part_136683_1226698106.1789328859982" ------=_Part_136683_1226698106.1789328859982 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_136683_1226698106.1789328859982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,

BIP-329 solved the data layer for wallet labels, but movi= ng labels between wallets is still a manual export/import cycle. Users runn= ing multiple wallets over the same descriptor (a desktop coordinator plus a= mobile watch-only, for example) never see a consistent view of their label= s, 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 synchron= ization of unmodified BIP-329 records through a shared, untrusted store. Th= e core ideas:

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

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

3. Transport agnosticism. The envelope and merge rule= s assume only a dumb store with put/fetch. Nostr relays would be the refere= nce 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 alr= eady ships descriptor-rendezvous label sync over Nostr carrying BIP-329 pay= loads, so this would standardize a pattern with a production existence proo= f rather than a greenfield design. SLIP-0015 is the cautionary tale: derivi= ng from private keys excluded coordinator wallets entirely.

Ques= tions I'd particularly like input on:

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

- Identity model. A single sha= red derived keypair with symmetric encryption is simpler and enables restor= e-from-descriptor, but any key holder can write as well as read. Bitcoin Sa= fe 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-typ= e tag? The former risks divergence from inconsistent descriptor serializati= on across wallets; the latter risks colliding wallets that share xpubs unde= r 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegroups.com.
------=_Part_136683_1226698106.1789328859982-- ------=_Part_136682_1677935832.1789328859982--