From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Dec 2025 23:29:03 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vTxaI-0001Ff-Lp for bitcoindev@gnusha.org; Thu, 11 Dec 2025 23:29:03 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3f0d1a7a9c2sf620196fac.3 for ; Thu, 11 Dec 2025 23:29:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765524536; cv=pass; d=google.com; s=arc-20240605; b=I16sE46HFcZYZuFkwzMLrbZ+j+nxIGNZ9k+y0mD7fAfFvpPlq3qV8UiKAmhPzW2YEH m7x60IdjtMKfiMB4AxXW7Xm393owPTo/ZOOEqKrp4S+qG1K4dOjgJfjQZceM1YRKdZik OyTO4ooot1Fn+Jmr3QRn5JtjvArR42dKTG28kdDyYzgkLI1F74HgqUar9PAaFHInlYuW 7Q0xuW/34CVHEWRMk18UttN5PcqXnNzuiO8OIhy3yLXH/pL0/HAqHYTQKnSb5gtGM+dl 1B2jIThutg9CZYTCGTQhRAJXI1AfeHjuvZjEHtUtewB32/waW7+wlhydH7Subiu+Uelf Hg8Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 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=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; fh=UoEU8cVlz33nKjowm0374ldGdCZ+h5i6Yi7jP2UU6Ck=; b=UqqRH8iopCvC/Z0MQPK96K26Zb+ylBkCXLO7J8lrZunhkJwXf2gXYIgw8uYQ12unXM H3DdrMJ63/lwzVHd6AEo8pYsOzzXVlvz3LBV8QnwEYbgC40AYbcrAKasAtLYp39cEjJG KAe2RgeXFMi0jxtXeHORYfX9ooNtU0Om/N8IR/WLmwuFGnpp2lEq4DoSR9EImsnEpl43 diFjxYu6IGU9dY4TO+b127MW6CAMEGL/imE2A0TqYtXOnD2XhnGrD9du2pmi98MVOMgB YE30xmU+N1NQhHWNfbGoo0Bwnh417KTLXDk+xVwaKmEQEYgpUlYU/85cweX3VdW0VFHh rB+A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=eunovo9@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=20230601; t=1765524536; x=1766129336; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; b=KTsHUF3UPsbVBvWinBW/xvN4k7E++8kdgJzjnwqkh6sUJ32UJ3FWPUwrAh4vyjgFQ2 c7uQ+/6K44bQIlczu3GQaBaWS5K+A472j7IXM1vp9DkAkf1uAgk8oCzckpSkkt+RprIi Or/feqlXuUApynBXwIwXGaLgrN2f3Wnx7dTjJ2H4eLZn45ukQHhxbyZ4bmh9luRZm47d V5p2YUqBNh2VsOMS4+iE4DkPeXbVASruyphg/o4MNYybzpMnxFbH6/wAXzNRZy4Mq57Y tFF10BHgPBGwITHYyXLSOg7IBNi3UXKOaRwQEQ+Sbf0V8N+z4gFvFfX+I8oG9t50TszV lGWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765524536; x=1766129336; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; b=jqcLXxoQ/1eooblqC+jjgOhlIFl4HOYN0euxdrjMkNk5PnZXxICs3Zu4ySychgnP8l kYXAxbpcB+MaqJf155uDbNzwLBaAJCun4nTlr2knm1/qH4HgdghgSpSM5b7ubk1DvILy cHCH1g8x/eAD5YWWoNQgInYoaR5KAZiw7IilQhcVMix62dPAiXsXRxRJkCLl4v/BUuOg 4XLGlRCxFQ/uUK17glEbOCioT09OyIw+Sk2OCjh3aFWBd8V7xs6QB3Akv63RK3pDgAPZ PYbpAg119hGvYBdmyx+Xl2ffTEaQ9FWD83beybtD5HKhkcYFCF+U7RlTYdbuwVHUgm4B JWhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765524536; x=1766129336; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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; bh=hpyovdw64MDCgOAa8Rde+kr1DlsQMUpyUHd++IQRbok=; b=ArMfo05NVhGKV0MTSnjA0Qc5J2A6AxNPhxvhdadE/uydXOHqxgjJn9PfwvpUd+stdL j35UP2tmemqc5V299oKQsmFryDsTwvNkJNmeRS+BtFbUYD6bVUwmxqGsaYv9/OXNO6/3 mibLd8Rd5wK6Dk6ukpwn9e4obJGad/hgLOKdw/e4RxlZJi4MAeSLbjdzR4nn6deyr8GN dpsZ8eLFtIz50RoE2/zHGEwSEOsjNGcR9tUUEzVfnu58amaj4zHvl477jOcj5N9LWM+O vG6VzFDaMiAYoY1GSLDqX8aR56w4PZM9yV4byNtlBHy/MoAZgxQwNpvr4s/KkvbpulEv d51g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUF/77kKErBw5BD5UOfOQBTDB+KoASUBN1VXxcHAPS3+QpX2QV0/vDdav8IktjUKYn0st0zqY09ydgx@gnusha.org X-Gm-Message-State: AOJu0YxQcAui/sl+C1ZSz28XALwGZx28+J7EzKksBevwvQ5+EML8P+uV jINvWhSc9iI7nl+PPGl/UruQzClUpBsRxP794HHW+17H2lTNFyZCDHqH X-Google-Smtp-Source: AGHT+IG0NuWKSovRj9w+V3awJgy+6CfNSS7aFJrNXQUVIQ/AssEIYDydYOR9D7ETmLuhp1IadZqvjg== X-Received: by 2002:a05:6870:b60a:b0:3e8:3382:aaed with SMTP id 586e51a60fabf-3f5f8a0bc8emr605381fac.12.1765524535682; Thu, 11 Dec 2025 23:28:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYVPpsAbzQR0uHe6LrvgniG8H/BLLYORP5G/EA2qBKOfQ==" Received: by 2002:a05:6870:aa89:b0:3ec:5074:681b with SMTP id 586e51a60fabf-3f5f87f491els159079fac.2.-pod-prod-06-us; Thu, 11 Dec 2025 23:28:51 -0800 (PST) X-Received: by 2002:a05:6808:15a4:b0:43f:6979:6c9d with SMTP id 5614622812f47-455ac7f6afemr485308b6e.7.1765524531701; Thu, 11 Dec 2025 23:28:51 -0800 (PST) Received: by 2002:a05:6808:a5d2:10b0:44f:fe66:38a2 with SMTP id 5614622812f47-455a761a2c0msb6e; Thu, 11 Dec 2025 23:22:16 -0800 (PST) X-Received: by 2002:a05:6808:14c8:b0:450:1f44:d1ce with SMTP id 5614622812f47-455ac9d8385mr371362b6e.64.1765524135371; Thu, 11 Dec 2025 23:22:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765524135; cv=none; d=google.com; s=arc-20240605; b=CLcsblFB11kCoOFoahT77cDfGt7VJGFN2Bmhk6lIEwHyZd9nCBtwkpSGHC1rOAtLd4 tYZXq9aDVLPwI+wcY0IScBr0tvhQbkjz9ALpIMhUmB11OUOwlWY7Co9oHzyFZDT5HX9O SisWj82hiHGOVCTlO1QFmVLdlvGAoZbm2PhX1g4A68esF5ylJM8KtQ9IgMgLZL6you0F 2YkSrrlksoCAwFKoIGuodLFro8Of1AzwkAPh0n4yhw5UUU1DGK7hYbh9Bz3wm0zXmxgJ qDXs8fYRQHy2wTbF0PjZWvCZZzQJtwAKhhk4aNNdolI4Z/C8oU5DGCcu6Pk51uvU3/WU nU4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=pCQrhBKFkal6uzS5U3VEgjJP8zjmemnTb9JuoYZp3YE=; fh=Firs9aU8UUrTC2Il09j93tv/gVfId1RjWFRagBcPp9k=; b=g5dEIOkiFwT6VQ5YNvM76PD87VXt5TW3JiXPbHs3WiY1REvEbiZhYhueTwN0HYaPQA MjrFwg8tBSSU+G4FbpcEdXlkOUUmGeyK2ltrHrq0TrlDbcxPlgwvCwhJ2OzVkKG3/Lyf CgXWxA252dy3hGkcacWXrGwF7dB+960odcTqK/yRt+11bHMIS0BUPchE8bKAREfQP9ST VUty9G97q+btTt7t8UUlTKrIe9N46jB2Us1als6MGqo7jZmtBTxGw32YB3HynGmgVikU P4Vcs3cJr0JaBT7lBQ2wkMecZ+m51Ib4faKbxMuC11enEouOOeUqE62uHfGVwvgwXiKE q3ug==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=eunovo9@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com. [2607:f8b0:4864:20::82d]) by gmr-mx.google.com with ESMTPS id 5614622812f47-4559894fcb4si107590b6e.0.2025.12.11.23.22.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Dec 2025 23:22:15 -0800 (PST) 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; Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-4ee1879e6d9so10251131cf.1 for ; Thu, 11 Dec 2025 23:22:15 -0800 (PST) X-Gm-Gg: AY/fxX4hlTWJ9SIapTMQwPW5rIUEgNBJHGVYSUxq8OtHxgut1lhZjdCei5qM2YNDeiU SR6efG7Mdb6gd8RCg3EhNDD0A7FJrCTCFEofEEwKQ/BO3zldsY0BOBrpVk34fXeMKNQh0ioevkx gaEUVMtsvYpdEkwjOkTrety8U9doJjXNJ12yJM6pAnsIBefdKKPNXoegMa3tTDUHqBSMyuT4ahX 9zfYsgQVcyuLl8lAXE/Rcb2euv42qrf9iM2dBvezhZZaaMmt8FgzCMWnIX44JPzRB0B04x2 X-Received: by 2002:a05:622a:1aa5:b0:4f1:b956:6125 with SMTP id d75a77b69052e-4f1d04b9a79mr14429521cf.20.1765524134644; Thu, 11 Dec 2025 23:22:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Oghenovo Usiwoma Date: Fri, 12 Dec 2025 08:22:03 +0100 X-Gm-Features: AQt7F2pAwPyGg3a9wgaB5LbGoFEKm0y5ajIOrrNHkaePFavsjQujcFOtBombb-A Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 To: Craig Raw Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000e350350645bc1ebe" X-Original-Sender: eunovo9@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=QAAu1dGg; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=eunovo9@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 (/) --000000000000e350350645bc1ebe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig, I see how adding the birthday to the descriptor string could be beneficial for anyone trying to use a third-party scanning server; they will only have to submit the descriptor string, and the server will automatically determine what height to start scanning from. However, without the birthday, the descriptor will still be able to describe its outputs. The birthday can be collected through some other means, as we do with other descriptors today. I'm opposed to using new key formats because I do not think we have enough justification to do so. With existing key formats, users and wallets will be able use their existing master key to generate silent payment outputs using a descriptor like: sp(/352h/1h/0h/1h/0,/352h/1h/0h/0h/0). > A self-describing format which makes the use and sensitivity of the key material immediately obvious > The advantages of Bech32m encoding, including strong error detection and unambiguous characters I'm not sure these are strong enough to warrant new key formats. > Safety from accidentally mixing different unrelated scan and spend keys I'm not sure what the chance of this happening is. We already have descriptors with multiple keys having complex relationships. Compared to those, the "sp()" is simple. Users are supposed to back up the entire descriptor string. If this is done properly, then the keys should not be mixed up. > Versioning to indicate silent payments version 0 We should use the descriptor prefix to indicate the silent payments version instead of the keys. > A similar format to an xpub, the display of which is a common user interface element in many wallets, which makes things simpler for wallet developers and users alike Things can be even simpler without the new key format. >From your original email: > Finally, zero or more positive integers may be specified as further arguments to scan for additional BIP352 labels. IIUC, this creates a descriptor with a variable length. What if we encoded multiple labels in one number? For example, labels 1, 5, 10 are encoded into a 64-bit number by setting the corresponding bit positions to '1' so that the final number is '1058'. Using one number to encode the labels is very appealing to me. Kind regards, Novo On Thu, Dec 4, 2025 at 12:02=E2=80=AFPM Craig Raw wrot= e: > Hi Novo, > > Responses inline: > > > I'm not sure adding a block height does much to reduce scanning burden. > We can already scan from the taproot activation height and it won't matte= r > much anyway, because the chain will get longer and this only helps > temporarily. > > I'm not sure I follow here. Since we need to retrieve and compute possibl= e > matching outputs for all eligible public keys in the chain, having a bloc= k > height later than the Taproot activation date can make a significant > difference, and will make a greater difference in future as the chain gro= ws. > > > Is there any reason to add the birthday to the descriptor? Other > descriptors do not do this. > > The difference between this and other descriptors is that it cannot > describe outputs without reference to the blockchain. This, combined with > the significant computational burden which other descriptors do not have = to > bear, is reason enough I think to include it here as an optional argument= . > > > For example, we can set the maximum number of labels in the bip; wallet= s > will only have to scan for this max number of labels during recovery and = if > a wallet goes beyond this maximum number, they have gone beyond the bip a= nd > are now responsible for ensuring full recovery of funds. > > The problem with this approach is that scanning for each additional label > adds incrementally and non-trivially to the computational burden. For eac= h > label, there is an EC point addition and comparison against all taproot > outputs for an eligible transaction. Some benchmark numbers indicating th= e > relative cost of each additional label are in [1], demonstrating that > scanning for 100k labels is cost-prohibitive. As an aside, I will add tha= t > labels have a limited use case, and in most cases a new BIP44 account is = a > better choice for additional silent payment addresses based on the same > seed. > > > Given the above points, I argue that we don't need to introduce new > scan and spend key formats, and we can use "sp(scankey,spendkey)". > > While not strictly necessary, using spscan and spspend key > expressions make for a much better user experience and reduce the chance > for user error. With this encoding we get: > > 1. A self-describing format which makes the use and sensitivity of the > key material immediately obvious > 2. The advantages of Bech32m encoding, including strong error > detection and unambiguous characters > 3. Safety from accidentally mixing different unrelated scan and spend > keys > 4. Versioning to indicate silent payments version 0 > 5. A similar format to an xpub, the display of which is a common user > interface element in many wallets which makes things simpler for walle= t > developers and users alike > > --Craig > > [1]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080/11 > > On Thu, Dec 4, 2025 at 11:39=E2=80=AFAM Oghenovo Usiwoma > wrote: > >> Hi Craig, thank you for taking this up. I have the following comments, >> based on a light inspection of your original email. >> >> > In order to reduce the scanning burden, a block height may be >> optionally specified in the sp() expression as a second argument for a >> wallet birthday. >> >> I'm not sure adding a block height does much to reduce scanning burden. >> We can already scan from the taproot activation height and it won't matt= er >> much anyway, because the chain will get longer and this only helps >> temporarily. >> >> Users can also specify a "wallet birthday" in their wallets which can be >> used for scanning. Is there any reason to add the birthday to the >> descriptor? Other descriptors do not do this. >> >> > Finally, zero or more positive integers may be specified as further >> arguments to scan for additional BIP352 labels. The change label (m =3D = 0) is >> implicitly included. >> >> In >> https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-an= d-recovery >> , a strategy to recover funds from labels is specified. We can attempt t= o >> make this stronger and avoid the need to also include an integer for >> labels. For example, we can set the maximum number of labels in the bip; >> wallets will only have to scan for this max number of labels during >> recovery and if a wallet goes beyond this maximum number, they have gone >> beyond the bip and are now responsible for ensuring full recovery of fun= ds. >> >> > In summary a new top level script expression sp() is defined, which >> takes as it's first argument one of two new key expressions: >> - spscan1q... which encodes the scan private key and the spend public ke= y >> - spspend1q... which encodes the scan private key and the spend private >> key >> >> Given the above points, I argue that we don't need to introduce new scan >> and spend key formats, and we can use "sp(scankey,spendkey)". >> >> I'm happy to hear any counter arguments you have. >> >> Novo >> >> On Thu, 4 Dec 2025, 12:40=E2=80=AFpm Craig Raw, wro= te: >> >>> Hi all, >>> >>> There is a practical need for a silent payments output descriptor forma= t >>> in order to enable wallet interoperability and backup/recovery. There h= as >>> been some prior discussion on this topic [1][2] which this BIP proposal >>> builds on: >>> >>> https://github.com/bitcoin/bips/pull/2047 >>> >>> In summary a new top level script expression sp() is defined, which >>> takes as it's first argument one of two new key expressions: >>> >>> - spscan1q... which encodes the scan private key and the spend >>> public key >>> - spspend1q... which encodes the scan private key and the spend >>> private key >>> >>> The outputs may then be generated by combining this key material with >>> the sender input public keys. >>> >>> In order to reduce the scanning burden, a block height may be optionall= y >>> specified in the sp() expression as a second argument for a wallet >>> birthday. Finally, zero or more positive integers may be specified as >>> further arguments to scan for additional BIP352 labels. The change labe= l (m >>> =3D 0) is implicitly included. >>> >>> Examples: >>> sp(spscan1q...) >>> sp([deadbeef/352'/0'/0']spscan1q...,900000) >>> sp(spspend1q...,842579,1,2,3) >>> sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10) >>> >>> --Craig >>> >>> [1]: >>> https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment= -descriptors >>> [2]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080 >>> >>> -- >>> 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/CAPR5oBNCd65XaipOF%3DeXW7P= T%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.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/= CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y%2BGaGnKRCMv1kk3pKw%40mail.gmail.com. --000000000000e350350645bc1ebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Craig,

I see how adding the birthday to the desc= riptor string could be beneficial for anyone trying to use a third-party sc= anning server; they will only have to submit the descriptor string, and the= server will automatically determine what height to start scanning from. Ho= wever, without the birthday, the descriptor will still be able to describe = its outputs. The birthday can be collected through some other means, as we = do with other descriptors today.

I'm opposed to using new key fo= rmats because I do not think we have enough justification to do so. With ex= isting key formats, users and wallets will be able use their existing maste= r key to generate silent payment outputs using a descriptor like: sp(<ma= ster_key>/352h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0).

&g= t; A self-describing format which makes the use and sensitivity of the key = material immediately obvious
> The advantages of Bech32m encoding, in= cluding strong error detection and unambiguous characters
I'm not su= re these are strong enough to warrant new key formats.

>=C2=A0Saf= ety from accidentally mixing different unrelated scan and spend keys
I&#= 39;m not sure what the chance of this happening is. We already have descrip= tors with multiple=C2=A0keys having complex relationships. Compared to thos= e, the "sp()" is simple. Users are supposed to back up the entire= descriptor string. If this is done properly, then the keys should not be m= ixed up.

>=C2=A0Versioning to indicate silent payments version 0<= br>We should use the descriptor prefix to indicate the silent payments vers= ion instead of the keys.

>=C2=A0A similar format to an xpub, the = display of which is a common user interface element in many wallets, which = makes things simpler for wallet developers and users alike
Things can be= even simpler without the new key format.

From your original email:<= br>> Finally, zero or more positive integers may be specified as further= arguments to scan for additional BIP352 labels.
IIUC, this creates a de= scriptor with a variable length. What if we encoded multiple labels in one = number? For example, labels 1, 5, 10 are encoded into a 64-bit number by se= tting the corresponding bit positions to '1' so that the final numb= er is '1058'. Using one number to encode the labels is very appeali= ng to me.

Kind regards,
Novo

On Thu, Dec 4, = 2025 at 12:02=E2=80=AFPM Craig Raw <craigraw@gmail.com> wrote:
Hi Novo,

Responses = inline:

> I'm not sure adding a block heigh= t does much to reduce scanning burden. We can already scan from the taproot= activation height and it won't matter much anyway, because the chain w= ill get longer and this only helps temporarily.

I&= #39;m not sure I follow here. Since we need to retrieve and compute possibl= e matching outputs for all eligible=C2=A0public keys in the chain, having a= block height later than the Taproot activation date can make a significant= difference, and will make a greater difference in future as the chain grow= s.

> Is there any reason to add the birthday to= the descriptor? Other descriptors do not do this.

The difference between this and other descriptors is that it cannot descri= be outputs without reference to the blockchain. This, combined with the sig= nificant=C2=A0computational burden=C2=A0which other descriptors do not have= to bear, is reason enough I think to include it here as an optional argume= nt.

> For example, we can set the maximum numbe= r of labels in the bip; wallets will only have to scan for this max number = of labels during recovery and if a wallet goes beyond this maximum number, = they have gone beyond the bip and are now responsible for ensuring full rec= overy of funds.=C2=A0
=
The problem with this approach is that scanning for each add= itional label adds incrementally and non-trivially to the computational bur= den. For each label, there is an EC point addition and comparison against a= ll taproot outputs for an eligible transaction. Some benchmark numbers indi= cating=C2=A0the relative cost of each additional label are in [1], demonstr= ating that scanning for 100k labels is cost-prohibitive. As an aside, I wil= l add that labels have a limited use case, and in most cases a new BIP44 ac= count is a better choice for additional silent payment addresses based on t= he same seed.

>=C2=A0Given the above points, I argue that we don't need to introduce new= scan and spend key formats, and we can use "sp(scankey,spendkey)"= ;.

While not strictly necessar= y, using spscan and spspend=C2=A0key expressions=C2=A0make for a much bette= r user experience and reduce the chance for user error. With this encoding = we get:
  1. A self-describing format which makes the use and = sensitivity of the key material immediately obvious
  2. The advantages = of Bech32m encoding, including strong error detection and unambiguous chara= cters
  3. Safety from accidentally mixing different unrelated scan and = spend keys
  4. Versioning to indicate silent payments version 0
    5. A similar format to an xpub, the display of which is a common user interfa= ce element in many wallets which makes things simpler for wallet developers= and users alike
--Craig


On Thu, Dec 4, 2025 at 11:39=E2=80=AFAM Oghen= ovo Usiwoma <euno= vo9@gmail.com> wrote:
Hi Craig, thank you for ta= king this up. I have the following comments, based on a light inspection of= your original email.

&g= t; In order to reduce the scanning burden, a block height may be optionally= specified in the sp() expression as a second argument for a wallet birthda= y.

I'm not sure addi= ng a block height does much to reduce scanning burden. We can already scan = from the taproot activation height and it won't matter much anyway, bec= ause the chain will get longer and this only helps temporarily.

Users can also specify a "wall= et birthday" in their wallets which can be used for scanning. Is there= any reason to add the birthday to the descriptor? Other descriptors do not= do this.

> Finally, = zero or more positive integers may be specified as further arguments to sca= n for additional BIP352 labels. The change label (m =3D 0) is implicitly in= cluded.

In=C2=A0https://github.com/bitcoin/bips/blob/master/= bip-0352.mediawiki#backup-and-recovery , a strategy to recover funds fr= om labels is specified. We can attempt to make this stronger and avoid the = need to also include an integer for labels. For example, we can set the max= imum number of labels in the bip; wallets will only have to scan for this m= ax number of labels during recovery and if a wallet goes beyond this maximu= m number, they have gone beyond the bip and are now responsible for ensurin= g full recovery of funds.=C2=A0

> In summary a new top level script expression sp() is defined= , which takes as it's first argument one of two new key expressions:
- spscan1q... which encodes the scan private key and t= he spend public key
- spspend1q... which encodes the= scan private key and the spend private key

Given the above points, I argue that we don't need = to introduce new scan and spend key formats, and we can use "sp(scanke= y,spendkey)".

I'= ;m happy to hear any counter arguments you have.
Novo

On Thu, 4 Dec 2025, 12:40=E2=80= =AFpm Craig Raw, <craigraw@gmail.com> wrote:
Hi all,

There is a = practical need for a silent payments output descriptor format in order to e= nable wallet interoperability and backup/recovery. There has been some prio= r discussion on this topic [1][2] which this BIP proposal builds on:
<= div>

In summary=C2=A0a new top level script expre= ssion sp() is defined, which takes as it's first argument one of two ne= w key expressions:
  • spscan1q...= which encodes the scan private key and the spend public key
  • spspend1q... which encodes the=C2=A0scan private=C2= =A0key and the spend private key
The outputs may then be gene= rated by combining this key material with the sender input public keys.=C2= =A0

In order to reduce the scanning burden, = a block height may be optionally specified in the sp() expression as a seco= nd argument for a wallet birthday. Finally, zero or more positive integers = may be specified as further arguments to scan for additional BIP352 labels.= The change label (m =3D 0) is implicitly included.

Examples:
sp(spscan1q...)
sp([deadbeef/352'/0'= ;/0']spscan1q...,900000)
sp(spspend1q...,842579,1,2,3)
<= div>sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10)

--Craig


--
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.google.com/d/msgid/bitcoindev/CAPR5oBNCd65X= aipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.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/CAOCjZ9SCrFqXaejbZRg3OTd4sCHG7KB2Y%2BGaGnKRCMv1kk3pKw%40ma= il.gmail.com.
--000000000000e350350645bc1ebe--