From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 05 Aug 2026 16:36:58 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.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 1wrlAO-0000N8-UH for bitcoindev@gnusha.org; Wed, 05 Aug 2026 16:36:57 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-4412c255fd4sf792886fac.3 for ; Wed, 05 Aug 2026 16:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1785973010; x=1786577810; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=7a+MIC1DfEIEfrDaCMK73nYgwKjAQ65U3SmysN6+gmw=; b=aX8JreCc/dbmQUG3tOmjpc3/dBeZzWBV8/6KGyV4dGRelaTSe1TZVEQ0lmvqRHdWZs Yb8b7GUT0m0wCfK/66tfckguq6k8OvBmaKoxErz0zZdLzx1B5GEwURxRyRXlVovLfjFg Db8Lb/xfCa/qSYkbyFXIPnenqwR23SSqkLzBivcEBs3kA4tv3v0vSUEFTReoktqwunEP JhmMfSuRdkN7Af2+5+CBPWMnKQimy8Lov1pPsDQtBDctw8Me6gGNWY7jieweffKQJ7SX yUVL81UdSYHP7D8cuGUWpiI/E7+mceK84VjEjTz7g4vXSpW0+XExqyK/PyGEKkf3n+ev MSWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785973010; x=1786577810; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=7a+MIC1DfEIEfrDaCMK73nYgwKjAQ65U3SmysN6+gmw=; b=WjGIUO/OFs/poeJsNI9Ex5R6qRw7bGe3vUG4zuTgBo4lQQvmexW0ATArOT25tDkDai k+ohM3o4CWcYDNLzHOWOq9pyigFXklM9jf8CXZu/PK2Hb+0qWdBdw8+7DzGtsPsQOH3l Qy77n4xOHHzczoWPVz3S8Q16CcVFqBpYEZkR2VkVaJA1W6Od1smkHGB8bIYiWB4nt/R/ 1BpPW1ivNxsW0/tgHDxydD6lIAh1VBXvV9jPEp5Iy6hoCue5GQYsZtDfDTK51OXxflKN 7GSwh/S7a/h/qOwJc3MDL8OBuJI4HxO1Hq0zaV6Qbm5s4T0WOKqYgBK5I1k2j6qzXPAw R9oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785973010; x=1786577810; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :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:content-type; bh=7a+MIC1DfEIEfrDaCMK73nYgwKjAQ65U3SmysN6+gmw=; b=KdCSlsHKRfeF6DeYe+migTZPMU6415poekxdjYY/gYGFIKOJF+GwH4x68Vmk0Ilvad u/ILtWnhV0sdtAGfeiX+b3Y+8Vz09mSSWHq8VgKpViClQ28CBnKofKxYPbo3cKvwDGXz Z8V2EMaJUir3yC17FPyhSypynSPDDDij9deOfdNUXEjZm0oDn3NZU3xy1Pf15epCtHw/ xB36ScDVav0wJhV/P2poFP+e1na9xdybkkYR6VVa1AWp7AZNXE0yyiCapmNxUeIpduiT 2aGSiZ5iK0Lh+Cdirc2XNlj8wJs2bDxuUHNpiCfj773d5HFoUjmh4nM1vf+a+Fvtix5i G59g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RoOkv4OqgM79YwWevE40+5WnPKDPBpk/5P9km3QN46Ou867U/mKq8QSejqLyO+NYTl4veso9gPMgYfo@gnusha.org X-Gm-Message-State: AOJu0YyrmnxH4GtB3KeOSXqIePtdgxsGP9R3441IvMStkXRnd8ZkCbb7 MmFTOdDl1ChVxRqhn61DlC454sij+Uj6wHQEdouJnLJElYEjPphN8YxO X-Received: by 2002:a05:6870:515:b0:43e:e5bf:1ab4 with SMTP id 586e51a60fabf-4599f140ef7mr5929870fac.21.1785973010328; Wed, 05 Aug 2026 16:36:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPRDYButOH3iUQb7uJbEX9SMAMTwusvFkUaiUDpEtWSVqw==" Received: by 2002:a05:6870:760d:b0:447:3cb4:2c19 with SMTP id 586e51a60fabf-459cd2b0cadls33875fac.0.-pod-prod-09-us; Wed, 05 Aug 2026 16:36:43 -0700 (PDT) X-Received: by 2002:a05:6808:16a0:b0:4aa:cad:cb4c with SMTP id 5614622812f47-4afaddd8417mr5712720b6e.1.1785973003714; Wed, 05 Aug 2026 16:36:43 -0700 (PDT) Received: by 2002:a05:690c:9a11:b0:81e:11b4:1172 with SMTP id 00721157ae682-82112542592ms7b3; Wed, 5 Aug 2026 16:26:27 -0700 (PDT) X-Received: by 2002:a05:690c:4b86:b0:81d:e7d2:a46d with SMTP id 00721157ae682-8201bc73840mr62567767b3.5.1785972386103; Wed, 05 Aug 2026 16:26:26 -0700 (PDT) Date: Wed, 5 Aug 2026 16:26:25 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] BIP draft: CISA for Taproot Key Path Spends MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_32064_476181467.1785972385702" X-Original-Sender: bnagaev@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: -0.5 (/) ------=_Part_32064_476181467.1785972385702 Content-Type: multipart/alternative; boundary="----=_Part_32065_192768288.1785972385702" ------=_Part_32065_192768288.1785972385702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, hi Fabian, hi all! If we use BIP-459=20 full=20 aggregation for P2MR or P2TRH, we can recover one of the EC keys of a CISA= =20 group, solving its equation for that EC key. This saves 32 bytes per group.= =20 If a group is small, this actually makes sense. This is the equation that BIP-459 verifies: s=E2=8B=85G =3D R + =CE=A3 c_i=E2=8B=85P_i We can solve it for one of the public keys (P_j): P_j =3D (c_j^-1 mod n) =E2=8B=85 (s=E2=8B=85G - R - =CE=A3_{i=E2=89=A0j} c_= i=E2=8B=85P_i) (Here c_j !=3D 0. If c_j =3D=3D0, we need to restart the signing session wi= th=20 freshly generated nonces.) One thing we have to change in BIP-459 to enable this is how=20 coefficients c_i are calculated. Currently BIP-459 produces them based on EC public keys themselves: roughly= =20 c_j =3D H(L || R || P_j || m_j). This creates a circular dependency at=20 verification time if we don't know the omitted key (for P2MR or P2TRH). For P2TRH, we need to replace P_j with scriptPubKey_j in the=20 formula (something similar to my EC recovery proposal=20 ).=20 Since it commits to P_j, this should remain secure (need a formal proof). L= =20 also depends on public keys in BIP-459 - we need to change it to depend=20 on scriptPubKeys as well. We need to do it at least for the input whose=20 public key is recovered, but can also do for all inputs, for uniformity. For P2MR recoverable EC leaf=20 , scriptPubKey is=20 not sufficient as a replacement for a pubkey, since there might be multiple= =20 such leaves. To prevent related-key attacks, scriptPubKey must be=20 accompanied with the control block (or its hash) of the leaf. This must be= =20 done both in c_j and L formulas. Then we can recover one of the keys instead of putting it into witness. The= =20 natural choice is to recover the key of the input holding=20 the aggregate signature, since it is already a special input in CISA. Savings: - P2TRH-CISA: n + 32n + 64 =3D 33n + 64 - One-key recovery: n + 32(n-1) + 64 =3D 33n + 32 (This counts the witness payload above, including one marker byte per=20 input, but excludes CompactSize framing, annexes, and explicit sighash=20 bytes.) Inputs P2TRH-CISA One-key recovery Saved Saving 1 97 bytes 65 bytes 32 32.99% 2 130 bytes 98 bytes 32 24.62% 3 163 bytes 131 bytes 32 19.63% 4 196 bytes 164 bytes 32 16.33% 5 229 bytes 197 bytes 32 13.97% 7 295 bytes 263 bytes 32 10.85% 10 394 bytes 362 bytes 32 8.12% 20 724 bytes 692 bytes 32 4.42% 100 3,364 bytes 3,332 bytes 32 0.95% One additional nice effect of this is that no separate ordinary mode is=20 needed for basic single-input spending. A one-input full-aggregation group= =20 has the same 65-byte payload as a marker-based non-CISA single-input spend. The price is the loss of batch verification across CISA=20 groups. Inside-group verification efficiency is preserved: EC workload=20 inside group is almost the same, just one additional scalar inversion. Best, Boris On Saturday, July 18, 2026 at 1:50:35=E2=80=AFPM UTC-5 conduition wrote: Sending this again because I think the first time didn't work. Thanks Fabian, this is very cool. I haven't read the entire BIP in detail= =20 yet, but first thing I notice on a quick skim is that reserving segwit=20 version 2 conflicts with BIP-360 which proposes to use the same. I'm particularly interested in how to dovetail this proposal with PQ=20 migration efforts. I have two questions: 1. Can the framework you use for verifying aggregated sigs be=20 generalized to support future aggregated PQ signatures in the future?=20 (assuming we someday have a PQ sig algorithm that admits aggregation)=20 =20 2. How do you see this proposal mixing with BIP360? The major hurdle I= =20 see is that your proposed output type puts a bare EC pubkey on-chain in = the=20 script-pubkey. Unfortunately Boris' EC recovery trick=20 does=20 not seem to work in this context: Because signatures are aggregated we= =20 can't recover pubkeys, so we can't hide them behind a hash. We either ha= ve=20 to put them in the SPK, or the witness. So at face value, it seems there= =20 are two options: 1.=20 1. Couple CISA tightly with P2TRv2. On one hand this would be good=20 because it would provide a concrete incentive for users to migrate to= a=20 wallet that supports PQC. This also seems like the easier option from= an=20 engineering perspective. However it comes with all the baggage of P2T= Rv2=20 (not actually quantum-safe by default, need to solve the Q-day timing= =20 problem). 2. Hide the EC pubkeys behind a hash in the SPK (e.g. P2MR or P2TRH),= =20 and attach the EC pubkey in the witness of every aggregated TX input,= so=20 that the verifier can run the aggregated sig-verify algorithms. This = would=20 be more secure and relaxes the Q-day timing constraints, but we don't= get=20 as much relative savings.=20 =20 Napkin math of the witness weight of an aggregated input, assuming=20 full-aggregation is used: - with P2TRv2: - 1 byte for the marker - total: 1 byte - with P2TRH: - 1 byte for the marker - 32 bytes for the EC pubkey - total: 33 weight units - with P2MR: - 1 byte for the marker (witness) - 32 bytes for the merkle sibling node (witness) - 32 bytes for the EC pubkey (witness) - total: 65 weight units =20 regards, conduition On Saturday, July 18th, 2026 at 7:44 AM, 'Fabian' via Bitcoin Development= =20 Mailing List wrote: Hi list, I would like to share a BIP draft for transaction-wide cross-input signature aggregation (CISA). It introduces a new witness version, which enables Taproot-style key path spending where inputs can aggregate their signatures. Each input chooses between half-aggregation, full-aggregation, or an explicit opt-out via a marker byte in its witness. The aggregation schemes themselves are specified in the previously shared BIP 458 (half-aggregation) and BIP 459 (full-aggregation) drafts. Script path spending follows BIP 341/342 unchanged. The BIP draft text can be found here: https://github.com/fjahr/bips/blob/cf0d4f2142cd0504b16e86739167b1f7ab9a3a06= /bip-XXXX.mediawiki For inline comments, I have opened a mock pull request on my BIPs repo fork: https://github.com/fjahr/bips/pull/6 Feedback of any kind is much appreciated. Best, Fabian --=20 You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/Qc_VmkfXgE8KHBfUnUB-hdWF1QOYv6= zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEagoHs= V4%3D%40protonmail.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/= bc77e7a7-fb5a-4563-90bf-e6a3f98ed351n%40googlegroups.com. ------=_Part_32065_192768288.1785972385702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduition, hi Fabian, hi all!

If we use= = BIP-459 full aggregation for P2MR or P2TRH, we can recover one of the E= C keys of a CISA group, solving its equation for that EC key. This saves 32= bytes per group. If a group is small, this actually makes sense.

This is the equation that BIP-459 verifies:
s=E2=8B= =85G =3D R + =CE=A3 c_i=E2=8B=85P_i

We can solve= it for one of the public keys (P_j):
P_j =3D (c_j^-1 mod n) =E2= =8B=85 (s=E2=8B=85G - R - =CE=A3_{i=E2=89=A0j} c_i=E2=8B=85P_i)
<= br />
(Here=C2=A0c_j !=3D 0. If=C2=A0c_j =3D=3D0, we need to=C2= =A0restart the signing session with freshly generated nonces.)
One thing we have to change in=C2=A0BIP-459=C2=A0to enable t= his is how coefficients=C2=A0c_i are calculated.
Currently=C2=A0B= IP-459 produces them based on EC public keys themselves:=C2=A0roughly c_j = =3D H(L || R || P_j || m_j). This creates a circular dependency at verifica= tion time if we don't know=C2=A0the omitted key (for=C2=A0P2MR or P2TRH).

For=C2=A0P2TRH, we need to replace=C2=A0P_j with= =C2=A0scriptPubKey_j in the formula=C2=A0(something similar to my EC recovery proposal). Since it=C2=A0commits to=C2=A0P_j,= this=C2=A0should remain secure=C2=A0(need a formal proof). L also depends = on public keys in=C2=A0BIP-459 - we need to change it to depend on=C2=A0scr= iptPubKeys as well. We need to do it at least for the input whose public ke= y is recovered, but can also do for all inputs, for uniformity.
<= br />
For=C2=A0P2MR recoverable EC leaf,= =C2=A0scriptPubKey=C2=A0is not sufficient as a replacement for a pubkey, si= nce there might be multiple such=C2=A0leaves. To=C2=A0prevent related-key a= ttacks,=C2=A0=C2=A0scriptPubKey=C2=A0must be accompanied with the control b= lock (or its hash) of the leaf. This must be done both in c_j and L formula= s.

Then we can recover one of the key= s instead of putting it into witness. The natural choice is to recover the = key of the input holding the=C2=A0aggregate=C2=A0signature, since it is alr= eady a special input in CISA.

Savings:
- P2TRH-CISA: n + 32n + 64 =3D 33n + 64
- One-key recovery: n + 32(n-= 1) + 64 =3D 33n + 32
(This counts the witness payload above, incl= uding one marker byte per input, but excludes CompactSize framing, annexes,= and explicit sighash bytes.)

=C2=A0Inputs =C2=A0 =C2=A0 P2TRH-CISA =C2=A0 =C2=A0= One-key recovery =C2=A0 =C2=A0Saved =C2=A0 =C2=A0Saving
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 97 bytes =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A065 bytes =C2=A0 =C2=A0 =C2=A0 32 =C2=A0 =C2=A032.99%
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0130 bytes =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A098 bytes =C2=A0 =C2=A0 =C2=A0 32 =C2=A0 =C2=A024.62= %
=C2=A0 =C2=A0 =C2=A0 =C2=A0 3 =C2=A0 =C2=A0 =C2=A0163 bytes =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 131 bytes =C2=A0 =C2=A0 =C2=A0 32 =C2=A0 =C2=A0= 19.63%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 4 =C2=A0 =C2=A0 =C2=A0196 bytes =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 164 bytes =C2=A0 =C2=A0 =C2=A0 32 =C2=A0 = =C2=A016.33%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 5 =C2=A0 =C2=A0 =C2=A0229 byt= es =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 197 bytes =C2=A0 =C2=A0 =C2=A0 32 =C2= =A0 =C2=A013.97%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 7 =C2=A0 =C2=A0 =C2=A0295= bytes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 263 bytes =C2=A0 =C2=A0 =C2=A0 32= =C2=A0 =C2=A010.85%
=C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2= =A0394 bytes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 362 bytes =C2=A0 =C2=A0 =C2= =A0 32 =C2=A0 =C2=A0 8.12%
=C2=A0 =C2=A0 =C2=A0 =C2=A020 =C2=A0 =C2=A0= =C2=A0724 bytes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 692 bytes =C2=A0 =C2=A0= =C2=A0 32 =C2=A0 =C2=A0 4.42%
=C2=A0 =C2=A0 =C2=A0 100 =C2=A0 =C2=A03= ,364 bytes =C2=A0 =C2=A0 =C2=A0 =C2=A0 3,332 bytes =C2=A0 =C2=A0 =C2=A0 32 = =C2=A0 =C2=A0 0.95%

One additional nice e= ffect of this is that=C2=A0no separate ordinary mode is needed for basic si= ngle-input spending.=C2=A0A one-input full-aggregation group has the same 6= 5-byte payload as a marker-based non-CISA single-input spend.
The price is the loss of batch verification across CISA group= s.=C2=A0Inside-group verification efficiency is preserved: EC workload insi= de group is almost the same, just one additional scalar inversion.

Best,
Boris


On Saturday, July 18, 2026 at 1:50:35=E2=80=AFPM UTC-5 conduiti= on wrote:
Sending this again because I think the first= time didn't work.

Tha= nks Fabian, this is very cool. I haven't read the entire BIP in detail yet,= but first thing I notice on a quick skim is that reserving segwit version = 2 conflicts with BIP-360 which proposes to use the same.
<= br />
I'm particularly interested in how to dovetail this proposa= l with PQ migration efforts. I have two questions:

  1. Can the framework you use for verifying ag= gregated sigs be generalized to support future aggregated PQ signatures in = the future? (assuming we someday have a PQ sig algorithm that admits aggreg= ation)=C2=A0

  1. How do you see this proposal mixing with B= IP360? The major hurdle I see is that your proposed output type puts a bare= EC pubkey on-chain in the script-pubkey. Unfortunately Boris' EC recovery trick=C2=A0does not seem to work in this= context: Because signatures are aggregated we can't recover pubkeys, so we= can't hide them behind a hash. We either have to put them in the SPK, or t= he witness. So at face value, it seems there are two options:

      1. Couple CISA tightly with P2TRv2. On one h= and this would be good because it would provide a concrete incentive for us= ers to migrate to a wallet that supports PQC. This also seems like the easi= er option from an engineering perspective. However it comes with all the ba= ggage of P2TRv2 (not actually quantum-safe by default, need to solve the Q-= day timing problem).
      2. Hide the EC pubkeys behind a hash= in the SPK (e.g. P2MR or P2TRH), and attach the EC pubkey in the witness o= f every aggregated TX input, so that the verifier can run the aggregated si= g-verify algorithms. This would be more secure and relaxes the Q-day timing= constraints, but we don't get as much relative savings.=C2=A0
        3. <= /ol>

    Napkin math of= the witness weight of an aggregated input, assuming full-aggregation is us= ed:

    • w= ith P2TRv2:
      • 1 byte for the marker
      • total: 1 byte
      • <= li style=3D"list-style-type: "- ";">with P2TRH:
      • 1 byte for th= e marker
      • 32 bytes for the EC pubkey
      • total: 33 weight units<= /li>
    • with P2MR:
        1 byte for the marker (witness)
      • 32 bytes for the merkle sibling no= de (witness)
      • 32 bytes for the EC pubkey (witness)
      • total: 65= weight units

    regards,
    = conduition

On Saturday, July 18th, 2026 at 7:44 AM, 'Fabian' via Bitcoin Devel= opment Mailing List <bitco...@googlegroups= .com> wrote:
Hi list,

<= span>I would like to share a BIP draft for transaction-wide cross-input
signature=C2=A0aggregation (CISA). It introduces=C2=A0a new=C2=A0witness= =C2=A0version,
which enables Taproot-style key path = spending where=C2=A0inputs can<= /span>
aggregate their signa= tures.

Each input chooses between h= alf-aggregation, full-aggregation, or an
explicit op= t-out via a marker byte in its witness.
The aggregation schemes themselves are spec= ified in the previously
shared BIP 458 (half-aggrega= tion) and BIP 459 (full-aggregation)
drafts. Script = path spending follows BIP 341/342 unchanged.

<= div>The BIP draft text can be found here:

For inline comments, I have opened a m= ock pull request on my BIPs
repo fork:
<= div>ht= tps://github.com/fjahr/bips/pull/6

<= div>Feedback of any kind is much appreciated.

=
Best,
Fabian

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Qc_VmkfXgE8KHBfUnUB-hdWF1Q= OYv6zshzI7WEv_hvqJ6O_4zssJ4X2T2Di79I3TqHQvRDXsFtD8os5M44wrbB61M1LD_-GDRGYEa= goHsV4%3D%40protonmail.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/bitcoind= ev/bc77e7a7-fb5a-4563-90bf-e6a3f98ed351n%40googlegroups.com.
------=_Part_32065_192768288.1785972385702-- ------=_Part_32064_476181467.1785972385702--