From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 12:33:11 -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 1vUsmD-0000Ys-MQ for bitcoindev@gnusha.org; Sun, 14 Dec 2025 12:33:11 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3ec7ae153fasf2295675fac.0 for ; Sun, 14 Dec 2025 12:33:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765744383; cv=pass; d=google.com; s=arc-20240605; b=g/bnobDFUd+bDHX76RL3aR0ClDgsW6g+ZkppfSNHOPPA3Bxd2FkvFJxc/PMpWRJr/z xq7IBwwxk18YKWoblGpO11ro/4y1kOZE10PFzITlinpeeN8cdi0ifGbgcvwP9+wyYnZk zBY9n9pjo6o6+f85GK6AaRMd6SGDI4x/nKF/OYeVUXg+GIBGWn4Uymd8wI4dkBkExhAH uG9FojPDKXpNPib9pSyxt+YIAnBHn1phjD5/zuCnQgD5zVXYqlanWAo9ZqX7BcPOTUwy MUVR/F3IQD18XwpkHAtBm4XqSwGczA9NJirw2cMBfwS7dOqbzYTk4S2gfuH3+VgYLx5A opNA== 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=N5r/o9yQ7vYTAEQxYksUvr5YKolr42j+o3CRjYzx7d8=; fh=HDzbF6El0TtMAnzVlA4vtRziExlax9XPv3N+4SJ+lrc=; b=Mqicglretexmh++64MGKgK1mCA0kDuuzGwR36jw3dK4eiWW53IOiJmUenmKZMk0T2V LnSJ7Sii7IuLc6Wjh4d2ThZPoH9JhPYp0xte9vSYZG7uHyxBGxVzzRvZb+KVp6EXnT26 zPmzPANrclz1h/Djf6YFwheDs73+geqKqDd/No5C6RgM8ETQVWrpW4EzPqTVZnSaHhdL DOn7JjqRfaZCCFJNkmhosCBXfhjMhQQpakkb5hY2iy2r+vC3b4Axcnp3xLZTCLjU/cB4 XbUeK+pZYp/2I5VmORHGUYjzZoPma8vdSwrcFVk5WKBUrQQkWjC25eyfcDik/FmNTa4J pdBw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VWh5Yutt; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82c 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=1765744383; x=1766349183; 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=N5r/o9yQ7vYTAEQxYksUvr5YKolr42j+o3CRjYzx7d8=; b=InncDLsFxs0igjdXARM+ZxRQgAkXF7MrIOXJdIV3GY8eeroYgFRI/QZXxrtwXIznK0 ZWz+HySFWDf+BHtaOoVNzXTfi2vY/FlnlmZc056G5EL185wrcy4CDtvc4IXQhPI+ia8o vh6ODblP/4NeInZFvO4YwV5szO8Z6xfC3HhusF2K+ub2gp3CkWQ8EECKXchD3hPCaTfB nFPyB69/ZEH98ElCKBlEtub6i4Dult0gNtlWMh3YvRdMY2lYB9MrZ0SWEaYZ932QQnY/ hH71bKH1Q8ci1/wY+x/uxxf8XxSq7jk5IKmOkDsCo33OqIEvUed04mgY4QvNgfLc3Q1q wxFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765744383; x=1766349183; 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=N5r/o9yQ7vYTAEQxYksUvr5YKolr42j+o3CRjYzx7d8=; b=hYbczbEnhPTytq3k4bC7X4qiMM7Qb9r6CtF+gaTlgapDjrlsR7fmU78KDm7uO81oV5 mppXgz17HeAQnLhybhTU8/+KM5k4vSW5S2KSgrlq1ymDHy2QwbsdsIBga7y/h1mSv9v5 fZsGCFPsejbLN62AfnD+eCHD++5/xSU+oGktUn/GOOXCswEWY2NAz8ZtfzoxF8OvBorH J4af+l2qht/YkaoLvzj81kPR/SKJgk8qfAzI+X3GgoljXkw7p9zl46PQ0BvomCAAGQs4 JMYNmFPOtwtlrsZvJQp+yem+10iyPmJ2MlZ2KXOErfH2zjC/VD78CPHxtXPc86+2cAnR 6GZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765744383; x=1766349183; 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=N5r/o9yQ7vYTAEQxYksUvr5YKolr42j+o3CRjYzx7d8=; b=vRsSaRr1hdYcIlt/JSJTxIoZim1WouOEPoNPYSRyyEQrrQcRSSnJYI0smOhjyaH9qX sHnoxWREKAO03pFK8kge+hPe7qRM/QYOoRUTiUxceWWiCAi5OkAiSshx2khXGX1RIG3q awTPwKEk3hwTiuIYXf7oUUARstGWDJTHHzCvYvbjH7NZVb3bnUEP+akrgHNhlT+l/a6j OV0Yp3LWRA8HFXNpVVD6C22rdPOanj8rQlD6YPhbTazQnObv77Si25JTL1th57hSRUlH I3HDCCbO52uSTf06/poyd19x8+bO7UKDWByFsRhlJpjrIUaOVJokuT2qCxJLFQ9BI/fB spGg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW+iRNSBfE1HQ7ZSy376r4KknRmQ/rrGZGB9kX9zQiKctyxTqVJF7jTlRQ1CzO/XgsfFtapMqYgEnvL@gnusha.org X-Gm-Message-State: AOJu0Yxqv8knxi+qXeTOyh4/MVmGA1pUcJMlO1siSiIGQIVpdXxZHWlQ 0KbGk5ifGjJaoYJUUfG0iJ8hrqVGtzBOSr2lV98rSt7gdvVIEn6qWTTA X-Google-Smtp-Source: AGHT+IHpDaOYhBDVGt4/s0Q2PatsoOixw1rfqk4FXS43e4xkdPZh6awSzsISMem2sSqxaR5lM9GLrw== X-Received: by 2002:a05:6820:228d:b0:659:9a49:90c7 with SMTP id 006d021491bc7-65b4520e538mr3698177eaf.70.1765744383486; Sun, 14 Dec 2025 12:33:03 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYug8smYkAOOi5U/PjhE+YhFT43HCaXSTZYjtvu4owjxw==" Received: by 2002:a05:6870:535b:10b0:3d4:d703:74d7 with SMTP id 586e51a60fabf-3f5f83d50f2ls741635fac.0.-pod-prod-02-us; Sun, 14 Dec 2025 12:32:58 -0800 (PST) X-Received: by 2002:a05:6808:144a:b0:441:8f74:f2b with SMTP id 5614622812f47-455ac953803mr3603444b6e.53.1765744378441; Sun, 14 Dec 2025 12:32:58 -0800 (PST) Received: by 2002:a05:6808:a597:20b0:450:d4ca:2ed2 with SMTP id 5614622812f47-455a77a595fmsb6e; Sun, 14 Dec 2025 12:30:31 -0800 (PST) X-Received: by 2002:a17:90b:3949:b0:34a:a1c1:90a0 with SMTP id 98e67ed59e1d1-34abd76f805mr6827922a91.28.1765744230132; Sun, 14 Dec 2025 12:30:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765744230; cv=none; d=google.com; s=arc-20240605; b=cgjqAwdGOE/hmpD8VKVaJIwoYBPl4EZKSb1RW2hWcBfSX7ktbpDpsd+YQ5AlrQwsSL dvXFK0Lsg0LfiIFRMeRRdzKHSkRaRUCYgk4pmdZ4Fvcq5JJrXZb0UGLDyouBuZ2mm9ue XWI045pi5lE++f6Wuq8s1JAh7VrZAjB4XgkVWs5vJOfaUBATnDJ2ZklpPu8ybtvuU2WE zxbOa9ExrHlyU+55E/8Sn3qEALl1mDouRHZ3+Kj7M+TNQ2nMBEhvRzrUcAKAgGDQ/AL0 eVWlndI/OuY0xJoti/TnBqSSH0eEeV3NJqOtlvPSMI7Q17u3CRRub+CK9VOkMPimN5u8 K+hg== 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=RFgk3EVfmGjYfTCdRoU5a8s+L1z6O85M/BByA1nlskU=; fh=Firs9aU8UUrTC2Il09j93tv/gVfId1RjWFRagBcPp9k=; b=e3j/1jDi3se6w2unhIm2P3RM2Yop3hBWzRJFsBPnKnsj7Q3Lf8NmyBmyG7EmEih7uX lccYH4t1WCOP1o1/WvCTET3rPcvBm9uLn/LzyvXn+/vZJXaYsjFapJxCKjJqpGRIAvGN vU3w1Gl976HWOLYQoImh+9l8sD9bgV/Dv7IGLeVxmHzHHRUH4AR+Mt1RbBMPHVhmdc1F qhhx8qEf+U4h/Z95pFtWvr2MbYANKkVo7Ru0GfMoDS5+A4IXQE4Av+PqqTj8V98WUYv3 ItyWwc7BWnbCfbKaZhqus8jEEHGcwJBjrgQC1lPvFlZRyCs4g5y56U0ljkMuT8aoHlIJ Zlag==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VWh5Yutt; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82c 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-x82c.google.com (mail-qt1-x82c.google.com. [2607:f8b0:4864:20::82c]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7f4c237f97dsi356683b3a.1.2025.12.14.12.30.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Dec 2025 12:30:30 -0800 (PST) Received-SPF: pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82c as permitted sender) client-ip=2607:f8b0:4864:20::82c; Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-4ee14ba3d9cso28860611cf.1 for ; Sun, 14 Dec 2025 12:30:30 -0800 (PST) X-Gm-Gg: AY/fxX6K59TQ+54dICCVJpKo09lqfMLaS8FcKxqCwRLgwY+5MRBC4UxfOqU29Nxmbkg 5idCr8efM2DacbonyxlSF4iS+FxgLYRExRPneMqfOb/JPnMkGwtEteBMn4fH/fXQrF/2hECyBZj nQ6Pu0D5HszQUd42PUXK/hOYG0FsHzANtQk0WFrcJIgB3hZWb6bYzItbuNizL6QLisON8j6r/kb DZ9AJi4By3+LmB0gI5H2yv07rbKp4VyivzuWZVHloKh7bKs9WtgPUxWXOE6gYKHwCC+2q1ZA9c= X-Received: by 2002:a05:622a:5c19:b0:4e8:a413:bb3a with SMTP id d75a77b69052e-4f1d059e41amr124260581cf.46.1765744228178; Sun, 14 Dec 2025 12:30:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Oghenovo Usiwoma Date: Sun, 14 Dec 2025 21:30:17 +0100 X-Gm-Features: AQt7F2qz6ukFX63Z6MmdnWVx-q4RByP1MCktH2IeK-cxohn5gE-5_jWPW0Lb4_w 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="0000000000007c1e0e0645ef5d8f" 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=VWh5Yutt; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::82c 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 (/) --0000000000007c1e0e0645ef5d8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Craig, > > 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. > Descriptors are generally of variable length, so I'm not sure why this is so appealing. Not only does this limit the range from 1 to 63, it has the added disadvantage of making this part of the descriptor unreadable to most humans. I was thinking about a descriptor with thousands of labels and I thought I could encode a large list of numbers into 64 bit number, but that=E2=80=99s impossible. Consider this idea, if we strictly increment the label by one, then just writing the max label, '10', in this example should be sufficient to tell the wallet to check for labels 1.. 10. The previous example used "1, 5, 10" as labels, but I'm not sure why we would we use label '1' and skip to '5', so writing just the max label should work? I'm still not in support of using new key formats for the descriptor, but I'll see if they receive popular support. Novo. On Fri, 12 Dec 2025, 10:18=E2=80=AFam Craig Raw, wrote= : > Hi Novo, > > Responses inline: > > > 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. > > Indeed, that is why it is an optional argument. Again however, other > descriptors do not have to bear the very significant computational overhe= ad > that sp() descriptors do. For many deployment contexts, this will > effectively make the birthday a requirement to retrieve all silent paymen= t > outputs in a wallet within a usable time frame. Other descriptors do not > share such a stark usability challenge. > > > 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). > > You are requiring the user to specify their master xprv in an output > descriptor, even for a watch-only wallet. This is a non-starter. Today, > output descriptors are often stored in clear text alongside a hardware > wallet or similar as privacy-sensitive but not directly security-sensitiv= e > information. > > > > 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. > > To the contrary, the use of output descriptors today means they are often > written down (sometimes into durable media). In this context, the > advantages of strong error detection and unambiguous characters are > significant. > > > > Safety from accidentally mixing different unrelated scan and spend ke= ys > > I'm not sure what the chance of this happening is.... If this is done > properly, then the keys should not be mixed up. > > It might also be done intentionally, with unexpected results. Regardless > of the cause, having one key expression discourages this. > > > We should use the descriptor prefix to indicate the silent payments > version instead of the keys. > > Indeed, silent payments version 1 may use a different script expression. > The versioning here is still useful though. > > > Things can be even simpler without the new key format. > > This is an unsubstantiated statement, suggesting that two key expressions > are somehow simpler than one. Again, it is simpler for wallet developers > and users to adapt to formats that are similar to those they are already > familiar with - and they are very familiar with xpubs. > > > 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 t= o > '1' so that the final number is '1058'. Using one number to encode the > labels is very appealing to me. > > Descriptors are generally of variable length, so I'm not sure why this is > so appealing. Not only does this limit the range from 1 to 63, it has the > added disadvantage of making this part of the descriptor unreadable to mo= st > humans. > > Best regards, > Craig > > On Fri, Dec 12, 2025 at 9:22=E2=80=AFAM Oghenovo Usiwoma > wrote: > >> 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 d= o >> 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 wall= ets >> 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 ke= y >> 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 key= s >> 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 w= rote: >> >>> 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 w= on't >>> matter much anyway, because the chain will get longer and this only hel= ps >>> temporarily. >>> >>> I'm not sure I follow here. Since we need to retrieve and compute >>> possible matching outputs for all eligible public keys in the chain, ha= ving >>> 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 grows. >>> >>> > 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 wi= th >>> the significant computational burden which other descriptors do not hav= e to >>> bear, is reason enough I think to include it here as an optional argume= nt. >>> >>> > 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 gon= e >>> beyond the bip and are now responsible for ensuring full recovery of fu= nds. >>> >>> The problem with this approach is that scanning for each additional >>> label adds incrementally and non-trivially to the computational burden.= For >>> each label, there is an EC point addition and comparison against all >>> taproot outputs for an eligible transaction. Some benchmark numbers >>> indicating the relative cost of each additional label are in [1], >>> demonstrating that scanning for 100k labels is cost-prohibitive. As an >>> aside, I will add that labels have a limited use case, and in most case= s 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 chanc= e >>> 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 fo= r >>> wallet 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 ma= tter >>>> 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-= and-recovery >>>> , a strategy to recover funds from 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 maximum number of labels in the bi= p; >>>> 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 go= ne >>>> beyond the bip and are now responsible for ensuring full recovery of f= unds. >>>> >>>> > 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 privat= e >>>> 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, w= rote: >>>> >>>>> Hi all, >>>>> >>>>> There is a practical need for a silent payments output descriptor >>>>> format in order to enable wallet interoperability and backup/recovery= . >>>>> There has 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 >>>>> optionally specified in the sp() expression as a second argument for = a >>>>> wallet birthday. Finally, zero or more positive integers may be speci= fied >>>>> 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) >>>>> sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10) >>>>> >>>>> --Craig >>>>> >>>>> [1]: >>>>> https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payme= nt-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, sen= d >>>>> an email to bitcoindev+unsubscribe@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW= 7PT%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/= CAOCjZ9QxuFK2-6pEKC9tgL%3DbThtF2RqxJV_T3MpKz-k084hHAA%40mail.gmail.com. --0000000000007c1e0e0645ef5d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Craig,

> > IIUC, this creates a descriptor with a variable length. What = if we encoded multiple labels in one number? For example, labels 1, 5, 10 a= re 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.

<= div dir=3D"auto">> Descriptors are generally of variable length, so I= 9;m not sure why this is so appealing. Not only does this limit the range f= rom 1 to 63, it has the added disadvantage of making this part of the descr= iptor unreadable to most humans.

I was thinking about a descriptor with thousands of labels and I = thought I could encode a large list of numbers into 64 bit number, but that= =E2=80=99s impossible.

C= onsider this idea, if we strictly increment the label by one, then just wri= ting the max label, '10', in this example should be sufficient to t= ell the wallet to check for labels 1.. 10. The previous example used "= 1, 5, 10" as labels, but I'm not sure why we would we use label &#= 39;1' and skip to '5', so writing just the max label should wor= k?


I'm still not in support of using new key formats for the descri= ptor, but I'll see if they receive popular support.

Novo.

On = Fri, 12 Dec 2025, 10:18=E2=80=AFam Craig Raw, <craigraw@gmail.com> wrote:
Hi Novo,

Responses inline= :

> However, without the birthday, the descript= or will still be able to describe its outputs. The birthday can be collecte= d through some other means, as we do with other descriptors today.

Indeed, that is why it is an optional argument. Again howe= ver, other descriptors do not have to bear the very significant computation= al overhead that sp() descriptors do. For many deployment contexts, this wi= ll effectively make the birthday a requirement to retrieve all silent payme= nt outputs in a wallet within a usable time frame. Other descriptors do not= share such a stark usability challenge.

> With= existing key formats, users and wallets will be able use their existing ma= ster key to generate silent payment outputs using a descriptor like: sp(<= ;master_key>/352h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0).
<= div>
You are requiring the user to specify their master xprv = in an output descriptor, even for a watch-only wallet.=C2=A0This is a non-s= tarter. Today, output descriptors are often stored in clear text alongside = a hardware wallet or similar as privacy-sensitive but not directly security= -sensitive information.

> > The advantages o= f Bech32m encoding, including strong error detection and unambiguous charac= ters
> I'm not sure these are strong enough to warrant new= key formats.

To the contrary, the use of output d= escriptors today means they are often written down (sometimes into durable = media). In this context, the advantages of strong error detection and unamb= iguous characters are significant.

> >=C2=A0= Safety from accidentally mixing different unrelated scan and spend keys
> I'm not sure what the chance of this happening is.... If th= is is done properly, then the keys should not be mixed up.

It might also be done intentionally, with unexpected results. Rega= rdless of the cause, having one key expression discourages this.
=
> We should use the descriptor prefix to indicate the sil= ent payments version instead of the keys.

Indeed, = silent payments version 1 may use a different script expression. The versio= ning here is still useful though.

> Things can = be even simpler without the new key format.

This i= s an unsubstantiated statement, suggesting that two key expressions are som= ehow simpler than one. Again, it is simpler for wallet developers and users= to adapt to formats that are similar to those they are already familiar wi= th - and they are very familiar with xpubs.

> I= IUC, this creates a descriptor with a variable length. What if we encoded m= ultiple 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.

Descriptors are ge= nerally of variable length, so I'm not sure why this is so appealing. N= ot only does this limit the range from 1 to 63, it has the added disadvanta= ge=C2=A0of making this part of the descriptor unreadable to most humans.

Best regards,
Craig

On Fri, Dec 12, 2= 025 at 9:22=E2=80=AFAM Oghenovo Usiwoma <eunovo9@gmail.com> wrote:=
Hi Craig,

I see how adding the birthday to the descriptor string c= ould 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 au= tomatically determine what height to start scanning from. However, without = the birthday, the descriptor will still be able to describe its outputs. Th= e birthday can be collected through some other means, as we do with other d= escriptors today.

I'm opposed to using new key formats because I= do not think we have enough justification to do so. With existing key form= ats, users and wallets will be able use their existing master key to genera= te silent payment outputs using a descriptor like: sp(<master_key>/35= 2h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0).

> A self-descr= ibing format which makes the use and sensitivity of the key material immedi= ately obvious
> The advantages of Bech32m encoding, including strong = error detection and unambiguous characters
I'm not sure these are st= rong enough to warrant new key formats.

>=C2=A0Safety from accide= ntally mixing different unrelated scan and spend keys
I'm not sure w= hat the chance of this happening is. We already have descriptors with multi= ple=C2=A0keys having complex relationships. Compared to those, the "sp= ()" is simple. Users are supposed to back up the entire descriptor str= ing. If this is done properly, then the keys should not be mixed up.
>=C2=A0Versioning to indicate silent payments version 0
We should us= e the descriptor prefix to indicate the silent payments version instead of = the keys.

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

From your original email:
> Finally= , zero or more positive integers may be specified as further arguments to s= can for additional BIP352 labels.
IIUC, this creates a descriptor with a= variable length. What if we encoded multiple labels in one number? For exa= mple, labels 1, 5, 10 are encoded into a 64-bit number by setting the corre= sponding 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 &l= t;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 Oghenovo Usiwoma <eunovo9@gmail.com> wrote:
Hi Craig, thank you for taking this up. I have the following co= mments, 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 a= s a second argument for a wallet birthday.

I'm not sure adding a block height does much to redu= ce scanning burden. We can already scan from the taproot activation height = and it won't matter 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=C2=A0https://github.com/bitcoin/bips/blob/master/bip-0352.mediaw= iki#backup-and-recovery , a strategy to recover funds from labels is sp= ecified. We can attempt to make this stronger and avoid the need to also in= clude 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 la= bels 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 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 the spend public k= ey
- 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, = <craigraw@gmail.com> wrote:
Hi all,

There is = a practical need for a silent payments output descriptor format in order to= enable wallet interoperability and backup/recovery. There has been some pr= ior discussion on this topic [1][2] which this BIP proposal builds on:


In summary=C2=A0a 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=C2=A0scan = private=C2=A0key and the spend private key
The outputs may th= en be generated 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 second argument for a wallet birthday. Finally, zero or more positive = integers may be specified as further arguments to scan for additional BIP35= 2 labels. The change label (m =3D 0) is implicitly included.

=
Examples:
sp(spscan1q...)
sp([deadbeef/352&#= 39;/0'/0']spscan1q...,900000)
sp(spspend1q...,842579,1,2,= 3)
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/CA= PR5oBNCd65XaipOF%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/CAOCjZ9QxuFK2-6pEKC9tgL%3DbThtF2RqxJV_T3MpKz-k084hHAA%40ma= il.gmail.com.
--0000000000007c1e0e0645ef5d8f--