From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Dec 2025 02:12:03 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vR6Je-0005WD-3o for bitcoindev@gnusha.org; Thu, 04 Dec 2025 02:12:02 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3e89d22a84fsf480657fac.2 for ; Thu, 04 Dec 2025 02:12:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764843116; cv=pass; d=google.com; s=arc-20240605; b=fm5nAYMCGUsrxU+hDzz1A0/35OYiRKeEspJWiVRwwFfV9wO5wMFJ1/4NwBHm9NSgD3 lF3Oc9a/FCyinW5Ti9O/uZF8uJ+KSoaRbtMzktVDGbO5uDiH5URGC1hEhmdJy0OQIfBQ knBHcb+NskJN3Ci/8FYKY8+WQy1V1fIEJbzXJ003pMnv1nz354aE1Rjkkx746eegg+7F DmWzRkXpvU7iMJWG7k8X7yAUz8Ba64fOBCwmeSM4+qJpMC2gFycUmJpfmk4ujZj2uyx7 OM9sx5vsdKZAw+FWpaQWQyzVQYbKUxzOYSfNYPsUjQXpRllrytktUuRSh2VhtsQaPjl6 QJVA== 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=UorXEbSlOXIQMthONvPrLk0jxiiBDl+fmjR2cQdG1aw=; fh=FkQ2sykhZKF40OYcfuLP3KDSuWf7by8CNy535OuSv2Q=; b=bdHE1rNp+Lp+QZcd6yJGdpze0yVv9TsqSBUNB9+T7+JrzKMqZbKN+4Jmg4fSQklfzw ZEcDUKY/xfx2W6ZAWGttRM9rWzjpyKRDPj9e7XCCIiV6bfkicZ2Vu89RzYnZx3Z2a1Re eP8DO/4CsPmLqJfRpYiqhirQAAJLMtfYG8MPY8/ly/fbxfIe6I7QQtlGu8jK8xDWyeJC VzKIZPVfxAocNDV7Guy0aN6zuU349ewgWTOWopNSXGrFpX+GAZs93fpGr2aU/styi/Wf 64nimu1m6jKde8vZ3mXlTZUPtSWW/LhX043k4SeqfVyQp0cjER9o9nUoG5XPI2HsPIzp IfYA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DpPVVk2Z; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::834 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=1764843116; x=1765447916; 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=UorXEbSlOXIQMthONvPrLk0jxiiBDl+fmjR2cQdG1aw=; b=NurKSOTZ6Xd5QVAN43uIYLVGbyKmO+UQMXCkSNj4aJ1FQoOkkNT4idliEtuByMvzrh E4JrZ2EMh+gj+zAuGeKJaWASIZ5zuLproR4AB4iXDXQDSRd2CRcZoXmhBOJtX4wMyCcY 8f8HWh5DKiBKi+mR9jrfTQH7HLqhDGkmboXx33L0iCghFtwMnzovnXGrsyuZbBSBg4u9 TK+U9NSElOX+Ayk3NXEvKkXiybFXj1SJ9nXNCakV/kcKZPkl421kaiprkjMgS27Ye3cD 3++yf2+Yr/5sGWrdWCgksNtLqe7oVadFH2e4UEcBD0hLfDqOzgtOnFGNjhRuH6LV/ZSP J6mg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764843116; x=1765447916; 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=UorXEbSlOXIQMthONvPrLk0jxiiBDl+fmjR2cQdG1aw=; b=DeXK0e59qqGNJV/b3J0BXQZjpaAtlmXewKcPlZSuuWAb4K6DriGyJV+sWBLRSNk5Tn ECUfY5H3Cfg6g0tz5GtL3k2DkbD6owZKwCa9eBkcsDvTo2LP1xO3KHeCv50h4y9HfGgQ TLgMrjw2uwMuOHDsXdVjat4ilW5n6c/L+VUmNoR/dxnrJRzb3xU3rOBOHU0z9fR3JuDM 6ocUuQ4KSBt9t9OXGFyJFWf38FDDfTkIIYalJftLRDtBdv89gOXoIjB9SdunqFrxT2au m3gk61EWQc/+2f8gpF+1zEo5GWchWD/UTpQB9pAg07ZOzitrylda2gXU84yeK+AtOA1M snPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764843116; x=1765447916; 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=UorXEbSlOXIQMthONvPrLk0jxiiBDl+fmjR2cQdG1aw=; b=DQbzLy9btz/E9Y8+G58vV7aUHLJBhwQXaJKZJFBzpXDV2XuhhLV9xmNar6jAnHDTRb vdtxmDx9JXt9/BGEE5Ana4nVnurhD8WIPSTr0pF7qi0Flcfvw+YtmsAPY2r+9P1LvjD0 EWZVG2mXc5a3A6ypt5MIciem4z8Vq6a1e/jrmoTke49QwL6io8wYGQgHuf9nlu+ZJmIf VlLLSqQqMUV+GLMPXzvtlXh6Hje15Lijg5wmLrd2Ih/GXuv8WvpPGBEQUumA6LEp81ox B0MJnF19UlKLe8UvPw+TGDlI1wewDK1lgN9hlAGAWb+EHzZ6JD+e0kf+FqRVdWhOAFB/ avNg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUq0Z/fgAaEU8fx/UrQ4Jo2QKFMvtQz9sqx2JmMK8S9KewP6EEWEjpx3FcKLktpkhIzsHJZaCN/vzco@gnusha.org X-Gm-Message-State: AOJu0YzOvcFv3WDHHK5PrsUl6DtMGJdmu/sihV36h5KT4r2+A/3jmCVf qi3Mh7WoZAKQ2ay8qb5MRRMuiBjEGTow88VcbsrDEkUNf/JOooC3ny7T X-Google-Smtp-Source: AGHT+IG27r9MpYD/dEAwurq0kxb25xRgqT5wd+B3abkyNJOCnOLjB1uR+9prTZZg+/sSRmRcEcoo+g== X-Received: by 2002:a05:6870:200b:b0:3ec:5e8e:87fc with SMTP id 586e51a60fabf-3f169366f57mr4060581fac.31.1764843115422; Thu, 04 Dec 2025 02:11:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bEKBaPK52W+XeZuk+mbQtCIpS58dQd5I7z+kHKtYnBKQ==" Received: by 2002:a05:6871:60c9:b0:3ec:406d:5582 with SMTP id 586e51a60fabf-3f50905c75els346571fac.2.-pod-prod-04-us; Thu, 04 Dec 2025 02:11:51 -0800 (PST) X-Received: by 2002:a05:6808:4fe7:b0:44d:a531:456 with SMTP id 5614622812f47-4536e56cd85mr3048441b6e.52.1764843111276; Thu, 04 Dec 2025 02:11:51 -0800 (PST) Received: by 2002:a05:6808:1d35:b0:44f:fe66:38a2 with SMTP id 5614622812f47-4515e4b2f98msb6e; Thu, 4 Dec 2025 01:39:07 -0800 (PST) X-Received: by 2002:a05:6a21:3d86:b0:364:783:8c0f with SMTP id adf61e73a8af0-36407839469mr1435295637.33.1764841146011; Thu, 04 Dec 2025 01:39:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764841146; cv=none; d=google.com; s=arc-20240605; b=V0tdyGEiWvYynFG5rrAaWd1NGqDDpX/AGS+LopDbVZ/jF5DnllBSm0unn3+8LaIqov ZQRwNesgXFVZpdnX7qPQdRgTnxEbGBFnlHYSVxewux7yPtzN0oku+rInTLu8Gyw5BBzQ X2bEH7mNwOxaRA0nU3Q6W3K9/+ZdGwrXS9MOCvcTyUByg1yF7aZxC89/PRIKqItMYGqt a27Qmr/O+S5zZL+1Ck0rWAi0YeFvYqBVQ68aG0Evz+iDLkTtD6fHvCuW8zWN6KdSilTd vxoCtmHjW13K/hdIjKZx+8gb9i/krVw2+Nai23F7tVjOxJZGG5Ku7cl4h/1zn2AEWNR9 shZQ== 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=nTBH1unMYKvI1v7t1PeG37tbjhomQUT49LFVY1WXvvs=; fh=Firs9aU8UUrTC2Il09j93tv/gVfId1RjWFRagBcPp9k=; b=gWOeZx68eUKVsRdlSwCOTOeF5beomV8mvWz8ftNee13D57GoG1XgpNkgwnfz5GP47/ HVxlcZMJTPDFI+haToSIGd93QPbN/P1i737wjONemVmsxv+XQVmmilNoHIHnBZYc4OGW i5q8eRJc44PQp8DsNds7H4lufm6QfQsWZFA+wdmzPiFH913FM5XSf8xqAs/6DAojFO2t w+xntv4XoGkpqVFHCDpXgpIp6nHbhIJpm400eluT4l6vjYVX+8quMUy8qE0csM3JTd7H pro2/ERcBsR0fIAYXgDw7yEM7Ly9M5sUQO+BVfaQ1MINzA2lo4djy3mcDFL21IXTXah3 /I6w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DpPVVk2Z; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::834 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-x834.google.com (mail-qt1-x834.google.com. [2607:f8b0:4864:20::834]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-bf6a0a629ebsi31224a12.3.2025.12.04.01.39.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Dec 2025 01:39:05 -0800 (PST) Received-SPF: pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::834 as permitted sender) client-ip=2607:f8b0:4864:20::834; Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-4edb6e678ddso10184271cf.2 for ; Thu, 04 Dec 2025 01:39:05 -0800 (PST) X-Gm-Gg: ASbGncsu7EoDTjZQaB5J2aOyC8aueNu++EPlYz140JNu+k7d5+xeR6uGpI90emaSbxi wzZVOMiJ2NuJsbLO7vnIYsf6kcG0rnrMweBQoCVILgHvNeO5wmmmcFCSb3Ruvlz0nmQkedhjypy gkwOcNaCRVjXUtRkKNxrbFI52J7SMF+GbgxLX67w5ZStJzhXhx5C6cWrq7U5KwD0Go2g3wRd1Iy P+HP+IZC35r8ILZiad1J05RrDI3uZ4MByg+f4lnvyQTAARfNelqpXAQXMLibDGNH6isqEj9 X-Received: by 2002:a05:622a:84:b0:4ee:208a:fbef with SMTP id d75a77b69052e-4f017592a71mr77524381cf.14.1764841144916; Thu, 04 Dec 2025 01:39:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Oghenovo Usiwoma Date: Thu, 4 Dec 2025 13:38:48 +0400 X-Gm-Features: AWmQ_bmTQ_1oGr_qHnJbj_0QVsmaJku8bBXeA34y6PQDDxk6DF9zc7H2WAuM_SA 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="000000000000871f8906451d1910" 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=DpPVVk2Z; spf=pass (google.com: domain of eunovo9@gmail.com designates 2607:f8b0:4864:20::834 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 (/) --000000000000871f8906451d1910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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-r= ecovery , 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 funds. > 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 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, 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 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 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-d= escriptors > [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%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/= CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww%40mail.gmail.com. --000000000000871f8906451d1910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Craig, thank you for taking this up.= I have the following comments, based on a light inspection of your origina= l email.

> In order t= o 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 he= ight does much to reduce scanning burden. We can already scan from the tapr= oot activation height and it won't matter much anyway, because the chai= n will get longer and this only helps temporarily.
<= br>
Users can also specify a "wallet birthday&q= uot; in their wallets which can be used for scanning. Is there any reason t= o 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 additio= nal BIP352 labels. The change label (m =3D 0) is implicitly included.
=

In=C2=A0h= ttps://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-and-re= covery , a strategy to recover funds from labels is specified. We can a= ttempt 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 recov= ery 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<= /div>

> In summary a new to= p level script expression sp() is defined, which takes as it's first ar= gument 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 p= rivate key

Given the abo= ve points, I argue that we don't need to introduce new scan and spend k= ey formats, and we can use "sp(scankey,spendkey)".

I'm happy to hear any counter arg= uments you have.

Novo
On Thu, 4 Dec 2025, 12:40=E2=80=AFpm Craig = Raw, <craigraw@gmail.com> w= rote:
Hi all,
=
There is a practical need for a silent payments output descr= iptor 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:


In summary=C2=A0a = new top level script expression sp() is defined, which takes as it's fi= rst argument one of two new key expressions:
  • spscan1q... which encodes the scan private key and the spend= public key
  • spspend1q... which encodes t= he=C2=A0scan private=C2=A0key and the spend private key
The o= utputs may then 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 m= ore positive integers may be specified as further arguments to scan for add= itional BIP352 labels. The change label (m =3D 0) is implicitly included.

Examples:
sp(spscan1q...)
sp([d= eadbeef/352'/0'/0']spscan1q...,900000)
sp(spspend1q..= .,842579,1,2,3)
sp([deadbeef/352'/0'/0']spscan1q...,9= 00000,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/ms= gid/bitcoindev/CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww%40mail.g= mail.com.
--000000000000871f8906451d1910--