From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 14 Sep 2026 13:55:16 -0700 Received: from mail-oi1-f183.google.com ([209.85.167.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x6Dhr-0003CT-CU for bitcoindev@gnusha.org; Mon, 14 Sep 2026 13:55:16 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-4b28dbf4197sf5327884b6e.2 for ; Mon, 14 Sep 2026 13:55:15 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1789419309; cv=pass; d=google.com; s=arc-20260327; b=U1y7xV39VQxDrgogQx39vfWror2tOoOYVZn/z5VuO352etw460n/R5XDpDdvxWQogy Vlx1fr2q/QOA3v7Bhdn0gc1csgqYGL8aaL/hDjEfJlvqHOrq0w6S5qwCYTPCh/G4r7hD dU6aVgedv0z+vJtrBkXcxY4HlQLLaQhZSuimkL/xF+X48RhiBG+2ttUjGSvsAix10Z4B BIB+Jx7weUYqmNbRMeYApipR+8xq5pBaXGV4VJU7HBTNCSQ06XrdBCV9HU1FIUxkEboR G+JqHoI9evGNYVRSMRoX6NrygvUP1kU6HRg+K9zwaqJVBMB1jytK2WN8CmTiKY1PUfRv Harw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=4LBF+87ZN7vb26Z2sdhAzvg3jS3XqbdsbUQbDRYU7mY=; fh=JcyvleLHBVJWbH6hbbV52seA4SW1q7x05W50lHpclZk=; b=Ek5/kLB8KprpZH2mzD9EPu6E2JV/c6fvcq+wgyN1NvmF/SkIoE+i7vECQbeWSfn3+k 8+nOux0r3/PaWybiRWP97Zj/Rdt7qiEuMSwL8/auHA/K9SZF7bqhjD3s18dbasEzewq2 UkGIKkvha8qlB7DgBCa0YAUu4RitgtBGBzALC/eSnw9b6IefgrOCnlv9eAJ0MTc3u44j wjYFzoBX2wNLZIMzt4UOtSbGR/mqJg7gjYH6wpZmAarDra4s569WJ9XG7q/onXZZNNID ekUnr0roOH+Rzk2DvM5tSE6v7dgUSVW1CieGiIJQU3NU0Ff90jodmTsv+MBywhc8taUE rFTw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="nxarNSw/"; arc=pass (i=1); spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789419309; x=1790024109; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4LBF+87ZN7vb26Z2sdhAzvg3jS3XqbdsbUQbDRYU7mY=; b=asO3goiiIyJb3nRtqSGNIaSrYVryzIeFlh3kF10tQ6IdAHrvD0WIvV7VZpr3iavML5 pSVIketJtbsTf7bu0Y6SM75rbZ/WKp9czU31zrIXj5eRWlMfY/NwUA9w3sf+pMRWAtu+ Dwky/HaroMiaMmoEHj2QnGtuvQ8u/BVDaHUoFEZRc97AdeHwjDaV1I88pEOedkUYRlKM Lt2K2oGu4vYsttLmPGn+k9+t+rpt64nuzqGYeFW1slmLAzyrML8cB5A/zEYYSlI+u3fC UwnbOXJh7pvChu+HCR92iDRmE++YLc8oRvQ+gAh4wgI9kB4ZCaAWIvluOTJcQbELEdJm ChgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789419309; x=1790024109; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4LBF+87ZN7vb26Z2sdhAzvg3jS3XqbdsbUQbDRYU7mY=; b=sdBoSI7St8WneQKSV1++foOjhaUKYrY1hCwmnkHqSW2WkCCjFEK4JCH7hSbnfJ/moZ ZbZVcWqQeONsRX4QhKFpRYRjkbUTphKcp6w0ZJ7hZU6fg49bH/9rnfpuua9cVv3yDZcY KLBfFe6C7r13lUCUbZ8rXmAnMR6FgTrSlCQC5Koy92TC7pAtRTkXMJ2DKbfVaKG188CI 1U230sBkYDsgmnXyYGHN6hQINzND/m4REUgOa5yKHkdCD+5c+cAaTssxC/4R59eEJw66 pwmBNPIfvYTZlgAhcg80UTg0uIiCwB7g5lDfW4GT3DWG2zYKxIv+mnGgO/ahHr4QBQin bKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789419309; x=1790024109; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=4LBF+87ZN7vb26Z2sdhAzvg3jS3XqbdsbUQbDRYU7mY=; b=UkFfa7e6nEZtDBhctzhr99o1dok5yEnAI1ueR+KoYTMqJyxZV3idgvL1BD2liqV6OD tI8QuHV4tObxi8Qws1wMdA+5ITXUZBBlamsPrIMyEypEKoxSqVvYdu22BLpik2/XRLnO TkydjULcuGiUCAbJy8CYy/tqLiE3szxxZ0sIYgixxvR1qVcy/OH2WSvyo+g+BHQxIPLZ hjqcylVDJ/EMBpFYJRjzhIRVskhdnlNEryZT1ccJjkiNmPXLmXR3lGq2SUxivLSPRXSp YRaPgfVVjBBeGY/3lPzB2+0jh9CIGqDKq0fctCA+uTpcMRPhcF5UrxqLxY+3uiJ29Nu2 lyNA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AKwUvByoI5sUsLsotgh+n6VcyS44CKdYU3LGtEsm0n1oBYjnp5NjCMdQks9pCv5B1aNgOz9swhXnYjbDkWn3@gnusha.org X-Gm-Message-State: AFuF++k8c/3ifdJ0xohB2Y8VRkAEDssa2OE3NB85Wvq2iR0tG/7bJrxU tzTpuW/mx/UHL6nMaENPVKYoAXbcuCzhlw9ekSe6PCYOti2NThKQS6Cx X-Received: by 2002:a05:6808:4f0d:b0:4b9:e6ab:d081 with SMTP id 5614622812f47-4c7b626af11mr3300819b6e.33.1789419309003; Mon, 14 Sep 2026 13:55:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfl8HjreR5KvEAo0rdvVzTf+GsO54UrGUDnW4ZugqNpuw==" Received: by 2002:a05:6870:e2cc:b0:479:e31:7dc5 with SMTP id 586e51a60fabf-47c86fdea84ls5351329fac.1.-pod-prod-07-us; Mon, 14 Sep 2026 13:55:01 -0700 (PDT) X-Received: by 2002:a05:6808:1645:b0:4c3:bc6a:a328 with SMTP id 5614622812f47-4c7b617597emr2708458b6e.31.1789419301709; Mon, 14 Sep 2026 13:55:01 -0700 (PDT) Received: by 2002:a05:6808:aa4:b0:4c4:b241:2216 with SMTP id 5614622812f47-4c4b24158ecmsb6e; Mon, 14 Sep 2026 03:07:01 -0700 (PDT) X-Received: by 2002:a05:6a20:e292:b0:3cd:9dea:2be1 with SMTP id adf61e73a8af0-3db3ff581abmr3860843637.0.1789380420176; Mon, 14 Sep 2026 03:07:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789380420; cv=pass; d=google.com; s=arc-20260327; b=d3Ki86wTGONtBiTp1ImgSUrzzIEYIRPelhbrLnPOXMWOxEajnKlegaPW7R/YsIde/L n7ExtvHD2UqH3Rj+dHFU9fQdtwSMhZy0PV9tG3sx4hqHaw58A/jJsJS14LQZ9SPIJcSB +umjJdDDJlybEhkzV157D2YXl985gxhoVmYqA4URT/Z/d17D3xIn+yPXnOnfbCia5Sy8 yl7oywZvqQktGwndjnF7ZE0jgR179VynrEu8YYIuSt0HriVpVwFSbVY9kf8mNoq2QjHi 20M5UfKOIEb6izB4R1dzLSACozzXNZL9jJVJlI2unE2DBVfu8AHifZ1E/8t3tCtwL5f8 buOg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Fwdf1vi638y1zukTAylcV2O5dCOnPyf9Bk9yS77bxkU=; fh=v4MOvC3XZd+cE/rEstWCsN5BRUlMQjES9V24Ly5z078=; b=eER+E4uL6/VpbsqgrYrLgI1PdUQBL3laiupu/lk4ihNr8K6nheijrrBsiKP3QBiEHR vKBtPqfMUWeh4ani9bzQnM5nswH5a853t/USzNPd1ikKrSiCDOJkNRq8WZr9eFDejmxe zHv3Qz7yDYFOFnWeikfNJgmto36eUL5V7lc3KW2FQhK+FUsW72ewybY/RFXF1ehqeOhM l78rnR4yBGSBYAeoMbxqioswqB/KC1k8cGWYsy3qDgJEAZyfZY8p0noeYCJYkMmCHxyh EqwJY+c/iVzIso5L5I+mbyEMqY4qc0pmOdfEPsj/xZj9a54iO2QBYPkuNBI7QZdrrQim L4bg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="nxarNSw/"; arc=pass (i=1); spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com. [2607:f8b0:4864:20::f34]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-cc4c6570396si275468a12.7.2026.09.14.03.07.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:07:00 -0700 (PDT) Received-SPF: pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) client-ip=2607:f8b0:4864:20::f34; Received: by mail-qv1-xf34.google.com with SMTP id 6a1803df08f44-90e970f710cso37665836d6.3 for ; Mon, 14 Sep 2026 03:07:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789380419; cv=none; d=google.com; s=arc-20260327; b=RTwSFhJ8sCVBFCStP7xppK+QRrK+c4MZ881YOkeL6FS7NNXm9o5P9f8gu+fAMxWfl3 fRUXD5rAV8Xq6/XR+4KHehTz8FsG96ZMb0uparmNahPMFEExvlhOGhPtfpG8ua4sGeiG kAe9YwHGeIf91UItnT6uSD6otLqQfL+AbdWS5ePIz2i5v7JqQH7491E3D+4qXUhqDiqL gKt/vgfRVnraUdgQO9cYxqicTEMM3Ed8vjhVbQqWn6qjqtmGAD5ME9uLUzMe65ECAIT/ 0A8ifTzB3izM/NLE8pJaH0UOGO7Tkbm4aY/wi9Gah/rJfy8EPL49GiglMLllghyrzmxe G8uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Fwdf1vi638y1zukTAylcV2O5dCOnPyf9Bk9yS77bxkU=; fh=v4MOvC3XZd+cE/rEstWCsN5BRUlMQjES9V24Ly5z078=; b=K7KoFcvijxQ1Fb0btH+GaZsClfhj99jkHfJEQCnDO9Scm+SJ/Pjk4SIpTDXsCE8VPn fIK5YIb/lz7fLCa8JIDjaDOFTRLbza995QcaBFjStZSNSao90GYT1JHtfNToiAX7uH10 izkK3u5kC9aHM/0h1sP1l48lNMYSBPyiTHJMQ8W1QDFOP1S+AL+X79i+jgXR3BKxM8ai qQk9Pygc9ptT1sd0ek30HlOi70haTq1lPB2BTOILvjDUCPK1gbD5dZ3StsS6Vy4NOrJa l8RH/SfZJx06oaCFrhtD6CSwo4BWB7frkC3sjK3Elv15nSxexrKVSTlwYVisDwbI72nC ++lg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AYBFou2fu8Pz5alNvlPfEt9S0DFKB3XQm/UbJoRIpkP/JBCr0C8h1kosyVjjCzq7hUb ayDqwJlH6ZmcBvAesIi4mRZo7Ip6apkEppO+doR9RsmXmG5WJVhyIQ32Rs2CJrYhdNQIIPKuU1M bVevZHIuxWmsHzBN0lJnwwOs2SJ1s8fwgSpkhIhhUlKJMznJPR8PgVsQp4/ezwW8lMP18ltFbXZ FBE8gJXG2okFwxRBkY1KoOGzdlKZT3kGEk4vvZsUoh+aG82YHIXl9D8Xpz01Im5fCHNeQ95fmHk 33ESHhNYMUjCchMMAv5qQec3/uF0ujKQOR/jvlYPUebqjbxGSO0WKSrRxtMqmKXor0f+7wfufhg 1XMfaPgVdUwA5AUDG3Q8a8vZN2xOqN4cQ0keu7DKFG9nFeGG1qKIFH57cpFHcpySFwU0FOqY/4q 6pFCqGBthKARTclS8Fh16yt83iQmoRpgNGWdDYMoiVZQ== X-Received: by 2002:a05:6214:5713:b0:90e:7fa0:2da0 with SMTP id 6a1803df08f44-9122e660282mr26636296d6.26.1789380419132; Mon, 14 Sep 2026 03:06:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Mon, 14 Sep 2026 12:06:47 +0200 X-Gm-Features: AcwNN1VpRvbne7yRKE8Zjlp4Nr5C7a8mIKnLtXgwJxFVQAdxbZT-46J7Ck0gMk8 Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Wallet label synchronization (BIP-329 records over encrypted stores) To: Jakub Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000402594065b6e986e" X-Original-Sender: craigraw@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="nxarNSw/"; arc=pass (i=1); spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --000000000000402594065b6e986e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Jakub wrote= : > Hello, > > BIP-329 solved the data layer for wallet labels, but moving labels betwee= n > 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 walle= ts > holding the same descriptor find the same data with zero configuration an= d > 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). Mergin= g > 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), bu= t > 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 loc= al > 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 descripto= r > itself: zero-interaction restore for a watch-only wallet recreated from t= he > descriptor alone, but every past holder of your xpubs can read your label= s. > 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 standar= d? > > - 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 ris= ks > 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-b0c2= 9623ea41n%40googlegroups.com > > . > --=20 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 e= mail 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. --000000000000402594065b6e986e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jakub,

In my opinion this use case s= hould be addressed as part of a general specification for inter-wallet comm= unication, including similar use cases for PSBT sharing,=C2=A0multisig setu= p and payment confirmations. I've written some thoughts on this previou= sly in response to a prior BIP proposal:=C2=A0https://groups.google.co= m/g/bitcoindev/c/GTIO4xDX5MU/m/-MoPJhiTAwAJ. Scope will influence all o= f the design decisions you've mentioned, so I think that needs to be co= nsidered first. Wallet developers won't want to implement a different t= ransport and sync for every current and potential inter-wallet data format.=

I think the ideas of deterministic discovery, merge semantics and transport=C2= =A0agnosticism=C2=A0all= have merit. However, I'm unconvinced Nostr should be the reference tra= nsport. Nostr optimizes for censorship resistance over everything else; IMO= financial data sharing should optimize for privacy over everything else: s= ee my comments on=C2=A0= ephemerality and=C2=A0O= HTTP in the linked message as concrete examples of this.
<= span style=3D"background-color:transparent">
Separately, I'm working on a BIP pr= oposal for canonical output descriptors which may have relevance.

= Craig



On Sun, Sep 13, 2026 at 11:47=E2=80= =AFPM Jakub <mr.tokkino@gmail.co= m> 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 mo= bile watch-only, for example) never see a consistent view of their labels, = and UTXO labels are the worst case: coin selection decisions that affect pr= ivacy get made blind.

Before writing a full specification, I'd l= ike to gauge interest in, and gather feedback on, standardizing synchroniza= tion of unmodified BIP-329 records through a shared, untrusted store. The c= ore ideas:

1. Deterministic discovery. Wallets derive a storage loca= tion and encryption keys from the wallet descriptor (canonical form: sorted= xpubs + script type + network, hashed with domain separation via HKDF). Tw= o wallets holding the same descriptor find the same data with zero configur= ation 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 a= uthor timestamp and tombstones (BIP-329 has no deletion concept). Merging i= s last-write-wins per (type, ref), with timestamps taken from inside the ci= phertext, never from transport metadata. Periodic full snapshots let a fres= h wallet restore without unbounded history and tolerate stores that prune.<= 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), b= ut a plain HTTPS store or a synced folder satisfies the same interface. The= store learns nothing about content and cannot forge records; its availabil= ity affects freshness, never correctness, since the wallet's local data= base stays authoritative.

Prior art: Bitcoin Safe already ships desc= riptor-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 parti= cularly like input on:

- Key derivation modes. Mode A derives encryp= tion keys from the descriptor itself: zero-interaction restore for a watch-= only wallet recreated from the descriptor alone, but every past holder of y= our xpubs can read your labels. Mode B uses an independent random sync secr= et (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 pe= r-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.<= br>
Craig, Andreas: you've both thought about this longer than I hav= e, 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/afe6b286-427b-4bae-b7ba-b0c29623ea41n%40googlegrou= ps.com.

--
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/bitcoindev/CAPR5oBMgNRJQbnkj1-bV7AVpDYB%2BJKQ2M5_3aKUUJ%3DzjH9XWzw%= 40mail.gmail.com.
--000000000000402594065b6e986e--