From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 04 Mar 2026 02:38:13 -0800 Received: from mail-oa1-f63.google.com ([209.85.160.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 1vxjcK-00080Q-OR for bitcoindev@gnusha.org; Wed, 04 Mar 2026 02:38:13 -0800 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-4163be2d2ecsf12922107fac.2 for ; Wed, 04 Mar 2026 02:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772620686; x=1773225486; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=a6J1i2YvJZrcIGQaIVkc3eqFq9eMYD3HahauYA1IE8Y=; b=RUeQ9VSfJfFDVCB8lV/rPFXE8/ZsTekuRDHYXZCXVA0oOCMm9AtiYYZcSMR/T3o4hJ RiUwYu6bK2FYyNUTWeTnPP02wyrsxwyl21OKnK+vcso1N5+0M2jWM8FfAFSKRX2Ph7Tg ZPPU4ySESdQ/zUxlW3veAHF+zyRumvTCo/q9jNvhJU053xaPq0vri070o1H2iI9awqQQ RzulDYuNA1rEgUVnwCqDZDi15sa6YBMADLVH9mGOOlkG+qD6DlcbTk968vUFMGys1GN+ fScINNC+cD1zWju9P6bAtMTCX9mAlNaih8D4wcubkUjxHe/eSuG8G7jCFjQDoHYz3rn2 eaYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772620686; x=1773225486; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=a6J1i2YvJZrcIGQaIVkc3eqFq9eMYD3HahauYA1IE8Y=; b=TD3j7Ob4hYlyOLIBYVYvZLF7EpoKSR9F3A16jmwEvn1jaaBOuB9ZY7mwqf4w/9VPNS BE82UPeTtPQtVP3rZIxz3S8sTNLwhDKG3+yxh7Ez6tFOw7XSBzUJnz+zxT64IyCDjXSU BB/bxDw+V344sVU5XwM8/oMUHiiPt8OjfJT27PIzdGFL61L6dRCVrH0Sn348IU8jC9Zk YxHzXgcUteOWkzGv8GOFlgD/f3MdR7nCTEGDRFWkDggzz+yGWu0LkkX5cvEB8Eexqwrq eNqHovmt1BDWRbNncApPou5Fj9tV0m5YqdDiij0keW8BjT1eiJ5u6WXzjUQIZCqNTRL3 7aQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772620686; x=1773225486; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=a6J1i2YvJZrcIGQaIVkc3eqFq9eMYD3HahauYA1IE8Y=; b=BYKDf0F4NPeAgyGx29CM9ZXlDCgwE6M+Le7tLFbb/Rw5ZqL6m7WaNnHDcgsQpqrjoK JCi10jXFfay+yjPw+ORY7u8cjR/YojPGRfZZqBfqO3mBhLpN7juwP38tWG6mFVD6asjP ray4O4J5u74ASj7rJ8SgI5yHA9l+D8+msLFrFw7oTkpoGvDXTgnNunLmPKUEZ3HiD3Gt wZdQ4J5ANkY7iYLS45HDyokhDIBky7a0/RhiBFyw/w7TeZ632hNirJpkQaKSQX1MTWx6 8R4LkhKqGvlaMdRnKJ1TYaq14DUOM9nsQvnSrM3Feh/EFjqiiZoL67XBmWA9BT9ro3NF cnZA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVi3xxsz7NDZCVsXvGCEpUyhtd/nw/3vO7tO9PKqrXsWvPwr+cyLTaV/vKjGr01VTPLsKPqsdE57glT@gnusha.org X-Gm-Message-State: AOJu0YzUqraP0GT7ptm0L9cB11yrlXhMis9Em/XN2eLWqt042MVceBL4 FIAPYmU+LpBnLvBKzHa0mj2SssfQjHwLwhdzS6VbAzkXfMnX8Suio27x X-Received: by 2002:a05:6870:7124:b0:40e:dadc:4a01 with SMTP id 586e51a60fabf-416abc5cb79mr838060fac.46.1772620686075; Wed, 04 Mar 2026 02:38:06 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HFt5LMT2XGtTGXKOYuAMlgujia+yxdkU4GHve16v4lxg==" Received: by 2002:a05:6870:4410:b0:40e:f703:9195 with SMTP id 586e51a60fabf-415ede6e3eals4860535fac.0.-pod-prod-01-us; Wed, 04 Mar 2026 02:38:01 -0800 (PST) X-Received: by 2002:a05:6808:159c:b0:45e:c06e:5077 with SMTP id 5614622812f47-4651ad11066mr578423b6e.50.1772620680895; Wed, 04 Mar 2026 02:38:00 -0800 (PST) Received: by 2002:a05:690c:2b8c:b0:794:c577:7579 with SMTP id 00721157ae682-798c4323eb1ms7b3; Wed, 4 Mar 2026 01:45:03 -0800 (PST) X-Received: by 2002:a05:690c:e3ca:b0:798:752:101b with SMTP id 00721157ae682-798c6bd714bmr12363767b3.1.1772617502328; Wed, 04 Mar 2026 01:45:02 -0800 (PST) Date: Wed, 4 Mar 2026 01:45:01 -0800 (PST) From: Sebastian Falbesoner To: Bitcoin Development Mailing List Message-Id: <4bd9b8e5-1233-4959-b34f-281b5e91dcc1n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: BIP-352: Limiting the number of per-group recipients (K_max) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_62136_942925850.1772617501881" X-Original-Sender: sebastian.falbesoner@gmail.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: 2.6 (++) ------=_Part_62136_942925850.1772617501881 Content-Type: multipart/alternative; boundary="----=_Part_62137_790469533.1772617501881" ------=_Part_62137_790469533.1772617501881 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Update: the proposed BIP-352 protocol change [1] was merged, setting K_max= =20 =3D 2323. This limit was chosen intentionally, as it represents the maximum number of= =20 taproot outputs that can fit within a <=3D 100 kvB transaction with the smallest=20 Silent Payments eligible input (a taproot key-path spend) [2]. Consequently, any transaction that adheres to the current transaction size policy rule [3] is guaranteed to also comply with the K_max protocol limit.= =20 It is therefore extremely unlikely that any wallet would ever encounter this= =20 limit in practice, as such a transaction would not propagate on the network. Thanks to everyone involved in proposing, discussing and reviewing this=20 change. The secp256k1 silentpayments module PR [4] will be updated and taken out of draft state shortly. Best, Sebastian [1] https://github.com/bitcoin/bips/pull/2106 [2] a 1-in-2323-out P2TR transaction has a vsize of 99959 vbytes, see e.g.= =20 https://jlopp.github.io/bitcoin-transaction-size-calculator/ or=20 https://bitcoinops.org/en/tools/calc-size/ (note that the latter calculator= =20 doesn't account the two extra bytes needed for the output-count compactSize= =20 encoding); adding one more taproot output (taking 43) vbytes would result= =20 in 100002 vbytes [3] `MAX_STANDARD_TX_WEIGHT` in Bitcoin Core (expressed in WUs):=20 https://github.com/bitcoin/bitcoin/blob/2702711c3a54b2ba9ae3781b61c90d28ee9= 51de6/src/policy/policy.cpp#L110-L114 [4] https://github.com/bitcoin-core/secp256k1/pull/1765 On Friday, February 20, 2026 at 12:36:08=E2=80=AFAM UTC+1 Sebastian Falbeso= ner=20 wrote: > Thanks for all the feedback left on the secp256k1 issue [1]. > > As no objections were raised to the proposed K_max protocol change, I've= =20 > opened a corresponding PR in the BIPs repository, where the discussion ca= n=20 > be continued: > https://github.com/bitcoin/bips/pull/2106 > > Best, Sebastian > > [1]=20 > https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-384204= 6237=20 > ff. > On Wednesday, February 4, 2026 at 6:21:09=E2=80=AFPM UTC+1 Sebastian Falb= esoner=20 > wrote: > >> Hi list,=20 >> >> In the course of working on a Silent Payments module for libsecp256k1=20 >> [1], we=20 >> discovered that the scanning approach suggested in BIP-352 [2] suffers= =20 >> from=20 >> very poor performance for adversarial transactions [3].=20 >> >> One more recent proposal to mitigate this issue is by introducing a=20 >> "K_max"=20 >> protocol limit. This effectively limits the number of per-group recipien= ts=20 >> within a single transaction, i.e. the number of recipients sharing the= =20 >> same=20 >> scan public key. In theory this is a backwards incompatible protocol=20 >> change,=20 >> in practice we believe that none of the existing SP wallets would be=20 >> affected,=20 >> for a reasonably high K_max (the example value used is K_max=3D1000, but= =20 >> this=20 >> can be seen as a placeholder).=20 >> >> See the following BIP change draft for more details and motivation:=20 >> >> https://github.com/theStack/bips/commit/961d1442139ceecd6c0cc5775ef911d6= 9aabed4c=20 >> >> The discussion is on-going at the following issue:=20 >> https://github.com/bitcoin-core/secp256k1/issues/1799 [4]=20 >> >> If you have any concerns or feedback for this change, either for current= ly=20 >> existing wallets or potential future use-cases that you could think of,= =20 >> please=20 >> comment there. Most SP wallet developers that we are aware of have=20 >> already been=20 >> pinged on the issue. We are posting this here to reach a wider audience= =20 >> and to=20 >> provide an alternative opportunity to comment, in case anyone doesn't=20 >> want to=20 >> use GitHub.=20 >> >> Best, >> Sebastian >> >> [1] https://github.com/bitcoin-core/secp256k1/pull/1765=20 >> [2]=20 >> https://github.com/bitcoin/bips/blob/5d0f70a5cf4cfc429267cd6cc246ba3bcb9= 49cb3/bip-0352.mediawiki?plain=3D1#L330=20 >> [3]=20 >> https://github.com/bitcoin-core/secp256k1/pull/1698#pullrequestreview-33= 41766084=20 >> [4]=20 >> https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-38420= 46237=20 >> ff. in particular > > --=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/= 4bd9b8e5-1233-4959-b34f-281b5e91dcc1n%40googlegroups.com. ------=_Part_62137_790469533.1772617501881 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Update: the proposed BIP-352 protocol change [1] was merged, setting K_max = =3D 2323.
This limit was chosen intentionally, as it represents the ma= ximum number of taproot
outputs that can fit within a <=3D 100= kvB transaction with the smallest Silent Payments
eligible input= (a taproot key-path spend) [2].

Consequently, any transaction t= hat adheres to the current transaction size
policy rule [3] is guarant= eed to also comply with the K_max protocol limit. It
is therefore extr= emely unlikely that any wallet would ever encounter this limit
in prac= tice, as such a transaction would not propagate on the network.

= Thanks to everyone involved in proposing, discussing and reviewing this cha= nge.

The secp256k1 silentpayments module PR [4] will be updated = and taken out of
draft state shortly.

Best,
Sebastian<= br />
[1] https://github.com/bitcoin/bips/pull/2106
[2] a 1-in-23= 23-out P2TR transaction has a vsize of 99959 vbytes, see e.g. https://jlopp= .github.io/bitcoin-transaction-size-calculator/ or https://bitcoinops.org/e= n/tools/calc-size/ (note that the latter calculator doesn't account the two= extra bytes needed for the output-count compactSize encoding); adding one = more taproot output (taking 43) vbytes would result in 100002 vbytes
[= 3] `MAX_STANDARD_TX_WEIGHT` in Bitcoin Core (expressed in WUs): https://git= hub.com/bitcoin/bitcoin/blob/2702711c3a54b2ba9ae3781b61c90d28ee951de6/src/p= olicy/policy.cpp#L110-L114
[4] https://github.com/bitcoin-core/secp256= k1/pull/1765

On Friday, February 20, 2026 at 12:36:08=E2=80=AFAM UTC+1 S= ebastian Falbesoner wrote:
Thanks for all the feedback left on the secp256k1 issue = [1].

As no objections were raised to the proposed = K_max protocol change, I've opened a corresponding PR in the BIPs repos= itory, where the discussion can be continued:

Best, Sebastian

[1]=C2=A0https:= //github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3842046237= ff.
On Wednesday, February 4, 2026 at 6:21:09=E2=80=AFPM UTC+1 Sebastian Falbe= soner wrote:
Hi list, =20
=20
In the course of working on a Silent Payments module fo= r libsecp256k1 [1], we =20
discovered that the scanning approach suggested in BIP-= 352 [2] suffers from =20
very poor performance for adversarial transactions [3].= =20
=20
One more recent proposal to mitigate this issue is by i= ntroducing a "K_max" =20
protocol limit. This effectively limits the number of p= er-group recipients =20
within a single transaction, i.e. the number of recipie= nts sharing the same =20
scan public key. In theory this is a backwards incompat= ible protocol change, =20
in practice we believe that none of the existing SP wal= lets would be affected, =20
for a reasonably high K_max (the example value used is = K_max=3D1000, but this =20
can be seen as a placeholder). =20
=20
See the following BIP change draft for more details and= motivation: =20
https://github.com/theStack/bips/commit/961d1442139ceecd6c0cc5775ef9= 11d69aabed4c =20
=20
The discussion is on-going at the following issue: =20
https://github.com/bitcoin-core/secp256k1/issue= s/1799 [4] =20
=20
If you have any concerns or feedback for this change, e= ither for currently =20
existing wallets or potential future use-cases that you= could think of, please =20
comment there. Most SP wallet developers that we are aw= are of have already been =20
pinged on the issue. We are posting this here to reach = a wider audience and to =20
provide an alternative opportunity to comment, in case = anyone doesn't want to =20
use GitHub. =20
=20
Best,
Sebas= tian

[1] https://github.com/bitcoin-core/secp256k1/pull/1765 =20
[2] https://github.com/bitcoin/bips/blob/5d0f70a5cf4cfc429267cd6cc246ba3bcb949= cb3/bip-0352.mediawiki?plain=3D1#L330 =20
[3] https://github.com/bitcoin-core/secp256k1/pull/1698#pullreques= treview-3341766084 =20
[4] https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3= 842046237 ff. in particular

--
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/bitcoind= ev/4bd9b8e5-1233-4959-b34f-281b5e91dcc1n%40googlegroups.com.
------=_Part_62137_790469533.1772617501881-- ------=_Part_62136_942925850.1772617501881--