From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 31 Mar 2026 18:45:33 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w7keB-0004Cd-Ux for bitcoindev@gnusha.org; Tue, 31 Mar 2026 18:45:33 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-679c51b2d6csf20102295eaf.2 for ; Tue, 31 Mar 2026 18:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775007925; x=1775612725; 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=Sc34/+ZrTkFlSJPRvCe1MajQgv/So2U/Xj2WxrU37eQ=; b=Ku3IfwHBrjc3xu00joVNsmIby0MweQRcSRtp4hzE6HoJ1qYgKJn5epXv7mXhqy2MVh ZCjHCc8Z1vvhfAOiU19MV1tJc3xYbAWDxlnDgCJ86oQBLkxvxdhMg27PmiIeB8PksULu fkSOGNDtVU/3j3wCTUBxfo5OgitX6pIaUjNxTfIWcdtcLPNz5OUHwReFImoq9OpkssQA +pW81UB1zJI0Lw+RzaGuERt5jMQEDDf1SGnpDzHs0ed8WInkTEdvBoFEHiL4Ak+8d/Lf Ff+jrf4ldwxv3/daKyJfgFC0aFKPG7CeWY8Ztu6KGW1jSO9/OeYudL0+Apk1fN6Wu6yB NMiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775007925; x=1775612725; 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=Sc34/+ZrTkFlSJPRvCe1MajQgv/So2U/Xj2WxrU37eQ=; b=lFMq7L8j87ezWk2PhevD7FBp4dKDjpKMSKEFuTlqcHw0k/oLixOTH1078OQ92YurjX SlP+94h1mXFbQj25LCUdtl6bwiYEaHmfUBt7S51fWhPeDHN3Uuk5JycLdhvLYMlGR39b 02OAhGSzgo6VAYJiEL/3yUsAAfStGZE1tIriweab7dPCssI3Z3nm8CuBCsQthq5AVQHA wfrPln4gTd03JQaTmGNpul383bI4y4EOlusq9YntUKcgoejeM6oePBTl4A1VqEJrULzJ vauZjJbGdPbwnLO06xgNNMtn59iyxmAuhWN1t7u/4AOLMOz2o699dCQZiYz32PaajhL9 tYLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775007925; x=1775612725; 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=Sc34/+ZrTkFlSJPRvCe1MajQgv/So2U/Xj2WxrU37eQ=; b=lAtwlefSPvErxmmAWD+qUS3YOUPIiKHkfg5n1LnB1sgsP64nrDrh9WBplf6Nqhbw/w CXQ1fw27WzeYiJZRWF4uEZ0ZFMsoRYpYDzcN4w1GSv2A2W33HAKsiQsTP9mbC3qdA6vr XsRxaqJloQBvj77NlVO5BvFHzuBjh1VDGAlC+6j6sA5fSloI79z0ziAlz+WRPqbw34Fe N5C+zMxQ54ViTfD+EOIAUZ213FvuyK2cgeZrOTKLRjTFGq2PJ8iam3PQov0msFsd4klH 8tLBYed9XF4Xnf2QR34tcJdeb2UV03yZJ9poU97UgEDFPYlgOr7/0FTTltshbu5D584S 4ccA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXcYiJf04Z8OHWFhK2LqPk95EoSTGZ+L0IsIbPuYf0TrCY2w8gTy7W7jXWbKOWI8IbMWoYBR5u9X9DU@gnusha.org X-Gm-Message-State: AOJu0YwvdX+M6wetYeEzxANK9EOXNBnhu8EXF1YUR4CxYg5ud7T45Zzx anf+nolLU0tRYNrOf7ocjDCFJSZfwLMUxhH3oC4c3x3efEpiqXSilf/5 X-Received: by 2002:a05:6820:20e:b0:67c:1ea0:2c4 with SMTP id 006d021491bc7-67fabbf182emr872501eaf.6.1775007925481; Tue, 31 Mar 2026 18:45:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIPWR9TiZJLbNrf+3+GawSWEV694jiNoHTTEJHrMSz8Cw==" Received: by 2002:a05:6870:41cc:b0:40e:b5a8:d871 with SMTP id 586e51a60fabf-41cc8ff5aa2ls2359471fac.2.-pod-prod-02-us; Tue, 31 Mar 2026 18:45:20 -0700 (PDT) X-Received: by 2002:a05:6808:1508:b0:467:155f:8c2a with SMTP id 5614622812f47-46ae010a0admr914820b6e.35.1775007920114; Tue, 31 Mar 2026 18:45:20 -0700 (PDT) Received: by 2002:a81:fe0a:0:b0:79a:8019:36f5 with SMTP id 00721157ae682-7a25327915ems7b3; Tue, 31 Mar 2026 17:56:55 -0700 (PDT) X-Received: by 2002:a05:690c:102:b0:7a1:d383:eda3 with SMTP id 00721157ae682-7a2104a337bmr19361237b3.22.1775005014721; Tue, 31 Mar 2026 17:56:54 -0700 (PDT) Date: Tue, 31 Mar 2026 17:56:54 -0700 (PDT) From: Sebastian Falbesoner To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <4bd9b8e5-1233-4959-b34f-281b5e91dcc1n@googlegroups.com> References: <4bd9b8e5-1233-4959-b34f-281b5e91dcc1n@googlegroups.com> Subject: [bitcoindev] Re: BIP-352: Limiting the number of per-group recipients (K_max) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_521066_912312929.1775005014052" 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_521066_912312929.1775005014052 Content-Type: multipart/alternative; boundary="----=_Part_521067_425727506.1775005014052" ------=_Part_521067_425727506.1775005014052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Follow-up: a transaction demonstrating the discussed worst-case scanning attack with 23230 outputs is now available on Signet (block height 297894)= =20 [1]: https://mempool.space/signet/block/00000002f010f4f0dcc89bb3cf951e70d59d8be0= 4fa6fd2d281842c0ba6e02a2 https://mempool.space/signet/tx/e429ec8858d0b34d7e05f1ce178ada4ae197fa71868= 30613a304c59f9687a80e Wallets can exercise the effect of a targeted attack by scanning this block with the following key and label material: Scan secret key: =20 00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff Scan public key: =20 02c2a4c3969a1acfd0a67f8881a894f0db3b36f7f1dde0b053b988bf7cff325f6c Spend secret key:=20 ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100 Spend public key:=20 0398dc4ade30b8aee66db06be9d22543df8bc7b4ea8f177dcb2124d8789c8b97d3 Label tweak (m=3D0):=20 adecfc875af28554f2588be4f25cbb68b33a0e015cea5f67f954ea9b901848c1 Label (m=3D0): =20 03c848bb6729345caa616ec32ca54eeeac14f3c77cedcfae66ecdda5b5a06ad883 Labeled spend key:=20 03eff186a9a7c8e40b484c7fa4865e0bf52f9a10d09e1f95ce36ad6c241ded54e5 All 23230 outputs were created with the same labeled address as recipient: sp1qqtp2fsukngdvl59x07ygr2y57rdnkdhh78w7pvznhxyt7l8lxf0kcql07xr2nf7gus95snr= l5jr9uzl497dpp5y7r72uud4ddsjpmm25u5re4lah Note that as per the latest BIP-352 protocol change [2], only 2323 of these= =20 outputs (created with k values in the range [0..2322] inclusive) are valid. As a recap, the attack is only relevant for users following the "BIP=20 approach" of scanning. Wallets using the "LabelSet approach" are very likely not=20 affected (with or without the protocol change) [3]. I've hacked together a small demo that uses libbitcoinkernel and the=20 secp256k1 silentpayments module [4] to scan this block (assuming that an unpruned=20 signet datadir sits in ~/.bitcoin/signet), with and without the K_max protocol=20 limit to show the difference: $ git clone https://github.com/theStack/bip352-signet-scan-worstcase $ cd bip352-signet-scan-worstcase $ ./build_and_run.sh [ ... ] Scanning 1-in-23230-out tx=20 e429ec8858d0b34d7e05f1ce178ada4ae197fa7186830613a304c59f9687a80e... -> Uncapped K [worst-case order]: scanning took 165.186 seconds (23230=20 outputs found) -> Uncapped K [shuffled outputs]: scanning took 165.852 seconds (23230=20 outputs found) -> K_max=3D2323 [worst-case order]: scanning took 31.404 seconds (2323=20 outputs found) -> K_max=3D2323 [shuffled outputs]: scanning took 16.930 seconds (2323=20 outputs found) Note that shuffling outputs doesn't improve anything in the uncapped case,= =20 as the secp256k1 implementation currently doesn't skip found outputs to keep i= t simple -- with the K_max limit, it wouldn't improve the worst-case=20 performance noticeably. For anyone wondering, the demo code is currently not suitable for scanning= =20 SP transactions in general, as it assumes a single input and is only able to= =20 cope with P2TR inputs. It might be a workable starting point for a general=20 BIP-352 scanning tool using libbitcoinkernel and libsecp256k1, if anyone is=20 interested in working on that. Best, Sebastian [1] thanks to AJ Towns for mining this block; as this is a non-standard tx exceeding 100 kvB, offband communication was necessary to make this happen [2] https://github.com/bitcoin/bips/pull/2106 [3] see discussion=20 https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-37731557= 88=20 ff. [4] PR #1765: https://github.com/bitcoin-core/secp256k1/pull/1765 On Wednesday, March 4, 2026 at 11:38:06=E2=80=AFAM UTC+1 Sebastian Falbeson= er wrote: > Update: the proposed BIP-352 protocol change [1] was merged, setting K_ma= x=20 > =3D 2323. > This limit was chosen intentionally, as it represents the maximum number= =20 > of 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 siz= e > policy rule [3] is guaranteed to also comply with the K_max protocol=20 > limit. 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=20 > calculator doesn't account the two extra bytes needed for the output-coun= t=20 > compactSize encoding); adding one more taproot output (taking 43) vbytes= =20 > would result in 100002 vbytes > [3] `MAX_STANDARD_TX_WEIGHT` in Bitcoin Core (expressed in WUs):=20 > https://github.com/bitcoin/bitcoin/blob/2702711c3a54b2ba9ae3781b61c90d28e= e951de6/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 Falbe= soner=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 c= an=20 >> be continued: >> https://github.com/bitcoin/bips/pull/2106 >> >> Best, Sebastian >> >> [1]=20 >> https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-38420= 46237=20 >> ff. >> On Wednesday, February 4, 2026 at 6:21:09=E2=80=AFPM UTC+1 Sebastian Fal= besoner=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=20 >>> recipients=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, bu= t=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/961d1442139ceecd6c0cc5775ef911d= 69aabed4c=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=20 >>> currently=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/5d0f70a5cf4cfc429267cd6cc246ba3bcb= 949cb3/bip-0352.mediawiki?plain=3D1#L330=20 >>> [3]=20 >>> https://github.com/bitcoin-core/secp256k1/pull/1698#pullrequestreview-3= 341766084=20 >>> [4]=20 >>> https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3842= 046237=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/= cf64109b-4d78-4515-a68e-d427243a105cn%40googlegroups.com. ------=_Part_521067_425727506.1775005014052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Follow-up: a transaction demonstrating the discussed worst-case scanningattack with 23230 outputs is now available on Signet (block height 29789= 4) [1]:

https://mempool.space/signet/block/00000002f010f4f0dcc89= bb3cf951e70d59d8be04fa6fd2d281842c0ba6e02a2
https://mempool.space/sign= et/tx/e429ec8858d0b34d7e05f1ce178ada4ae197fa7186830613a304c59f9687a80e

Wallets can exercise the effect of a targeted attack by scanning thi= s block
with the following key and label material:

Scan sec= ret key: =C2=A0 00112233445566778899aabbccddeeff00112233445566778899aabbccd= deeff
Scan public key: =C2=A0 02c2a4c3969a1acfd0a67f8881a894f0db3b36f7= f1dde0b053b988bf7cff325f6c
Spend secret key: =C2=A0ffeeddccbbaa9988776= 6554433221100ffeeddccbbaa99887766554433221100
Spend public key: =C2=A0= 0398dc4ade30b8aee66db06be9d22543df8bc7b4ea8f177dcb2124d8789c8b97d3
Lab= el tweak (m=3D0): adecfc875af28554f2588be4f25cbb68b33a0e015cea5f67f954ea9b9= 01848c1
Label (m=3D0): =C2=A0 =C2=A0 =C2=A0 03c848bb6729345caa616ec32c= a54eeeac14f3c77cedcfae66ecdda5b5a06ad883
Labeled spend key: 03eff186a9= a7c8e40b484c7fa4865e0bf52f9a10d09e1f95ce36ad6c241ded54e5

All 232= 30 outputs were created with the same labeled address as recipient:
sp= 1qqtp2fsukngdvl59x07ygr2y57rdnkdhh78w7pvznhxyt7l8lxf0kcql07xr2nf7gus95snrl5= jr9uzl497dpp5y7r72uud4ddsjpmm25u5re4lah

Note that as per the lat= est BIP-352 protocol change [2], only 2323 of these outputs
(created w= ith k values in the range [0..2322] inclusive) are valid.
As a recap, = the attack is only relevant for users following the "BIP approach"
of = scanning. Wallets using the "LabelSet approach" are very likely not affecte= d
(with or without the protocol change) [3].

I've hacked to= gether a small demo that uses libbitcoinkernel and the secp256k1
silen= tpayments module [4] to scan this block (assuming that an unpruned signetdatadir sits in ~/.bitcoin/signet), with and without the K_max protocol= limit to
show the difference:

$ git clone https://github.c= om/theStack/bip352-signet-scan-worstcase
$ cd bip352-signet-scan-worst= case
$ ./build_and_run.sh
[ ... ]
Scanning 1-in-23230-out tx= e429ec8858d0b34d7e05f1ce178ada4ae197fa7186830613a304c59f9687a80e...
-= > Uncapped K [worst-case order]: scanning took 165.186 seconds (23230 ou= tputs found)
-> Uncapped K [shuffled outputs]: scanning took 165.85= 2 seconds (23230 outputs found)
-> K_max=3D2323 [worst-case order]:= scanning took 31.404 seconds (2323 outputs found)
-> K_max=3D2323 = [shuffled outputs]: scanning took 16.930 seconds (2323 outputs found)
=
Note that shuffling outputs doesn't improve anything in the uncapped = case, as
the secp256k1 implementation currently doesn't skip found out= puts to keep it
simple -- with the K_max limit, it wouldn't improve th= e worst-case performance
noticeably.

For anyone wondering, = the demo code is currently not suitable for scanning SP
transactions i= n general, as it assumes a single input and is only able to cope
with = P2TR inputs. It might be a workable starting point for a general BIP-352scanning tool using libbitcoinkernel and libsecp256k1, if anyone is inte= rested
in working on that.

Best,
Sebastian

= [1] thanks to AJ Towns for mining this block; as this is a non-standard tx<= br />exceeding 100 kvB, offband communication was necessary to make this ha= ppen
[2] https://github.com/bitcoin/bips/pull/2106
[3] see discus= sion https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-377= 3155788 ff.
[4] PR #1765: https://github.com/bitcoin-core/secp256k1/pu= ll/1765

On Wednesday, March 4, 2026 at 11:38:06=E2=80=AFAM UTC+1 Sebastia= n Falbesoner wrote:
Update: the proposed BIP-352 protocol change [1] was merged, setting= K_max =3D 2323.
This limit was chosen intentionally, as it represents t= he maximum number of taproot
outputs that can fit within a <=3D = 100 kvB transaction with the smallest Silent Payments
eligible in= put (a taproot key-path spend) [2].

Consequently, any transaction = that adheres to the current transaction size
policy rule [3] is guarante= ed to also comply with the K_max protocol limit. It
is therefore extreme= ly unlikely that any wallet would ever encounter this limit
in practice,= as such a transaction would not propagate on the network.

Thanks to= everyone involved in proposing, discussing and reviewing this change.
<= br>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. https://jlopp.github.io/bitcoi= n-transaction-size-calculator/ or https://bitcoinops.org/en/tools/calc-size/ (n= ote that the latter calculator doesn't account the two extra bytes need= ed for the output-count compactSize encoding); adding one more taproot outp= ut (taking 43) vbytes would result in 100002 vbytes
[3] `MAX_STANDARD_TX= _WEIGHT` in Bitcoin Core (expressed in WUs): https://github.com/bitcoin/bitcoin/blob/2702711c3a54= b2ba9ae3781b61c90d28ee951de6/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 Falbesoner wrote:
Thanks for all the feedba= ck left on the secp256k1 issue [1].

As no objectio= ns were raised to the proposed K_max protocol change, I've opened a cor= responding PR in the BIPs repository, where the discussion can be continued= :

Best, Se= bastian

On Wednesday, February 4, 2026 at 6:21:09= =E2=80=AFPM UTC+1 Sebastian Falbesoner 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/cf64109b-4d78-4515-a68e-d427243a105cn%40googlegroups.com.
------=_Part_521067_425727506.1775005014052-- ------=_Part_521066_912312929.1775005014052--