From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 02:16:40 -0800 Received: from mail-ot1-f56.google.com ([209.85.210.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vU0CV-0005Az-4i for bitcoindev@gnusha.org; Fri, 12 Dec 2025 02:16:40 -0800 Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-7c70546acd9sf1783917a34.3 for ; Fri, 12 Dec 2025 02:16:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765534593; cv=pass; d=google.com; s=arc-20240605; b=azam7fTPB8fysf6PCdJOivVunXrDPX9eiXws3IMQ2Z/RrbjXwuUyMf3scEqAsi5Jm3 lm7xx75dPp0IaFlQ6S/nDrGiVnKqE+uztql7IdsSnLOGOR8i8CuxRYcde/yK7Fc9AdKj cRdyKBAbzDOnIMS+MEXWvy7sARw9AORFerIeXMLrtEB6Su+Icvg0hHvExa2l/YEtgaEH rSjHASWXvSOY5zkUSQmakrmopWbcGECAG+baxF8ZAv9IyAgDkiOZnAswgzPoQBoCxxvr TYORMLie+EeNbBU0j1daDnioQP+2SDQBBSjLTo4NiLK8i0HnHKAo2UX/YOKL5UD5Abji yK2g== 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=NVIJIsC9uS1RBFiMrrxvOtfqja6g7HdvFATfGPvJn/s=; fh=4BfBuXh/ZDD9OYpMpjZEmAD82cl1dDl4rysdiyHmGAg=; b=JarQ6KbrpqXhUR7Y1vAD5F8/X7LvtVzxaT1dNTsr9hI/FMcI/h5LsT3y0MB8ChWBJ1 7uWQ8sl0aolxm1rVV0yY5YwTAkBTggWE1TRvCdnywlyIbfOJj/m+IOm2gmfLKN33K2x/ E8MrLKjYPWuF3gzDJaUz4zehD/eKIgKUbznpMCrG2PAGU+KZw/h2EaKTOeqondGS0zMH TH0gwfACXoBwk5x3EXp6MpS3oGAzcZNVC0/gwNQtWC+Df0K43yz/RnkqmHsxQGD/oAPz AjPxCr1sgaH9isya3GFNCKvL2NFhoPiQyhHPdWFMrEx4PHHg5xpwSNvlip/2uhjveVRq bqZQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=XL5FmPjs; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f29 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=1765534593; x=1766139393; 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=NVIJIsC9uS1RBFiMrrxvOtfqja6g7HdvFATfGPvJn/s=; b=OA7CpOnWn2Wa1NvDINqlLfH+aCQGoXNYzRVlAJUMJvPa+7SsR2WTK/+Y0VBMTwBbBv KeK6PRt0XyMMODVKJwj2fgyfpiQXS0Xnl+xX3d8fGbBt4NAXJtWdZZACB+TUd7I6WIDY ZYbyUxg4WzeieF+5fUduiEbAQbWF8hdhAJAI/GyZzjffQku+6UngQARbdsZ2DbCYRaid pe+75qb4kkMr1UMG83qszIWwwyQUaSeJ5N+pq7l9hh6+e2Hc5LYEqyX+e3ddlCps+xpz G8Mh108HwuUC/YYlhgalbog/13UTc3VGJz22Qxj50eDBEFZ5yW4OWsOZnScw0rp8GDL7 MLAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765534593; x=1766139393; 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=NVIJIsC9uS1RBFiMrrxvOtfqja6g7HdvFATfGPvJn/s=; b=moh8aeE/uNLER1RfTjcaQtCeXeT5ZOfocuecHBYLmA6H3Uwfe6/tElzFF9KhQP7hpW g7ydDUneuAPzYwSNqj+lwjNhg+oaPM16PhVzX14MwGisMd21X8dtJIiHSM3oa9rKTc6M zv4BEf/qD3vW3Kh/TjlHtrfCf+T2J55FMoDja9Vj0CPDPkl7HiMAthThUw+xyKkk14QM jrSTcpmRdbeGuXq2BkIm/84cKiA3riGq5fTRdO4UHVVsGG13reJOw3bok1HDnMI4BXH1 EokOme5Vu/3fjHA72x58vssk1I4yo/FmZXll07lYSZ94kdHmXXP7bAoGK6BBEhJqzosU qXbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765534593; x=1766139393; 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=NVIJIsC9uS1RBFiMrrxvOtfqja6g7HdvFATfGPvJn/s=; b=jefhNAlt8BxjLvnX2YWDl9ydAT5x0wzSCk/RZeeif90+fs4lv+idm/j/fiPhwNCaL3 RWggno2QaaxbHYfIhYRzKP9AqFX+cmt7KbfGBKm3hYO/kUuS5vbADD44pD/+zK+pxlm3 LKwjVF0VdgLQif4XbA54YGfZG890mCXxZ/zU3+uCt5dZ+hUaQlGKfCWxnUmy+S32o2C1 wN5OcM49DX9pl5ccO0U5DOoLxH3vc3QUERa5++6kn9TgdKnkQjo/3MnwWjcn/cPs3d9I UkI4WRA0rFKJ59MSF3g9S0/QbluxFmIRyF6rSpCb+RxOumLUnaZWxJdCLoUrEbv+gzqe ZxIw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUVSrwsfm/Y2rRGfX7sWVSZwEjlIyclDTIK+/kH0fR1rBOLQ64aHX4x+oC6k6+VIzlfxT0Leea8VI21@gnusha.org X-Gm-Message-State: AOJu0YwcqKqrPZuObaiFUgjm3byUNGvhyVZntfb7yxA3/EaQhPex/fHY KzYXFqDbZqzj51WzD8wM9LSEOuC65/S/1NtyNPZ6EwvYwSbzx2PXWaIH X-Google-Smtp-Source: AGHT+IFjuw+Getz6jKQo52DzSD2AMdtN7rBrURQS7X2i6Gvp8d9WVt8u38sRKZFaQ40XpBV8GN761Q== X-Received: by 2002:a05:6870:a408:b0:3e1:474b:beb3 with SMTP id 586e51a60fabf-3f5f8a9c24dmr729492fac.17.1765534592253; Fri, 12 Dec 2025 02:16:32 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWaMTYBRKE7+FTDWrE8DsnH24y00lGznxlkOcMAxWvckTA==" Received: by 2002:a05:6870:f10e:b0:3ea:9b4e:cb29 with SMTP id 586e51a60fabf-3f5f87f3f09ls249231fac.2.-pod-prod-08-us; Fri, 12 Dec 2025 02:16:28 -0800 (PST) X-Received: by 2002:a05:6808:1597:b0:450:abd0:d815 with SMTP id 5614622812f47-455ac84c2a0mr536553b6e.28.1765534588576; Fri, 12 Dec 2025 02:16:28 -0800 (PST) Received: by 2002:a05:620a:99b:b0:892:e292:65ef with SMTP id af79cd13be357-8bb21333399ms85a; Fri, 12 Dec 2025 01:18:36 -0800 (PST) X-Received: by 2002:a05:6214:c6c:b0:880:4f55:4af5 with SMTP id 6a1803df08f44-8887e7d5547mr21270716d6.52.1765531116036; Fri, 12 Dec 2025 01:18:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765531116; cv=none; d=google.com; s=arc-20240605; b=NKYFadclTwMVVEkOGqU+YkaswjlJa11Mbu2NBwr6spPbtk+tovgtlSh6v/3zDuoGdU gawxraWhF4LbRzYhnFeqxskxJjtlbsvGkfcveE43Y7tEZ7aAwD8IfEINrRCBKNt87aHY t/9HXcvwKbI3SJczhRrFs1braSqrN8AViKYwcaMUqu9QpCybRPYlIrcJ3r9MX1oKjz2H 71bDPqlyX8O8FXoWxVny2naYKhGSSNvwYV5eQfd2RkcUKQhNNDoxrwGfPx4eOvZEPCHG cSzHuksATqF2MDaM7kngHi1SsEAjRRZPhy5AYpukaAQh/qB+7zGjU9Hcer0Q21LR8s7J klUw== 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=VvqIt5CgQDVc7tzf2IYIsKa6/jsbImyzIaU5xQl+NWE=; fh=8iMi9Sc3WLBoiDx27193C05I/katw2V/VehSjA/vwxg=; b=BX3s0vjUWF2vzR4S/fqZ/2qT9+K/0D6tQ/2gn6f9d7pEHS05BAt/4NFXZ9bEEnw2PM P7VZpvIBz9cZUQc+BnewBQ6xwV+yRdhbntpabPtlhZk4go8XCT5iT3HQuQvaY2A+G3B2 J4hokzYKJpORsFYwz6Ug9Q7/gNNuTNFmXdwG273kOVOED32s0QW4Dr7niTOCkHN961KG wdLw9CUDaySG8iBWftKuN5XoLS6zCvyFZoBOVp/fPn2EKxzjoTaPtdLBKlTODbV9J1JI ToUag3xWtztTpyuqKRkYCr/iKKsdXgN8deWOqAnoHcGApWvAOJ+5tM6l+FfKpOZsLeWY VH2g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=XL5FmPjs; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f29 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-xf29.google.com (mail-qv1-xf29.google.com. [2607:f8b0:4864:20::f29]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8888180bbf9si247796d6.2.2025.12.12.01.18.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 01:18:36 -0800 (PST) Received-SPF: pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) client-ip=2607:f8b0:4864:20::f29; Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-88859a63001so6156776d6.0 for ; Fri, 12 Dec 2025 01:18:36 -0800 (PST) X-Gm-Gg: AY/fxX4y4sf81+riVXLYc4Ga1cV+4LFq4kwj97zhXnCuTeR/FGvIzda9oerp3595Z+Q 7B8q13ECpU20QJctrfNy7Jbd3Nq+6o8D/fseol4tM+WiiPb6o4aqy3pSQvdGGz6X4eX0NBrSNjU h8rQgRQXniF1GzNFDm3VCPuYURCWRnpzEHxARUNK0PvuY/cphUMvapZZD4PFHvIvoAqhJUdW0OV lT2yxOB9geNzF86zLv/Pqj0GLXuvBYZdVmj65YBheWbZN9OY545QvWL/k2kV7GvrQYFBlSJJsPe FWfM+gAmtyroLx+QWrwDjyVJOInn9lZV1B1rgAfS2pi3UDwi/hZYWqeIHg== X-Received: by 2002:a05:6214:4a8f:b0:882:6d1a:eacc with SMTP id 6a1803df08f44-8887e7f9a51mr18826406d6.57.1765531115375; Fri, 12 Dec 2025 01:18:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Fri, 12 Dec 2025 11:18:24 +0200 X-Gm-Features: AQt7F2rpfrNSFuUmcXzlKmRo6IPFnB_IGAY_VGS8AiPPZ2pjHO-mjNuBYjh824w 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="000000000000f8ceb90645bdbe5a" 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=XL5FmPjs; spf=pass (google.com: domain of craigraw@gmail.com designates 2607:f8b0:4864:20::f29 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 (/) --000000000000f8ceb90645bdbe5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 overhead that sp() descriptors do. For many deployment contexts, this will effectively make the birthday a requirement to retrieve all silent payment 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-sensitive 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 keys > 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 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. 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 beneficia= l > for anyone trying to use a third-party scanning server; they will only ha= ve > to submit the descriptor string, and the server will automatically > determine what height to start scanning from. However, without the > birthday, the descriptor will still be able to describe its outputs. The > birthday can be collected through some other means, as we do with other > descriptors today. > > I'm opposed to using new key formats because I do not think we have enoug= h > justification to do so. With existing key formats, users and wallets will > be able use their existing master key to generate silent payment outputs > using a descriptor like: > sp(/352h/1h/0h/1h/0,/352h/1h/0h/0h/0). > > > A self-describing format which makes the use and sensitivity of the key > material immediately obvious > > The advantages of Bech32m encoding, including strong error detection an= d > unambiguous characters > I'm not sure these are strong enough to warrant new key formats. > > > Safety from accidentally mixing different unrelated scan and spend keys > I'm not sure what the chance of this happening is. We already have > descriptors with multiple keys having complex relationships. Compared to > those, the "sp()" is simple. Users are supposed to back up the entire > descriptor string. If this is done properly, then the keys should not be > mixed up. > > > Versioning to indicate silent payments version 0 > We should use the descriptor prefix to indicate the silent payments > version instead of the keys. > > > A similar format to an xpub, the display of which is a common user > interface element in many wallets, which makes things simpler for wallet > developers and users alike > Things can be even simpler without the new key format. > > From your original email: > > Finally, zero or more positive integers may be specified as further > arguments to scan for additional BIP352 labels. > IIUC, this creates a descriptor with a variable length. What if we encode= d > 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 wr= ote: > >> 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 matt= er >> 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, hav= ing >> 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 wit= h >> the significant computational burden which other descriptors do not have= to >> bear, is reason enough I think to include it here as an optional argumen= t. >> >> > For example, we can set the maximum number of labels in the bip; >> wallets will only have to scan for this max number of labels during >> recovery and if a wallet goes beyond this maximum number, they have gone >> beyond the bip and are now responsible for ensuring full recovery of fun= ds. >> >> The problem with this approach is that scanning for each additional labe= l >> adds incrementally and non-trivially to the computational burden. For ea= ch >> label, there is an EC point addition and comparison against all taproot >> outputs for an eligible transaction. Some benchmark numbers indicating t= he >> relative cost of each additional label are in [1], demonstrating that >> scanning for 100k labels is cost-prohibitive. As an aside, I will add th= at >> 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 wall= et >> 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 mat= ter >>> 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 b= e >>> 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-a= nd-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 gon= e >>> beyond the bip and are now responsible for ensuring full recovery of fu= nds. >>> >>> > 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 sca= n >>> 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, wr= ote: >>> >>>> 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 B= IP >>>> 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 specif= ied >>>> 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-paymen= t-descriptors >>>> [2]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+unsubscribe@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7= PT%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/= CAPR5oBNX5oyzVJcWH9FDMOXE7q2MaZgSHX_LtCnOu%3DdcW9D70w%40mail.gmail.com. --000000000000f8ceb90645bdbe5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 des= criptors do not have to bear the very significant computational overhead th= at sp() descriptors do. For many deployment contexts, this will effectively= make the birthday a requirement to retrieve all silent payment 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 ge= nerate silent payment outputs using a descriptor like: sp(<master_key>= ;/352h/1h/0h/1h/0,<master_key>/352h/1h/0h/0h/0).

=
You are requiring the user to specify their master xprv in an output d= escriptor, even for a watch-only wallet.=C2=A0This is a non-starter. Today,= output descriptors are often stored in clear text alongside a hardware wal= let or similar as privacy-sensitive but not directly security-sensitive inf= ormation.

> > The advantages of Bech32m enco= ding, including strong error detection and unambiguous characters
> I'm not sure these are strong enough to warrant new key formats.<= /div>

To the contrary, the use of output descriptors tod= ay means they are often written down (sometimes into durable media). In thi= s context, the advantages of strong error detection and unambiguous charact= ers are significant.

> >=C2=A0Safety from ac= cidentally mixing different unrelated scan and spend keys
> I&= #39;m not sure what the chance of this happening is.... If this is done pro= perly, then the keys should not be mixed up.

It mi= ght 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 v= ersion instead of the keys.

Indeed, silent payment= s version 1 may use a different script expression. The versioning here is s= till useful though.

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

This is an unsubstan= tiated statement, suggesting that two key expressions are somehow simpler t= han one. Again, it is simpler for wallet developers and users to adapt to f= ormats that are similar to those they are already familiar with - and they = are very familiar with xpubs.

> IIUC, this crea= tes 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 numb= er by setting the corresponding bit positions to '1' so that the fi= nal number is '1058'. Using one number to encode the labels is very= appealing to me.

Descriptors are generally of var= iable length, so I'm not sure why this is so appealing. Not only does t= his limit the range from 1 to 63, it has the added disadvantage=C2=A0of mak= ing this part of the descriptor unreadable to most humans.

Best regards,
Craig

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

I see ho= w adding the birthday to the descriptor string could be beneficial for anyo= ne trying to use a third-party scanning server; they will only have to subm= it the descriptor string, and the server will automatically determine what = height to start scanning from. However, without the birthday, the descripto= r will still be able to describe its outputs. The birthday can be collected= through some other means, as we do with other descriptors today.

I&= #39;m opposed to using new key formats because I do not think we have enoug= h justification to do so. With existing key formats, users and wallets will= be able use their existing master key to generate silent payment outputs u= sing a descriptor like: sp(<master_key>/352h/1h/0h/1h/0,<master_ke= y>/352h/1h/0h/0h/0).

> A self-describing format which makes th= e use and sensitivity of the key material immediately obvious
> The a= dvantages of Bech32m encoding, including strong error detection and unambig= uous characters
I'm not sure these are strong enough to warrant new = key formats.

>=C2=A0Safety from accidentally mixing different unr= elated scan and spend keys
I'm not sure what the chance of this happ= ening is. We already have descriptors with multiple=C2=A0keys having comple= x relationships. Compared to those, the "sp()" is simple. Users a= re supposed to back up the entire descriptor string. If this is done proper= ly, then the keys should not be mixed up.

>=C2=A0Versioning to in= dicate silent payments version 0
We should use the descriptor prefix to = indicate the silent payments version instead of the keys.

>=C2=A0= A similar format to an xpub, the display of which is a common user interfac= e element in many wallets, which makes things simpler for wallet developers= and users alike
Things can be even simpler without the new key format.<= br>
From your original email:
> Finally, zero or more positive int= egers may be specified as further arguments to scan for additional BIP352 l= abels.
IIUC, this creates a descriptor with a variable length. What if w= e encoded multiple labels in one number? For example, labels 1, 5, 10 are e= ncoded into a 64-bit number by setting the corresponding bit positions to &= #39;1' so that the final number is '1058'. Using one number to = encode the labels is very appealing to me.

Kind regards,
Novo
On T= hu, Dec 4, 2025 at 12:02=E2=80=AFPM Craig Raw <craigraw@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hi Novo,<= div>
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 muc= h 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=C2=A0publi= c keys in the chain, having a block height later than the Taproot activatio= n date can make a significant difference, and will make a greater differenc= e in future as the chain grows.

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

The difference between this and other descrip= tors is that it cannot describe outputs without reference to the blockchain= . This, combined with the significant=C2=A0computational 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 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 resp= onsible for ensuring full recovery of funds.=C2=A0

The problem with this approach = is that scanning for each additional label adds incrementally and non-trivi= ally to the computational burden. For each label, there is an EC point addi= tion and comparison against all taproot outputs for an eligible transaction= . Some benchmark numbers indicating=C2=A0the relative cost of each addition= al label are in [1], demonstrating that scanning for 100k labels is cost-pr= ohibitive. 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.

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

While not strictly necessary, using spscan and spspend=C2=A0key expressio= ns=C2=A0make for a much better user experience and reduce the chance for us= er error. With this encoding we get:
  1. A self-describing fo= rmat which makes the use and sensitivity of the key material immediately ob= vious
  2. The advantages of Bech32m encoding, including strong error de= tection and unambiguous characters
  3. Safety from accidentally mixing = different unrelated scan and spend keys
  4. Versioning to indicate sile= nt payments version 0
  5. A similar format to an xpub, the display of w= hich is a common user interface element in many wallets which makes things = simpler for wallet developers and users alike

On Thu, Dec 4, 20= 25 at 11:39=E2=80=AFAM Oghenovo Usiwoma <eunovo9@gmail.com> wrote:
Hi Craig, thank you for taking this up. I have the following comments, ba= sed on a light inspection of your original email.
> In order to reduce the scanning burden, a bl= ock height may be optionally specified in the sp() expression as a second a= rgument 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&#= 39;t matter much anyway, because the chain will get longer and this only he= lps temporarily.

Users c= an also specify a "wallet birthday" in their wallets which can be= used for scanning. Is there any reason to add the birthday to the descript= or? 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 labe= l (m =3D 0) is implicitly included.

In=C2=A0https://github.co= m/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-and-recovery , a s= trategy to recover funds from labels is specified. We can attempt to make t= his 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 o= nly have to scan for this max number of labels during recovery and if a wal= let 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 e= xpression sp() is defined, which takes as it's first argument one of tw= o new key expressions:
- spscan1q... which encodes t= he scan private key and the spend public key
- spspe= nd1q... which encodes the scan private key and the spend private key
<= div dir=3D"auto">
Given the above points, I argu= e 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 need for a silent payments output descrip= tor format in order to enable wallet interoperability and backup/recovery. = There has been some prior discussion on this topic [1][2] which this BIP pr= oposal builds on:


In summary=C2=A0a ne= w top level script expression sp() is defined, which takes as it's firs= t argument one of two new key expressions:
  • spscan1q... which encodes the scan private key and the spend p= ublic key
  • spspend1q... which encodes the= =C2=A0scan private=C2=A0key and the spend private key
The out= puts may then be generated by combining this key material with the sender i= nput public keys.=C2=A0

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

Examples:
sp(spscan1q...)
sp([dea= dbeef/352'/0'/0']spscan1q...,900000)
sp(spspend1q...,= 842579,1,2,3)
sp([deadbeef/352'/0'/0']spscan1q...,900= 000,1,5,10)

--Craig


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65X= aipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAPR5oBNX5oyzVJcWH9FDMOXE7q2MaZgSHX_LtCnOu%3DdcW9D70w%40ma= il.gmail.com.
--000000000000f8ceb90645bdbe5a--