From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 02:16:17 -0800 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vU0C8-0005Ak-9t for bitcoindev@gnusha.org; Fri, 12 Dec 2025 02:16:17 -0800 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-4538a8bc513sf1494263b6e.2 for ; Fri, 12 Dec 2025 02:16:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765534570; cv=pass; d=google.com; s=arc-20240605; b=Gc/0F9dM8E25X+k/mgX+M8lYSNIEcQXEzx5uBotWZ9SqQipU82opbg8jbMSBzmDZe7 lW/4IazTrAOub9LJgbXFzpm6oXpkI+sadyEWTo8AG9QLYAwyTsFq7XWRrlZ/eR2V+qh4 aG4zOYwhV9oP0TEFY2NZj8LXFCoEczNUcg/iElQdM43IT3k43d/GgXYSfzy4m6m4jbxO 8th1c8nbrOa4Zfdgfw6fnQkFmQdsFIPSNAUGrmjXg5PRd1xhjgTCu/saSOYkHJeZ4gyt X7fCWBW2XdsT1He5DPKLlAUBX4Qskl5osM0OCd33G4rKPopRl2qrt4v9mlz84lXjHPV0 /ILQ== 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:mime-version:user-agent:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:sender :dkim-signature; bh=igxoIavl1LB3zPV0ZtS0p/c3//j1SUZZffNMWy+0HEo=; fh=z4IluZpr0s1tIa43N82IF5OunF+SmsY57T3F+91AXh8=; b=GB5bBt9O9x2StIcJWCetSvKsZvORsEDxnBGfLpynWH+dfP7vhsaIxO/hvgz+ew9zm4 JjbXE2mz8FMshO0Br2DzgWE9op+nfnJ6HNw+WHkwTy0+SHH0kmJmY9BQjZ5Q+RoKbxrS PoMm53n4QYOC2t6KfjbWp+kY3WWC/UendnM/M0EMGDvJ0RcAaiG/cWjwP0BmONqxdpQg azoUs2CPhIhOwMQLrbDFGjE/3Gn4ViWRyERrehMEMy5Enh+5X9h7jhcMWKZuVmBwoFu1 Fz0WmF5C3oLIb4wJPOQilj5DjKn0REHl61moYJyzAL3x6k4v9+xXaEtZQr/w89cCzgZP oCIw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@pythcoiner.dev header.s=dkim header.b=IntuIB9K; spf=pass (google.com: domain of pyth@pythcoiner.dev designates 159.198.47.63 as permitted sender) smtp.mailfrom=pyth@pythcoiner.dev; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=pythcoiner.dev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765534570; x=1766139370; 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:mime-version:user-agent:autocrypt:references :in-reply-to:date:cc:to:from:subject:message-id:sender:from:to:cc :subject:date:message-id:reply-to; bh=igxoIavl1LB3zPV0ZtS0p/c3//j1SUZZffNMWy+0HEo=; b=SiFFyPv88+jWcEVpswzcT7cTmpoOe3/gKlEyJjXVNDupV7Gn6yrpfphZCxen0KFris zjbXrtHo4gY9o8xO1baGxxmDBcx9P7pzglFKsWYYQKhZgwK4g/amlrji+zounnxQiJKe sYoLfO9vuNpqXK4ahCVx0HeuRAeJjc3rVtRaASFknhitbPRcyRAYtYduV5k+/o4fH1Sl aiD+N+YPCwqSyhUyX/XzgJZoTEzq8/pTR01VmBLS0yXycQSD9aRDuLgQyL6S5E6fpgff 59m7lfKHxHL808Jb63qd9PKHq9RmE9PlZzMVlGrdAq8XbHPQ2BxwwL5P5ZMp5jmsrhtO 77rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765534570; x=1766139370; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:autocrypt:references :in-reply-to:date:cc:to:from:subject:message-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=igxoIavl1LB3zPV0ZtS0p/c3//j1SUZZffNMWy+0HEo=; b=ug1LjTRjAGCCjN029TyiCGrelyAYugaJXmfY1yWWS5KvQ5ZuxmZHs/ov6qs6FxikyV ylbTZKj8XD0Sj5pKFWA72fO08fREIwfou0UhkQZfMRrSLIFeo4BOAvUHldkzBUW4/M2M 4YE5xkOUnf6N6BE4cuQWVt2eW7+Lk4424P8YEwrKcdgMtNQu5dMTuO3rWs048GvmPrg9 mdyVfEQUmZwlZoNo1u5S7MJhNZYsS3Fu0RvNi4CzHU7SYgB/8xpOJgBUyfSKdWf5tGdR Vdw6c1F8AjlNbUQhC0plg8tNAf7jHrHQR6Pe+b6KCzlx6iyOji+zUrBv7P1qHUi53nLa 0Jug== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVzV7u+XnWYBjRvCxva4i1NDdRk1r/DUvVyc0V3f+Bnq87uGO/lyMXuwuMRr9K+hyGZC2wDSeh2TXI3@gnusha.org X-Gm-Message-State: AOJu0Yyn7V8AG3dccySwKEmAvlBaSGiW2TIHr5NjA6kviAI3EfBal+LK KTn2Xcj9BsjxGNSvXwUaGQbr2uc/mcX8gpGx+9X79VwQgY1gjAvNn1Aa X-Google-Smtp-Source: AGHT+IHe9BTiID6s6g46Gf/MTK/w17JPOEnpa1w0kM4yAbtABuIdxkUGwlegloBx+8x8k7+fx01ylw== X-Received: by 2002:a05:6870:649f:b0:3ec:71d3:66ae with SMTP id 586e51a60fabf-3f5f8cbd34emr927518fac.44.1765534569407; Fri, 12 Dec 2025 02:16:09 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbkRoR2w0CixAnRyE3lzINEnmmcUA0lKghMQ+fKi4TnBQ==" Received: by 2002:a05:6870:f10e:b0:3ea:9b4e:cb29 with SMTP id 586e51a60fabf-3f5f87f3f09ls249093fac.2.-pod-prod-08-us; Fri, 12 Dec 2025 02:16:05 -0800 (PST) X-Received: by 2002:a05:6808:2120:b0:450:1fcc:3a9d with SMTP id 5614622812f47-455ac965e71mr701516b6e.52.1765534565303; Fri, 12 Dec 2025 02:16:05 -0800 (PST) Received: by 2002:a05:620a:72b7:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8bb213138e1ms85a; Fri, 12 Dec 2025 01:08:29 -0800 (PST) X-Received: by 2002:ac8:58cb:0:b0:4e8:9920:be58 with SMTP id d75a77b69052e-4f1d01731admr15445321cf.0.1765530507995; Fri, 12 Dec 2025 01:08:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765530507; cv=none; d=google.com; s=arc-20240605; b=I4Mpv0eFMN/4QrJ4n9i9clmMWJ7cgoFqqKJ1sqHGLD/Jz4meyaVhVOdsZqFp/qF/mR hHngxovqfbd4lK3LSYHd7WabqQEE4/LFirhye71kCxTpUynrQk71qIUQTza3tpS0NDJK iFASPOIkzab/PdLPhNxWXwjdJKap7pJoLlT/8ervVGUqXu5nujgo7JBzoGYsS03uL8Pz C2l8PopZDMCcjOUciyk2kITym9ZS0WM8gBit+gMEtCRKJyAg0cxNYxq9fSiAqdZ+mIiF SwUnfD8t19yuTXLaKgjbqiKTpghcMYb1kZw90VRgQ10mD5OqRubV4lJV10bAfda7Eo8M Rj8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:user-agent:autocrypt:references:in-reply-to:date:cc:to :from:subject:message-id:dkim-signature; bh=59Jhk07IAhioZfCIg2Bkui5656jBWkY37ZL+qPTUdb0=; fh=DlWkb4UFI5kvCIWIQouipnnk+qQCivrTVaKDItPzsA4=; b=HqVGruMXMhTyjFZ6bsn6gWJWQKrP0LTcyiKI+iAx8HLgqCBKey/CEyweMF1W37qRvp 06Jy1ESMW/tXjys516Gr5JKGwFytuDM0DGkDDN7Lyz4mAynyD8lRhlD9KhvVxb8kpLo5 MKekBaxzd9eE4FzNWPK9dUSzppReD6ZCwN9ZvtS+Y63Lu65uHfSFRQkHBUce/wi8Tm+s +2wzsmEcBSHA4EG3Zfy7BELszpeA2nzySwf+dWecs7c482F7dwiUrjhg0UstNVaVhQt0 yzfl1MhiYFRULcRYOLSFhzhqxWZ6T7cHnfHgObL5SgbOz5+BXkZ+Y+DZk/+kZzT0j3IK 5F4g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@pythcoiner.dev header.s=dkim header.b=IntuIB9K; spf=pass (google.com: domain of pyth@pythcoiner.dev designates 159.198.47.63 as permitted sender) smtp.mailfrom=pyth@pythcoiner.dev; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=pythcoiner.dev Received: from mail.pythcoiner.dev ([159.198.47.63]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-4f1bcf9277fsi2661571cf.0.2025.12.12.01.08.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 01:08:27 -0800 (PST) Received-SPF: pass (google.com: domain of pyth@pythcoiner.dev designates 159.198.47.63 as permitted sender) client-ip=159.198.47.63; Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 65F10AAF9B; Fri, 12 Dec 2025 09:08:22 +0000 (UTC) Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352 From: pyth To: Oghenovo Usiwoma , Craig Raw Cc: Bitcoin Development Mailing List Date: Fri, 12 Dec 2025 10:08:17 +0100 In-Reply-To: References: Autocrypt: addr=pyth@pythcoiner.dev; prefer-encrypt=mutual; keydata=mQENBGPeZhkBCACy/b/DDJ+0VcFXxPyRS1arP+vKow9cIskZYj06mPa5pIVHFXKhfeYj+ KEhwYGOXA3NeT69uOM9cbsyfISN8eGCVWLYsWIDIf/MNvTCiVq2HAxkvolUiiiG8zmOwTpY8HA/gH 5RxEcmK9ex/cdsjvbilPBYFrHsNQ1Gz6WOmfNHkmxYCVnJ6FO6AY7b5XK1ImV9eDlLJIq/NWLy3vm jiyeWgShA+O6rK12C3IlPINck2YSTs/UjxdGQOCQscX71Oioua1ERzWDyR6zey7KPAeYUfZGXpgno wwnQHNhLotyH8+GEOD9M+2hW/I4Yo0652nZSWzeHN17OuWAk/ddd51nVABEBAAG0IVB5dGhjb2luZ XIgPHB5dGhjb2luZXJAcHJvdG9uLm1lPokBTgQTAQoAOBYhBFv6QEPDRHm0tlQ6QykmzXZ/TcCDBQ Jj3mYZAhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJECkmzXZ/TcCDJ54H/35PpgjmzE+Cl6j q9u8WAjreflqB4tzvbktdCvOkqWbGBtdkAKo54X9ZBQQkv2BqbjffUBvd+7EeUf+xnBr3qT//lPUY mXvkNoDpQxiamZ36XfGjFssK6ckEAYJUvSezwzkF6w+pkgOjuBgH0unr2nIfQwfSvfSDVFI0MFwYU MM0X2giVTEpfCKX8/B1u78FK8e794FBU1khHIxc/eh4lr0wOjj42TkIdaicTKvPDaXBs+AEONZ8KV 0YX0PqBMBkaJNgGIWGufu6iSbcBo3NAn+n+osE8JTUTj1TlpD10ZSvzePQuEmpIC9N3qgxuvh4ixP sFHcXiYCodMTix5EEfZo= Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-fgN59N2HCKZz3EpMxTZ9" User-Agent: Evolution 3.58.1 MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-Original-Sender: pyth@pythcoiner.dev X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@pythcoiner.dev header.s=dkim header.b=IntuIB9K; spf=pass (google.com: domain of pyth@pythcoiner.dev designates 159.198.47.63 as permitted sender) smtp.mailfrom=pyth@pythcoiner.dev; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=pythcoiner.dev 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.7 (/) --=-fgN59N2HCKZz3EpMxTZ9 Content-Type: multipart/alternative; boundary="=-tjlVZR+LgP/H481HK4p5" --=-tjlVZR+LgP/H481HK4p5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Novo, > The birthday can be collected through some other means, as we do with other descriptors today. Being on the wallet side, I'd like other descriptor type to have an **optional** field for the birthday, being forced to backup it separately is not the best design imho. Best, Pyth On Fri, 2025-12-12 at 08:22 +0100, Oghenovo Usiwoma wrote: > Hi Craig, >=20 > 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. >=20 > 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). >=20 > > 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. >=20 > >=C2=A0Safety 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=C2=A0keys having complex relationships. Compare= d > 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. >=20 > >=C2=A0Versioning to indicate silent payments version 0 > We should use the descriptor prefix to indicate the silent payments > version instead of the keys. >=20 > >=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. >=20 > 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. >=20 > Kind regards, > Novo >=20 > On Thu, Dec 4, 2025 at 12:02=E2=80=AFPM Craig Raw wr= ote: > > Hi Novo, > > Responses inline: > >=20 > > > 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. > >=20 > > I'm not sure I follow here. Since we need to retrieve and compute > > possible 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 grows. > >=20 > > > Is there any reason to add the birthday to the descriptor? Other > > descriptors do not do this. > >=20 > > The difference between this and other descriptors is that it cannot > > describe outputs without reference to the blockchain. This, > > combined with the significant=C2=A0computational burden=C2=A0which othe= r > > descriptors do not have to bear, is reason enough I think to > > include it here as an optional argument. > >=20 > > > 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.=C2=A0 > >=20 > > 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=C2=A0the 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. > >=20 > > >=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)". > >=20 > > While not strictly necessary, using spscan and spspend=C2=A0key > > expressions=C2=A0make 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 > >=20 > > [1]:=C2=A0 > > https://delvingbitcoin.org/t/bip352-private-key-formats/2080/11 > >=20 > > 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. > > >=20 > > > > 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. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > > 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. > > >=20 > > > In=C2=A0 > > > 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 funds.=C2=A0 > > >=20 > > > > 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 > > >=20 > > > 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)". > > >=20 > > > I'm happy to hear any counter arguments you have. > > >=20 > > > Novo > > >=20 > > > 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: > > > >=20 > > > > https://github.com/bitcoin/bips/pull/2047 > > > >=20 > > > > 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 then be generated by combining this key > > > > material with the sender input public keys.=C2=A0 > > > >=20 > > > > 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. > > > >=20 > > > > 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) > > > >=20 > > > > --Craig > > > >=20 > > > > [1]:=C2=A0 > > > > https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-pay= ment-descriptors > > > > [2]:=C2=A0 > > > > https://delvingbitcoin.org/t/bip352-private-key-formats/2080 > > > >=20 --=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/= d8fd5e1bda1b2241b14bd04f4c15b0d5570df223.camel%40pythcoiner.dev. --=-tjlVZR+LgP/H481HK4p5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Novo,

> The birthday can be collecte= d through some other means, as we do with other descriptors today.

B= eing on the wallet side, I'd like other descriptor type to have an **option= al** field for the birthday, being forced to backup it separately is not th= e best design imho.

Best,
Pyth

On Fri, 2025-12-12 at 08:22= +0100, Oghenovo Usiwoma wrote:
Hi Craig,

I see how adding the birthday to the descriptor stri= ng could be beneficial for anyone trying to use a third-party scanning serv= er; they will only have to submit the descriptor string, and the server wil= l automatically determine what height to start scanning from. However, with= out 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 oth= er 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 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 strong= enough to warrant new key formats.

> Safety from accidental= ly 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 do= ne properly, then the keys should not be mixed up.

> Version= ing to indicate silent payments version 0
We should use the descriptor p= refix to indicate the silent payments version instead of the keys.

&= gt; 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 d= evelopers and users alike
Things can be even simpler without the new key= format.

From your original email:
> Finally, zero or more pos= itive 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 posit= ions 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 <= ;craigraw@gmail.com> wrote:
Hi Novo,

<= div>Responses inline:

> I'm not sure adding a b= lock height does much to reduce scanning burden. We can already scan from t= he taproot activation height and it won't matter much anyway, because the c= hain will get longer and this only helps temporarily.

<= div>I'm not sure I follow here. Since we need to retrieve and compute possi= ble matching outputs for all eligible public keys in the chain, having= a block height later than the Taproot activation date can make a significa= nt difference, and will make a greater difference in future as the chain gr= ows.

> 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 desc= ribe outputs without reference to the blockchain. This, combined with the s= ignificant computational burden which other descriptors do not ha= ve to bear, is reason enough I think to include it here as an optional argu= ment.

> For example, we can set the maximum num= ber of labels in the bip; wallets will only have to scan for this max numbe= r 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 r= ecovery of funds. 

The problem with this approach is that scanning for each a= dditional label adds incrementally and non-trivially to the computational b= urden. For each label, there is an EC point addition and comparison against= all taproot outputs for an eligible transaction. Some benchmark numbers in= dicating the relative cost of each additional label are in [1], demons= trating that scanning for 100k labels is cost-prohibitive. As an aside, I w= ill 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 s= can and spend key formats, and we can use "sp(scankey,spendkey)".

While not strictly necessary, using sps= can and spspend key expressions make for a much better user exper= ience 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 e= ncoding, including strong error detection and unambiguous characters
    3. Safety from accidentally mixing different unrelated scan and spend keys
  3. Versioning to indicate silent payments version 0
  4. A similar f= ormat to an xpub, the display of which is a common user interface element i= n many wallets which makes things simpler for wallet developers and users a= like
--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 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 mu= ch to reduce scanning burden. We can already scan from the taproot activati= on height and it won't matter much anyway, because the chain will get longe= r and this only helps temporarily.

Users can also specify a "wallet birthday" in their wallets whic= h 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 s= pecified as further arguments to scan for additional BIP352 labels. The cha= nge label (m =3D 0) is implicitly included.
- s= pspend1q... 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 w= e 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 ne= ed 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:
In summary a new top level script expression sp() i= s defined, which takes as it's first argument one of two new key expression= s:
  • spscan1q... which encodes t= he scan private key and the spend public key
  • spspend1q... which encodes the scan private key and the spen= d 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 b= e optionally specified in the sp() expression as a second argument for a wa= llet 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']spsc= an1q...,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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/d8fd5e1bda1b2241b14bd04f4c15b0d5570df223.camel%40pythcoiner.dev.
--=-tjlVZR+LgP/H481HK4p5-- --=-fgN59N2HCKZz3EpMxTZ9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEaUDzTAAmS01IhXXCwQSK7t8wO4gFAmk724EACgkQwQSK7t8w O4gUXAf/fj9B0FfaGVfYmQh13lGNnhFkxslzw8DFOsozmBVLICGiq6jrLT9llEk9 qkEHBil4m7u98XrrqBsQlpD9bS1ZSRu8kZ9O3bWuY+r5KapkLHVe5TcUFdJ/ISsg k91aqxMA4nc4PU0O//wuCAUt1/nmRKMJ+JFiqoil0NtP2jLCpVxnqwhMimhStsD0 Q+WyVqGJDIMemQXaz4HkQyuRLBYyGAykUwP2PQpC4/5hpkTW/rA//mOqd2kwF8a8 5AqzvrRVf1sLWN4SKca8RxpXYbFf6ObzQpHGTaNaP97WMRM/GycVBmFOeeSJtbtr RmeU2IhF4q5dBBnqAjdBjlbV4Hh9Ag== =ZcxF -----END PGP SIGNATURE----- --=-fgN59N2HCKZz3EpMxTZ9--