From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Dec 2025 03:07:57 -0800 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vR7Bj-0006S6-R1 for bitcoindev@gnusha.org; Thu, 04 Dec 2025 03:07:56 -0800 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7c75290862csf1902193a34.2 for ; Thu, 04 Dec 2025 03:07:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764846469; cv=pass; d=google.com; s=arc-20240605; b=eFVXKdDd9D1+hSwh/aPHvE83PRS+GR5O6ZNcX1X+ObujCqcV+hWwJ6jbHWzhhFW6hU mfuMM0zKpDALOdo6T+vtmV9q7kkoqKl5dLFIjytprUhPbYny46yPlcGCwmyC0MTmiKha iE64/Q+oJuY9RKdXHyx+di+tcQIPBpns+QCrlX3Vpu9U5+kypKWunRdIsiLWaRZc8e7L 3FjG7+ckSguZBXOa/0h3xneF974AnPJ73RGsKPv0T/TizIXxGNBlJXmfwRMHYWUFLR3b WcdeGTXzBJFkb4QwfOOi9y1NtHRgcLH6XiLXXQ4sXvYiDyZfbscup+/pLyy+ALE1mBrw 0gbg== 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=svwNs4xPh/MiRwYoZY8jKUJJfvZXajFqHPi2D7WwjDg=; fh=Nw63iEUxGvNYiZcrIXpFUY4juUBIN3l6NHm++D3grPI=; b=i2SFS+NWlK/OJE86eZ+ycH0zmaKKUxRJ3I6q+EiwUk+48NOvTM2SkzdY5nziTcHMsT 9hPP4wPJxowLa8qhMIatxFaubdGAkCJx5pixsPsAwafApnf48BTf3ps4/nc4WCEKneUq ct9MHMCJp/auPsgp9OTs2kh4oBTBB1mrb/ITQOogypofgQY20tF4POJ94onYLQKpp/Zb 7SXUQf0DeuCpKzLwGeHUWRwzqmYygFrhDniJUT08Kg+gD6O669AKJoEb9zSfPunanh+9 tuvYhhtKzeI7Ff+KHjZM1pbC+jHb+MJNS5VNWfSPy+iWiaifOMYZhNTc/rbddzrKXq62 GrPw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VQQFPwKH; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764846469; x=1765451269; 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=svwNs4xPh/MiRwYoZY8jKUJJfvZXajFqHPi2D7WwjDg=; b=JnPVthDvS5KXSpyYvp3hwIJPSjeFn3tv0hbZ7o7kjThMi0urq7y9JMDEgHi4kdliDI cYVvRDDjF0lxgV7u1TBDbhazthL/SKTjSN+Qee083imzAJ+FqH3uMd4aLbFtGP+Y2OHD 27Oig3mpVCL9HKVE4IZ+Dj3+zldeoiLY1YjcU47ETGN1auBZy6BuneAq0iUVaoMTF192 O2+RaB4RZQh1DS9sgjVSty0eojX08KC0BV5OnJ1EQfg81qzgh7Uzqiq48uw8T31Mw/aR XHc5suviJ2S8j/NLKeIpllufomMubOG8JmCNOwSOnIaukdzP17jbb7gBFua/hpt8o4lM zyAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764846469; x=1765451269; 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=svwNs4xPh/MiRwYoZY8jKUJJfvZXajFqHPi2D7WwjDg=; b=USrFkKiSZgglsdkaIBMGpiwC2w3++crnKDJNDCQ+PJMI4a4C3nNh/LQmNWo/2jGXbj 4iNif00WBRMZCUSL5YE93HSsDQHBP/4IU3Y6cIMX+2mjImTniLuc3BMz5lV7ErmmBwZN vNifS84m8eoog9msYfW9Jo2W1tuXfl08GF3LKkUPdLsFHlVUelP+zPV8SytAjrmrN64w kcuZGnRJRm4UJXlD2damkqoMHRMTperja833FSFc5ys+V+4k+ZgMe82lmXSvn8ECANb1 GFDlMKI99TUSFRSFxNEWsy5oIrQV7N9peSiEUjIsjnYFRklJ/Ae7dhvJd5undn6GRKIj +kOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764846469; x=1765451269; 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=svwNs4xPh/MiRwYoZY8jKUJJfvZXajFqHPi2D7WwjDg=; b=ZVq3EW0q5eqh+y9Dd/S/WasyeEpMJ1Wr5AkdqZjeBBjjNc6CUBECL7lggUMCWO8/0h sArUNnibO10oJiqM1jO26cT41nqiYquuy24WBHhz9IW4crOsM4KjwdNFimky1kIfVxti iV/Wv4GsUJKv/MouWddnB3G4wMXVu75Pz0l0aUgszfWCIcuGePrXlXh04o/wos95YHMF gAEQ8kjOQUFWj7VU2N1/jRKWINqF14L+d6nBZKCMIFNjvjajYlgyhgsSKPLWWlEfUmIR w6o3NW2N0JHCIkeHrlmPeG4YT86vMnYIj+ITLcBNVTZXjGtz6eY3je506cWQvCx+QtYC PV1g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWduJqu7mBbFDeRrz2sT0L4VkioWG5Bixq+LbsgmbXPZV/tV7/gQCRrXKRopnYSiPeG6lEuKErk3yM+@gnusha.org X-Gm-Message-State: AOJu0YyE1+D9icsLqAW2WnyNBjMLJ0igkl58g8nMqgZQ2ttY2vAoeLMo P0T+G5ZlXjybXfoV6wRqFqQZNnqaQ3LQzNwo3judUMUSnDoVeyBF3x7H X-Google-Smtp-Source: AGHT+IFxsfoYAueBVC9ekaUtSlm8xf97/NWNSDTlIylqN5wKEOgOERLM0i650RyiWcgrLg5ROwPj9w== X-Received: by 2002:a05:6830:254c:b0:7c7:51e4:1360 with SMTP id 46e09a7af769-7c958af595amr1498281a34.13.1764846469118; Thu, 04 Dec 2025 03:07:49 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aPpRHwSXtUDN36wvqssWSH0kOp2iDFmOuHudglpTECnw==" Received: by 2002:a05:6820:28c2:b0:657:7bb4:8279 with SMTP id 006d021491bc7-6597d0dc9dels276584eaf.1.-pod-prod-08-us; Thu, 04 Dec 2025 03:07:44 -0800 (PST) X-Received: by 2002:a05:6808:f87:b0:441:ca0e:f5ab with SMTP id 5614622812f47-45379e38c9amr1248880b6e.65.1764846464907; Thu, 04 Dec 2025 03:07:44 -0800 (PST) Received: by 2002:a05:6808:1d35:b0:44f:fe66:38a2 with SMTP id 5614622812f47-4515e4b2f98msb6e; Thu, 4 Dec 2025 03:02:47 -0800 (PST) X-Received: by 2002:a17:90b:3d8a:b0:347:5ddd:b2d1 with SMTP id 98e67ed59e1d1-34947f09f3fmr2734651a91.27.1764846166265; Thu, 04 Dec 2025 03:02:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764846166; cv=none; d=google.com; s=arc-20240605; b=DsWQOcfit9xyJak0M5Bteun6i1HHPmI/qPYdekoq99EPJk8xWdr8pWCcGbHpwKHR5A nmCkuLdGTgE27NAXrBAKVAnt/EBbkftE66G5m88qDsZHQOqho5iq1iLn+dB/N0S/IjIr Xm8b7U06cqngDyD9fo1rYCakdzBTPB+sjoLobzDi/Czv6N03FXZKKVR6oXY9xb5dFhO9 euiu5yArNl0XPn76kTlXsrw3ZWFCAjGn7Y63JqyFdpAM//D7b6GzPCewhZJh98ykxqDt 7vv027kW139ITt1/ibaarXO40so+Qv8Re7mYX/xEbp78MpwKkSPvPI8AnI6zYVfYvQ3G bSGg== 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=mem3R6LLUSeccPlbdY9szHVDA+E06qKDxc/eAXluQJ0=; fh=8iMi9Sc3WLBoiDx27193C05I/katw2V/VehSjA/vwxg=; b=K7YkMvXk2P2slOb8ZD1p5PuVlpdCCZlqmuhDRmScxlb3uqOjHmtXlGZey1JHnjRGw4 4fhN8vSktFwQrdiKOIwKulkPZRheaGdR3+J+VfNsKS17wgHd+QeNAjl0ou9/rfTBlBA8 04OSZsoW1fPR50cEGqoIgXoibr/zof8Hwf7LdypsxKjsJIhBQIeQWpSW8H1J+gC63dpg JIvJue3fhOR1I3Xif2sZpToRGHe0955lD6yYr7DGsM4R6zGcQiT2rhiTElXjrqsIEJPO ffG5HJ9dOCoBzL0febnAxGqMWsD7cOIbkwl2tZlagoiUqsX9rcsgIAQTjIthxZxLVmaY fqKA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VQQFPwKH; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com. [2607:f8b0:4864:20::f2d]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3494ea4f5b9si12616a91.3.2025.12.04.03.02.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Dec 2025 03:02:46 -0800 (PST) Received-SPF: pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) client-ip=2607:f8b0:4864:20::f2d; Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-88056cab4eeso5706116d6.2 for ; Thu, 04 Dec 2025 03:02:46 -0800 (PST) X-Gm-Gg: ASbGncv2HduJ9J5yZEkrrDJkxI43nGcMW5MPD7xyeu0JoAx4I4yjn8KHbYzE2sOjwcW RUg6L9vSJAWNsqzKm3bkezUxS7xSIUSvfhTk7RGMySHPU1gShkiHxFrKhRwcC8zwBtAbLdX8Bpw HSjNranyHvA4Tv0xtUdjHZyyXezmzF19rZljccI5vF7752E1TGTtqcCv/ZyS7oNFNqKoIJFiz8d KWDejYEAruNMbaTV9RbftKS2FFgNIaql53t+LJdhMRTA3bxOizn9HhxyEfHiIZS3OBvIgcgM9p2 JL1LDjdjJH7wTrozV329Yf/IV8fPeGnAlPddDDc9klayl9GaLkAhDBYoP589W13aO/8= X-Received: by 2002:ad4:5caa:0:b0:880:4f55:4af5 with SMTP id 6a1803df08f44-888248bc82bmr39333666d6.52.1764846165147; Thu, 04 Dec 2025 03:02:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Thu, 4 Dec 2025 13:02:33 +0200 X-Gm-Features: AWmQ_bmmz8jJQ01zX-Qfpz_U12hZdjCRp0vgl7VdVfEH-0l8ZGiXlcRL3ufCd2o Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 To: Oghenovo Usiwoma Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000c1c4fc06451e4421" X-Original-Sender: craigraw@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VQQFPwKH; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=craigraw@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --000000000000c1c4fc06451e4421 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 matter 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 possible matching outputs for all eligible public 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 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 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; 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 funds. 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 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 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 optionall= y > specified in the sp() expression as a second argument for a wallet birthd= ay. > > I'm not sure adding a block height does much to reduce scanning burden. W= e > 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 > 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 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 fund= s. > > > 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 k= ey > > 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, wrot= e: > >> Hi all, >> >> There is a practical need for a silent payments output descriptor format >> in order to enable wallet interoperability and backup/recovery. There ha= s >> 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 take= s >> 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 th= e >> 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 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) >> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7PT= %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/= CAPR5oBPH%3Dmbv4N3_4vuCcf%2BmDTCiT52WDb%3DqQ6KNuT%3D6Qr5tKA%40mail.gmail.co= m. --000000000000c1c4fc06451e4421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Novo,

Responses inline:
> I'm not sure adding a block height does much to reduc= e scanning burden. We can already scan from the taproot activation height a= nd it won't matter much anyway, because the chain will get longer and t= his only helps temporarily.

I'm not sure I fol= low here. Since we need to retrieve and compute possible matching outputs f= or all eligible=C2=A0public keys in the chain, having a block height later = than the Taproot activation date can make a significant difference, and wil= l make a greater difference in future as the chain grows.

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

The difference betw= een this and other descriptors is that it cannot describe outputs without r= eference to the blockchain. This, combined with the significant=C2=A0comput= ational burden=C2=A0which 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 b= ip; wallets will only have to scan for this max number of labels during rec= overy and if a wallet goes beyond this maximum number, they have gone beyon= d the bip and are now responsible for ensuring full recovery of funds.=C2= =A0

The problem with this approach is that scanning for each ad= ditional label adds incrementally and non-trivially to the computational bu= rden. For each label, there is an EC point addition and comparison against = all taproot outputs for an eligible transaction. Some benchmark numbers ind= icating=C2=A0the relative cost of each additional label are in [1], demonst= rating that scanning for 100k labels is cost-prohibitive. As an aside, I wi= ll add that labels have a limited use case, and in most cases a new BIP44 a= ccount is a better choice for additional silent payment addresses based on = the same seed.

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

While not strictly necessa= ry, using spscan and spspend=C2=A0key expressions=C2=A0make for a much bett= er 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 char= acters
  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 interf= ace element in many wallets which makes things simpler for wallet developer= s and users alike
--Craig


On Thu, Dec 4, 2025 at 11:39=E2=80=AFAM Oghenovo Usiwoma <eunovo9@gmail.com&= gt; wrote:
Hi Craig, thank you for taking this up. I ha= ve the following comments, based on a light inspection of your original ema= il.

> In order to red= uce 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 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.

=
Users can also specify a "wallet birthday"= ; in their wallets which can be used for scanning. Is there any reason to a= dd the birthday to the descriptor? Other descriptors do not do this.
<= div dir=3D"auto">
> Finally, zero or more pos= itive 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.mediawik= i#backup-and-recovery , a strategy to recover funds from labels is spec= ified. We can attempt to make this stronger and avoid the need to also incl= ude an integer for labels. For example, we can set the maximum number of la= bels in the bip; wallets will only have to scan for this max number of labe= ls during recovery and if a wallet goes beyond this maximum number, they ha= ve gone beyond the bip and are now responsible for ensuring full recovery o= f funds.=C2=A0

> In s= ummary 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 a= nd the spend private key

Given the above points, I argue that we don't need to introduce new sc= an and spend key formats, and we can use "sp(scankey,spendkey)".<= /div>

I'm happy to hear an= y counter arguments you have.

Novo

On Thu, 4 Dec 2025, 12:40=E2=80=AFpm Craig Raw, <= craigraw@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Hi all,

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


<= /div>
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 sc= an private key and the spend public key
  • = spspend1q... which encodes the=C2=A0scan private=C2=A0key and the spend pri= vate key
The outputs may then be generated by combining this = key material with the sender input public keys.=C2=A0

<= /div>
In order to reduce the scanning burden, a block height may be opt= ionally specified in the sp() expression as a second argument for a wallet = birthday. Finally, zero or more positive integers may be specified as furth= er 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...,9000= 00)
sp(spspend1q...,842579,1,2,3)
sp([deadbeef/352'= /0'/0']spscan1q...,900000,1,5,10)

--
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/CAPR5oBPH%3Dmbv4N3_4vuCcf%2BmDTCiT52WDb%3DqQ6KNuT%3D= 6Qr5tKA%40mail.gmail.com.
--000000000000c1c4fc06451e4421--