a4e5a45e99c1f713ead671b3edc2e4c938e1b0
1 Delivery-date: Thu, 11 Dec 2025 23:29:03 -0800 2 Received: from mail-oa1-f55.google.com ([209.85.160.55]) 3 by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 4 (Exim 4.94.2) 5 (envelope-from <bitcoindev+bncBD64ZMV5WMLBBM4I57EQMGQEWBELJAY@googlegroups.com>) 6 id 1vTxaI-0001Ff-Lp 7 for bitcoindev@gnusha.org; Thu, 11 Dec 2025 23:29:03 -0800 8 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3f0d1a7a9c2sf620196fac.3 9 for <bitcoindev@gnusha.org>; Thu, 11 Dec 2025 23:29:02 -0800 (PST) 10 ARC-Seal: i=2; a=rsa-sha256; t=1765524536; cv=pass; 11 d=google.com; s=arc-20240605; 12 b=I16sE46HFcZYZuFkwzMLrbZ+j+nxIGNZ9k+y0mD7fAfFvpPlq3qV8UiKAmhPzW2YEH 13 m7x60IdjtMKfiMB4AxXW7Xm393owPTo/ZOOEqKrp4S+qG1K4dOjgJfjQZceM1YRKdZik 14 OyTO4ooot1Fn+Jmr3QRn5JtjvArR42dKTG28kdDyYzgkLI1F74HgqUar9PAaFHInlYuW 15 7Q0xuW/34CVHEWRMk18UttN5PcqXnNzuiO8OIhy3yLXH/pL0/HAqHYTQKnSb5gtGM+dl 16 1B2jIThutg9CZYTCGTQhRAJXI1AfeHjuvZjEHtUtewB32/waW7+wlhydH7Subiu+Uelf 17 Hg8Q== 18 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 19 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post 20 :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from 21 :in-reply-to:references:mime-version:sender:dkim-signature 22 :dkim-signature; 23 bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; 24 fh=UoEU8cVlz33nKjowm0374ldGdCZ+h5i6Yi7jP2UU6Ck=; 25 b=UqqRH8iopCvC/Z0MQPK96K26Zb+ylBkCXLO7J8lrZunhkJwXf2gXYIgw8uYQ12unXM 26 H3DdrMJ63/lwzVHd6AEo8pYsOzzXVlvz3LBV8QnwEYbgC40AYbcrAKasAtLYp39cEjJG 27 KAe2RgeXFMi0jxtXeHORYfX9ooNtU0Om/N8IR/WLmwuFGnpp2lEq4DoSR9EImsnEpl43 28 diFjxYu6IGU9dY4TO+b127MW6CAMEGL/imE2A0TqYtXOnD2XhnGrD9du2pmi98MVOMgB 29 YE30xmU+N1NQhHWNfbGoo0Bwnh417KTLXDk+xVwaKmEQEYgpUlYU/85cweX3VdW0VFHh 30 rB+A==; 31 darn=gnusha.org 32 ARC-Authentication-Results: i=2; gmr-mx.google.com; 33 dkim=pass header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; 34 spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=eunovo9@gmail.com; 35 dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; 36 dara=pass header.i=@googlegroups.com 37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 38 d=googlegroups.com; s=20230601; t=1765524536; x=1766129336; darn=gnusha.org; 39 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post 40 :list-id:mailing-list:precedence:x-original-authentication-results 41 :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to 42 :references:mime-version:sender:from:to:cc:subject:date:message-id 43 :reply-to; 44 bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; 45 b=KTsHUF3UPsbVBvWinBW/xvN4k7E++8kdgJzjnwqkh6sUJ32UJ3FWPUwrAh4vyjgFQ2 46 c7uQ+/6K44bQIlczu3GQaBaWS5K+A472j7IXM1vp9DkAkf1uAgk8oCzckpSkkt+RprIi 47 Or/feqlXuUApynBXwIwXGaLgrN2f3Wnx7dTjJ2H4eLZn45ukQHhxbyZ4bmh9luRZm47d 48 V5p2YUqBNh2VsOMS4+iE4DkPeXbVASruyphg/o4MNYybzpMnxFbH6/wAXzNRZy4Mq57Y 49 tFF10BHgPBGwITHYyXLSOg7IBNi3UXKOaRwQEQ+Sbf0V8N+z4gFvFfX+I8oG9t50TszV 50 lGWw== 51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 52 d=gmail.com; s=20230601; t=1765524536; x=1766129336; darn=gnusha.org; 53 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post 54 :list-id:mailing-list:precedence:x-original-authentication-results 55 :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to 56 :references:mime-version:from:to:cc:subject:date:message-id:reply-to; 57 bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; 58 b=jqcLXxoQ/1eooblqC+jjgOhlIFl4HOYN0euxdrjMkNk5PnZXxICs3Zu4ySychgnP8l 59 kYXAxbpcB+MaqJf155uDbNzwLBaAJCun4nTlr2knm1/qH4HgdghgSpSM5b7ubk1DvILy 60 cHCH1g8x/eAD5YWWoNQgInYoaR5KAZiw7IilQhcVMix62dPAiXsXRxRJkCLl4v/BUuOg 61 4XLGlRCxFQ/uUK17glEbOCioT09OyIw+Sk2OCjh3aFWBd8V7xs6QB3Akv63RK3pDgAPZ 62 PYbpAg119hGvYBdmyx+Xl2ffTEaQ9FWD83beybtD5HKhkcYFCF+U7RlTYdbuwVHUgm4B 63 JWhg== 64 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 65 d=1e100.net; s=20230601; t=1765524536; x=1766129336; 66 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post 67 :list-id:mailing-list:precedence:x-original-authentication-results 68 :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to 69 :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state 70 :sender:from:to:cc:subject:date:message-id:reply-to; 71 bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; 72 b=ArMfo05NVhGKV0MTSnjA0Qc5J2A6AxNPhxvhdadE/uydXOHqxgjJn9PfwvpUd+stdL 73 j35UP2tmemqc5V299oKQsmFryDsTwvNkJNmeRS+BtFbUYD6bVUwmxqGsaYv9/OXNO6/3 74 mibLd8Rd5wK6Dk6ukpwn9e4obJGad/hgLOKdw/e4RxlZJi4MAeSLbjdzR4nn6deyr8GN 75 dpsZ8eLFtIz50RoE2/zHGEwSEOsjNGcR9tUUEzVfnu58amaj4zHvl477jOcj5N9LWM+O 76 vG6VzFDaMiAYoY1GSLDqX8aR56w4PZM9yV4byNtlBHy/MoAZgxQwNpvr4s/KkvbpulEv 77 d51g== 78 Sender: bitcoindev@googlegroups.com 79 X-Forwarded-Encrypted: i=2; AJvYcCUF/77kKErBw5BD5UOfOQBTDB+KoASUBN1VXxcHAPS3+QpX2QV0/vDdav8IktjUKYn0st0zqY09ydgx@gnusha.org 80 X-Gm-Message-State: AOJu0YxQcAui/sl+C1ZSz28XALwGZx28+J7EzKksBevwvQ5+EML8P+uV 81 jINvWhSc9iI7nl+PPGl/UruQzClUpBsRxP794HHW+17H2lTNFyZCDHqH 82 X-Google-Smtp-Source: AGHT+IG0NuWKSovRj9w+V3awJgy+6CfNSS7aFJrNXQUVIQ/AssEIYDydYOR9D7ETmLuhp1IadZqvjg== 83 X-Received: by 2002:a05:6870:b60a:b0:3e8:3382:aaed with SMTP id 586e51a60fabf-3f5f8a0bc8emr605381fac.12.1765524535682; 84 Thu, 11 Dec 2025 23:28:55 -0800 (PST) 85 X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYVPpsAbzQR0uHe6LrvgniG8H/BLLYORP5G/EA2qBKOfQ==" 86 Received: by 2002:a05:6870:aa89:b0:3ec:5074:681b with SMTP id 87 586e51a60fabf-3f5f87f491els159079fac.2.-pod-prod-06-us; Thu, 11 Dec 2025 88 23:28:51 -0800 (PST) 89 X-Received: by 2002:a05:6808:15a4:b0:43f:6979:6c9d with SMTP id 5614622812f47-455ac7f6afemr485308b6e.7.1765524531701; 90 Thu, 11 Dec 2025 23:28:51 -0800 (PST) 91 Received: by 2002:a05:6808:a5d2:10b0:44f:fe66:38a2 with SMTP id 5614622812f47-455a761a2c0msb6e; 92 Thu, 11 Dec 2025 23:22:16 -0800 (PST) 93 X-Received: by 2002:a05:6808:14c8:b0:450:1f44:d1ce with SMTP id 5614622812f47-455ac9d8385mr371362b6e.64.1765524135371; 94 Thu, 11 Dec 2025 23:22:15 -0800 (PST) 95 ARC-Seal: i=1; a=rsa-sha256; t=1765524135; cv=none; 96 d=google.com; s=arc-20240605; 97 b=CLcsblFB11kCoOFoahT77cDfGt7VJGFN2Bmhk6lIEwHyZd9nCBtwkpSGHC1rOAtLd4 98 tYZXq9aDVLPwI+wcY0IScBr0tvhQbkjz9ALpIMhUmB11OUOwlWY7Co9oHzyFZDT5HX9O 99 SisWj82hiHGOVCTlO1QFmVLdlvGAoZbm2PhX1g4A68esF5ylJM8KtQ9IgMgLZL6you0F 100 2YkSrrlksoCAwFKoIGuodLFro8Of1AzwkAPh0n4yhw5UUU1DGK7hYbh9Bz3wm0zXmxgJ 101 qDXs8fYRQHy2wTbF0PjZWvCZZzQJtwAKhhk4aNNdolI4Z/C8oU5DGCcu6Pk51uvU3/WU 102 nU4w== 103 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 104 h=cc:to:subject:message-id:date:from:in-reply-to:references 105 :mime-version:dkim-signature; 106 bh=pCQrhBKFkal6uzS5U3VEgjJP8zjmemnTb9JuoYZp3YE=; 107 fh=Firs9aU8UUrTC2Il09j93tv/gVfId1RjWFRagBcPp9k=; 108 b=g5dEIOkiFwT6VQ5YNvM76PD87VXt5TW3JiXPbHs3WiY1REvEbiZhYhueTwN0HYaPQA 109 MjrFwg8tBSSU+G4FbpcEdXlkOUUmGeyK2ltrHrq0TrlDbcxPlgwvCwhJ2OzVkKG3/Lyf 110 CgXWxA252dy3hGkcacWXrGwF7dB+960odcTqK/yRt+11bHMIS0BUPchE8bKAREfQP9ST 111 VUty9G97q+btTt7t8UUlTKrIe9N46jB2Us1als6MGqo7jZmtBTxGw32YB3HynGmgVikU 112 P4Vcs3cJr0JaBT7lBQ2wkMecZ+m51Ib4faKbxMuC11enEouOOeUqE62uHfGVwvgwXiKE 113 q3ug==; 114 dara=google.com 115 ARC-Authentication-Results: i=1; gmr-mx.google.com; 116 dkim=pass header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; 117 spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=eunovo9@gmail.com; 118 dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; 119 dara=pass header.i=@googlegroups.com 120 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com. [2607:f8b0:4864:20::82d]) 121 by gmr-mx.google.com with ESMTPS id 5614622812f47-4559894fcb4si107590b6e.0.2025.12.11.23.22.15 122 for <bitcoindev@googlegroups.com> 123 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); 124 Thu, 11 Dec 2025 23:22:15 -0800 (PST) 125 Received-SPF: pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) client-ip=2607:f8b0:4864:20::82d; 126 Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-4ee1879e6d9so10251131cf.1 127 for <bitcoindev@googlegroups.com>; Thu, 11 Dec 2025 23:22:15 -0800 (PST) 128 X-Gm-Gg: AY/fxX4hlTWJ9SIapTMQwPW5rIUEgNBJHGVYSUxq8OtHxgut1lhZjdCei5qM2YNDeiU 129 SR6efG7Mdb6gd8RCg3EhNDD0A7FJrCTCFEofEEwKQ/BO3zldsY0BOBrpVk34fXeMKNQh0ioevkx 130 gaEUVMtsvYpdEkwjOkTrety8U9doJjXNJ12yJM6pAnsIBefdKKPNXoegMa3tTDUHqBSMyuT4ahX 131 9zfYsgQVcyuLl8lAXE/Rcb2euv42qrf9iM2dBvezhZZaaMmt8FgzCMWnIX44JPzRB0B04x2 132 X-Received: by 2002:a05:622a:1aa5:b0:4f1:b956:6125 with SMTP id 133 d75a77b69052e-4f1d04b9a79mr14429521cf.20.1765524134644; Thu, 11 Dec 2025 134 23:22:14 -0800 (PST) 135 MIME-Version: 1.0 136 References: <CAPR5oBNCd65XaipOF=eXW7PT+JRVC4m6ey+X42aQsKa1YzA-Xw@mail.gmail.com> 137 <CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww@mail.gmail.com> <CAPR5oBPH=mbv4N3_4vuCcf+mDTCiT52WDb=qQ6KNuT=6Qr5tKA@mail.gmail.com> 138 In-Reply-To: <CAPR5oBPH=mbv4N3_4vuCcf+mDTCiT52WDb=qQ6KNuT=6Qr5tKA@mail.gmail.com> 139 From: Oghenovo Usiwoma <eunovo9@gmail.com> 140 Date: Fri, 12 Dec 2025 08:22:03 +0100 141 X-Gm-Features: AQt7F2pAwPyGg3a9wgaB5LbGoFEKm0y5ajIOrrNHkaePFavsjQujcFOtBombb-A 142 Message-ID: <CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y+GaGnKRCMv1kk3pKw@mail.gmail.com> 143 Subject: Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 144 To: Craig Raw <craigraw@gmail.com> 145 Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> 146 Content-Type: multipart/alternative; boundary="000000000000e350350645bc1ebe" 147 X-Original-Sender: eunovo9@gmail.com 148 X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass 149 header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; spf=pass 150 (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as 151 permitted sender) smtp.mailfrom=eunovo9@gmail.com; dmarc=pass (p=NONE 152 sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 153 Precedence: list 154 Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com 155 List-ID: <bitcoindev.googlegroups.com> 156 X-Google-Group-Id: 786775582512 157 List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> 158 List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> 159 List-Archive: <https://groups.google.com/group/bitcoindev 160 List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> 161 List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, 162 <https://groups.google.com/group/bitcoindev/subscribe> 163 X-Spam-Score: -0.5 (/) 164 165 --000000000000e350350645bc1ebe 166 Content-Type: text/plain; charset="UTF-8" 167 Content-Transfer-Encoding: quoted-printable 168 169 Hi Craig, 170 171 I see how adding the birthday to the descriptor string could be beneficial 172 for anyone trying to use a third-party scanning server; they will only have 173 to submit the descriptor string, and the server will automatically 174 determine what height to start scanning from. However, without the 175 birthday, the descriptor will still be able to describe its outputs. The 176 birthday can be collected through some other means, as we do with other 177 descriptors today. 178 179 I'm opposed to using new key formats because I do not think we have enough 180 justification to do so. With existing key formats, users and wallets will 181 be able use their existing master key to generate silent payment outputs 182 using a descriptor like: 183 sp(<master_key>/352h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0). 184 185 > A self-describing format which makes the use and sensitivity of the key 186 material immediately obvious 187 > The advantages of Bech32m encoding, including strong error detection and 188 unambiguous characters 189 I'm not sure these are strong enough to warrant new key formats. 190 191 > Safety from accidentally mixing different unrelated scan and spend keys 192 I'm not sure what the chance of this happening is. We already have 193 descriptors with multiple keys having complex relationships. Compared to 194 those, the "sp()" is simple. Users are supposed to back up the entire 195 descriptor string. If this is done properly, then the keys should not be 196 mixed up. 197 198 > Versioning to indicate silent payments version 0 199 We should use the descriptor prefix to indicate the silent payments version 200 instead of the keys. 201 202 > A similar format to an xpub, the display of which is a common user 203 interface element in many wallets, which makes things simpler for wallet 204 developers and users alike 205 Things can be even simpler without the new key format. 206 207 From your original email: 208 > Finally, zero or more positive integers may be specified as further 209 arguments to scan for additional BIP352 labels. 210 IIUC, this creates a descriptor with a variable length. What if we encoded 211 multiple labels in one number? For example, labels 1, 5, 10 are encoded 212 into a 64-bit number by setting the corresponding bit positions to '1' so 213 that the final number is '1058'. Using one number to encode the labels is 214 very appealing to me. 215 216 Kind regards, 217 Novo 218 219 On Thu, Dec 4, 2025 at 12:02=E2=80=AFPM Craig Raw <craigraw@gmail.com> wrot= 220 e: 221 222 > Hi Novo, 223 > 224 > Responses inline: 225 > 226 > > I'm not sure adding a block height does much to reduce scanning burden. 227 > We can already scan from the taproot activation height and it won't matte= 228 r 229 > much anyway, because the chain will get longer and this only helps 230 > temporarily. 231 > 232 > I'm not sure I follow here. Since we need to retrieve and compute possibl= 233 e 234 > matching outputs for all eligible public keys in the chain, having a bloc= 235 k 236 > height later than the Taproot activation date can make a significant 237 > difference, and will make a greater difference in future as the chain gro= 238 ws. 239 > 240 > > Is there any reason to add the birthday to the descriptor? Other 241 > descriptors do not do this. 242 > 243 > The difference between this and other descriptors is that it cannot 244 > describe outputs without reference to the blockchain. This, combined with 245 > the significant computational burden which other descriptors do not have = 246 to 247 > bear, is reason enough I think to include it here as an optional argument= 248 . 249 > 250 > > For example, we can set the maximum number of labels in the bip; wallet= 251 s 252 > will only have to scan for this max number of labels during recovery and = 253 if 254 > a wallet goes beyond this maximum number, they have gone beyond the bip a= 255 nd 256 > are now responsible for ensuring full recovery of funds. 257 > 258 > The problem with this approach is that scanning for each additional label 259 > adds incrementally and non-trivially to the computational burden. For eac= 260 h 261 > label, there is an EC point addition and comparison against all taproot 262 > outputs for an eligible transaction. Some benchmark numbers indicating th= 263 e 264 > relative cost of each additional label are in [1], demonstrating that 265 > scanning for 100k labels is cost-prohibitive. As an aside, I will add tha= 266 t 267 > labels have a limited use case, and in most cases a new BIP44 account is = 268 a 269 > better choice for additional silent payment addresses based on the same 270 > seed. 271 > 272 > > Given the above points, I argue that we don't need to introduce new 273 > scan and spend key formats, and we can use "sp(scankey,spendkey)". 274 > 275 > While not strictly necessary, using spscan and spspend key 276 > expressions make for a much better user experience and reduce the chance 277 > for user error. With this encoding we get: 278 > 279 > 1. A self-describing format which makes the use and sensitivity of the 280 > key material immediately obvious 281 > 2. The advantages of Bech32m encoding, including strong error 282 > detection and unambiguous characters 283 > 3. Safety from accidentally mixing different unrelated scan and spend 284 > keys 285 > 4. Versioning to indicate silent payments version 0 286 > 5. A similar format to an xpub, the display of which is a common user 287 > interface element in many wallets which makes things simpler for walle= 288 t 289 > developers and users alike 290 > 291 > --Craig 292 > 293 > [1]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080/11 294 > 295 > On Thu, Dec 4, 2025 at 11:39=E2=80=AFAM Oghenovo Usiwoma <eunovo9@gmail.c= 296 om> 297 > wrote: 298 > 299 >> Hi Craig, thank you for taking this up. I have the following comments, 300 >> based on a light inspection of your original email. 301 >> 302 >> > In order to reduce the scanning burden, a block height may be 303 >> optionally specified in the sp() expression as a second argument for a 304 >> wallet birthday. 305 >> 306 >> I'm not sure adding a block height does much to reduce scanning burden. 307 >> We can already scan from the taproot activation height and it won't matt= 308 er 309 >> much anyway, because the chain will get longer and this only helps 310 >> temporarily. 311 >> 312 >> Users can also specify a "wallet birthday" in their wallets which can be 313 >> used for scanning. Is there any reason to add the birthday to the 314 >> descriptor? Other descriptors do not do this. 315 >> 316 >> > Finally, zero or more positive integers may be specified as further 317 >> arguments to scan for additional BIP352 labels. The change label (m =3D = 318 0) is 319 >> implicitly included. 320 >> 321 >> In 322 >> https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-an= 323 d-recovery 324 >> , a strategy to recover funds from labels is specified. We can attempt t= 325 o 326 >> make this stronger and avoid the need to also include an integer for 327 >> labels. For example, we can set the maximum number of labels in the bip; 328 >> wallets will only have to scan for this max number of labels during 329 >> recovery and if a wallet goes beyond this maximum number, they have gone 330 >> beyond the bip and are now responsible for ensuring full recovery of fun= 331 ds. 332 >> 333 >> > In summary a new top level script expression sp() is defined, which 334 >> takes as it's first argument one of two new key expressions: 335 >> - spscan1q... which encodes the scan private key and the spend public ke= 336 y 337 >> - spspend1q... which encodes the scan private key and the spend private 338 >> key 339 >> 340 >> Given the above points, I argue that we don't need to introduce new scan 341 >> and spend key formats, and we can use "sp(scankey,spendkey)". 342 >> 343 >> I'm happy to hear any counter arguments you have. 344 >> 345 >> Novo 346 >> 347 >> On Thu, 4 Dec 2025, 12:40=E2=80=AFpm Craig Raw, <craigraw@gmail.com> wro= 348 te: 349 >> 350 >>> Hi all, 351 >>> 352 >>> There is a practical need for a silent payments output descriptor forma= 353 t 354 >>> in order to enable wallet interoperability and backup/recovery. There h= 355 as 356 >>> been some prior discussion on this topic [1][2] which this BIP proposal 357 >>> builds on: 358 >>> 359 >>> https://github.com/bitcoin/bips/pull/2047 360 >>> 361 >>> In summary a new top level script expression sp() is defined, which 362 >>> takes as it's first argument one of two new key expressions: 363 >>> 364 >>> - spscan1q... which encodes the scan private key and the spend 365 >>> public key 366 >>> - spspend1q... which encodes the scan private key and the spend 367 >>> private key 368 >>> 369 >>> The outputs may then be generated by combining this key material with 370 >>> the sender input public keys. 371 >>> 372 >>> In order to reduce the scanning burden, a block height may be optionall= 373 y 374 >>> specified in the sp() expression as a second argument for a wallet 375 >>> birthday. Finally, zero or more positive integers may be specified as 376 >>> further arguments to scan for additional BIP352 labels. The change labe= 377 l (m 378 >>> =3D 0) is implicitly included. 379 >>> 380 >>> Examples: 381 >>> sp(spscan1q...) 382 >>> sp([deadbeef/352'/0'/0']spscan1q...,900000) 383 >>> sp(spspend1q...,842579,1,2,3) 384 >>> sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10) 385 >>> 386 >>> --Craig 387 >>> 388 >>> [1]: 389 >>> https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment= 390 -descriptors 391 >>> [2]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080 392 >>> 393 >>> -- 394 >>> You received this message because you are subscribed to the Google 395 >>> Groups "Bitcoin Development Mailing List" group. 396 >>> To unsubscribe from this group and stop receiving emails from it, send 397 >>> an email to bitcoindev+unsubscribe@googlegroups.com. 398 >>> To view this discussion visit 399 >>> https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7P= 400 T%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com 401 >>> <https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7= 402 PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com?utm_medium=3Demail&utm_so= 403 urce=3Dfooter> 404 >>> . 405 >>> 406 >>> 407 408 --=20 409 You received this message because you are subscribed to the Google Groups "= 410 Bitcoin Development Mailing List" group. 411 To unsubscribe from this group and stop receiving emails from it, send an e= 412 mail to bitcoindev+unsubscribe@googlegroups.com. 413 To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 414 CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y%2BGaGnKRCMv1kk3pKw%40mail.gmail.com. 415 416 --000000000000e350350645bc1ebe 417 Content-Type: text/html; charset="UTF-8" 418 Content-Transfer-Encoding: quoted-printable 419 420 <div dir=3D"ltr">Hi Craig,<br><br>I see how adding the birthday to the desc= 421 riptor string could be beneficial for anyone trying to use a third-party sc= 422 anning server; they will only have to submit the descriptor string, and the= 423 server will automatically determine what height to start scanning from. Ho= 424 wever, without the birthday, the descriptor will still be able to describe = 425 its outputs. The birthday can be collected through some other means, as we = 426 do with other descriptors today.<br><br>I'm opposed to using new key fo= 427 rmats because I do not think we have enough justification to do so. With ex= 428 isting key formats, users and wallets will be able use their existing maste= 429 r key to generate silent payment outputs using a descriptor like: sp(<ma= 430 ster_key>/352h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0).<br><br>&g= 431 t; A self-describing format which makes the use and sensitivity of the key = 432 material immediately obvious<br>> The advantages of Bech32m encoding, in= 433 cluding strong error detection and unambiguous characters<br>I'm not su= 434 re these are strong enough to warrant new key formats.<br><br>>=C2=A0Saf= 435 ety from accidentally mixing different unrelated scan and spend keys<br>I&#= 436 39;m not sure what the chance of this happening is. We already have descrip= 437 tors with multiple=C2=A0keys having complex relationships. Compared to thos= 438 e, the "sp()" is simple. Users are supposed to back up the entire= 439 descriptor string. If this is done properly, then the keys should not be m= 440 ixed up.<br><br>>=C2=A0Versioning to indicate silent payments version 0<= 441 br>We should use the descriptor prefix to indicate the silent payments vers= 442 ion instead of the keys.<br><br>>=C2=A0A similar format to an xpub, the = 443 display of which is a common user interface element in many wallets, which = 444 makes things simpler for wallet developers and users alike<br>Things can be= 445 even simpler without the new key format.<br><br>From your original email:<= 446 br>> Finally, zero or more positive integers may be specified as further= 447 arguments to scan for additional BIP352 labels.<br>IIUC, this creates a de= 448 scriptor with a variable length. What if we encoded multiple labels in one = 449 number? For example, labels 1, 5, 10 are encoded into a 64-bit number by se= 450 tting the corresponding bit positions to '1' so that the final numb= 451 er is '1058'. Using one number to encode the labels is very appeali= 452 ng to me.<br><br>Kind regards,<br>Novo</div><br><div class=3D"gmail_quote g= 453 mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 4, = 454 2025 at 12:02=E2=80=AFPM Craig Raw <<a href=3D"mailto:craigraw@gmail.com= 455 ">craigraw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo= 456 te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= 457 );padding-left:1ex"><div dir=3D"ltr">Hi Novo,<div><br></div><div>Responses = 458 inline:</div><div><br></div><div>> I'm not sure adding a block heigh= 459 t does much to reduce scanning burden. We can already scan from the taproot= 460 activation height and it won't matter much anyway, because the chain w= 461 ill get longer and this only helps temporarily.</div><div><br></div><div>I&= 462 #39;m not sure I follow here. Since we need to retrieve and compute possibl= 463 e matching outputs for all eligible=C2=A0public keys in the chain, having a= 464 block height later than the Taproot activation date can make a significant= 465 difference, and will make a greater difference in future as the chain grow= 466 s.</div><div><br></div><div>> Is there any reason to add the birthday to= 467 the descriptor? Other descriptors do not do this.</div><div><br></div><div= 468 >The difference between this and other descriptors is that it cannot descri= 469 be outputs without reference to the blockchain. This, combined with the sig= 470 nificant=C2=A0computational burden=C2=A0which other descriptors do not have= 471 to bear, is reason enough I think to include it here as an optional argume= 472 nt.</div><div><br></div><div>> For example, we can set the maximum numbe= 473 r of labels in the bip; wallets will only have to scan for this max number = 474 of labels during recovery and if a wallet goes beyond this maximum number, = 475 they have gone beyond the bip and are now responsible for ensuring full rec= 476 overy of funds.=C2=A0</div><span style=3D"color:inherit"><div dir=3D"auto">= 477 <br></div><div>The problem with this approach is that scanning for each add= 478 itional label adds incrementally and non-trivially to the computational bur= 479 den. For each label, there is an EC point addition and comparison against a= 480 ll taproot outputs for an eligible transaction. Some benchmark numbers indi= 481 cating=C2=A0the relative cost of each additional label are in [1], demonstr= 482 ating that scanning for 100k labels is cost-prohibitive. As an aside, I wil= 483 l add that labels have a limited use case, and in most cases a new BIP44 ac= 484 count is a better choice for additional silent payment addresses based on t= 485 he same seed.</div><div><br></div><div>>=C2=A0<span style=3D"color:inher= 486 it">Given the above points, I argue that we don't need to introduce new= 487 scan and spend key formats, and we can use "sp(scankey,spendkey)"= 488 ;.</span></div><div dir=3D"auto"><br></div><div>While not strictly necessar= 489 y, using spscan and spspend=C2=A0key expressions=C2=A0make for a much bette= 490 r user experience and reduce the chance for user error. With this encoding = 491 we get:</div><div><ol><li>A self-describing format which makes the use and = 492 sensitivity of the key material immediately obvious</li><li>The advantages = 493 of Bech32m encoding, including strong error detection and unambiguous chara= 494 cters</li><li>Safety from accidentally mixing different unrelated scan and = 495 spend keys</li><li>Versioning to indicate silent payments version 0</li><li= 496 >A similar format to an xpub, the display of which is a common user interfa= 497 ce element in many wallets which makes things simpler for wallet developers= 498 and users alike</li></ol></div><div>--Craig</div><div><br></div><div>[1]:= 499 =C2=A0<a href=3D"https://delvingbitcoin.org/t/bip352-private-key-formats/20= 500 80/11" target=3D"_blank">https://delvingbitcoin.org/t/bip352-private-key-fo= 501 rmats/2080/11</a></div></span></div><br><div class=3D"gmail_quote"><div dir= 502 =3D"ltr" class=3D"gmail_attr">On Thu, Dec 4, 2025 at 11:39=E2=80=AFAM Oghen= 503 ovo Usiwoma <<a href=3D"mailto:eunovo9@gmail.com" target=3D"_blank">euno= 504 vo9@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= 505 le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= 506 ng-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Hi Craig, thank you for ta= 507 king this up. I have the following comments, based on a light inspection of= 508 your original email.</div><div dir=3D"auto"><br></div><div dir=3D"auto">&g= 509 t; In order to reduce the scanning burden, a block height may be optionally= 510 specified in the sp() expression as a second argument for a wallet birthda= 511 y.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'm not sure addi= 512 ng a block height does much to reduce scanning burden. We can already scan = 513 from the taproot activation height and it won't matter much anyway, bec= 514 ause the chain will get longer and this only helps temporarily.</div><div d= 515 ir=3D"auto"><br></div><div dir=3D"auto">Users can also specify a "wall= 516 et birthday" in their wallets which can be used for scanning. Is there= 517 any reason to add the birthday to the descriptor? Other descriptors do not= 518 do this.</div><div dir=3D"auto"><br></div><div dir=3D"auto">> Finally, = 519 zero or more positive integers may be specified as further arguments to sca= 520 n for additional BIP352 labels. The change label (m =3D 0) is implicitly in= 521 cluded.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In=C2=A0<a href= 522 =3D"https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-a= 523 nd-recovery" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/= 524 bip-0352.mediawiki#backup-and-recovery</a> , a strategy to recover funds fr= 525 om labels is specified. We can attempt to make this stronger and avoid the = 526 need to also include an integer for labels. For example, we can set the max= 527 imum number of labels in the bip; wallets will only have to scan for this m= 528 ax number of labels during recovery and if a wallet goes beyond this maximu= 529 m number, they have gone beyond the bip and are now responsible for ensurin= 530 g full recovery of funds.=C2=A0</div><div dir=3D"auto"><br></div><div dir= 531 =3D"auto">> In summary a new top level script expression sp() is defined= 532 , which takes as it's first argument one of two new key expressions:</d= 533 iv><div dir=3D"auto">- spscan1q... which encodes the scan private key and t= 534 he spend public key</div><div dir=3D"auto">- spspend1q... which encodes the= 535 scan private key and the spend private key</div><div dir=3D"auto"><br></di= 536 v><div dir=3D"auto">Given the above points, I argue that we don't need = 537 to introduce new scan and spend key formats, and we can use "sp(scanke= 538 y,spendkey)".</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'= 539 ;m happy to hear any counter arguments you have.</div><div dir=3D"auto"><br= 540 ></div><div dir=3D"auto">Novo</div><br><div class=3D"gmail_quote" dir=3D"au= 541 to"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Dec 2025, 12:40=E2=80= 542 =AFpm Craig Raw, <<a href=3D"mailto:craigraw@gmail.com" target=3D"_blank= 543 ">craigraw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo= 544 te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= 545 );padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>There is a = 546 practical need for a silent payments output descriptor format in order to e= 547 nable wallet interoperability and backup/recovery. There has been some prio= 548 r discussion on this topic [1][2] which this BIP proposal builds on:</div><= 549 div><br></div><div><a href=3D"https://github.com/bitcoin/bips/pull/2047" re= 550 l=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/204= 551 7</a></div><div><br></div><div>In summary=C2=A0a new top level script expre= 552 ssion sp() is defined, which takes as it's first argument one of two ne= 553 w key expressions:</div><div><ul><li style=3D"margin-left:15px">spscan1q...= 554 which encodes the scan private key and the spend public key</li><li style= 555 =3D"margin-left:15px">spspend1q... which encodes the=C2=A0scan private=C2= 556 =A0key and the spend private key</li></ul><div>The outputs may then be gene= 557 rated by combining this key material with the sender input public keys.=C2= 558 =A0</div></div><div><br></div><div>In order to reduce the scanning burden, = 559 a block height may be optionally specified in the sp() expression as a seco= 560 nd argument for a wallet birthday. Finally, zero or more positive integers = 561 may be specified as further arguments to scan for additional BIP352 labels.= 562 The change label (m =3D 0) is implicitly included.</div><div><br></div><di= 563 v>Examples:</div><div>sp(spscan1q...)</div><div>sp([deadbeef/352'/0'= 564 ;/0']spscan1q...,900000)</div><div>sp(spspend1q...,842579,1,2,3)</div><= 565 div>sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10)</div><di= 566 v><br></div><div>--Craig</div><div><br></div><div>[1]:=C2=A0<a href=3D"http= 567 s://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment-descrip= 568 tors" rel=3D"noreferrer" target=3D"_blank">https://btctranscripts.com/bitco= 569 in-core-dev-tech/2024-04/silent-payment-descriptors</a></div><div>[2]:=C2= 570 =A0<a href=3D"https://delvingbitcoin.org/t/bip352-private-key-formats/2080"= 571 rel=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/bip352-p= 572 rivate-key-formats/2080</a></div><div><br></div></div> 573 574 <p></p> 575 576 -- <br> 577 You received this message because you are subscribed to the Google Groups &= 578 quot;Bitcoin Development Mailing List" group.<br> 579 To unsubscribe from this group and stop receiving emails from it, send an e= 580 mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n= 581 oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b= 582 r> 583 To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= 584 bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail= 585 .gmail.com?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer" t= 586 arget=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65X= 587 aipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com</a>.<br><br> 588 </blockquote></div></div> 589 </blockquote></div> 590 </blockquote></div> 591 592 <p></p> 593 594 -- <br /> 595 You received this message because you are subscribed to the Google Groups &= 596 quot;Bitcoin Development Mailing List" group.<br /> 597 To unsubscribe from this group and stop receiving emails from it, send an e= 598 mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind= 599 ev+unsubscribe@googlegroups.com</a>.<br /> 600 To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/= 601 bitcoindev/CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y%2BGaGnKRCMv1kk3pKw%40mail.gma= 602 il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/= 603 msgid/bitcoindev/CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y%2BGaGnKRCMv1kk3pKw%40ma= 604 il.gmail.com</a>.<br /> 605 606 --000000000000e350350645bc1ebe-- 607