path: root/6b/b53227b0fc33fe8e3f962df7f8ca6143c258d6

Delivery-date: Fri, 25 Jul 2025 09:56:41 -0700
Received: from mail-qt1-f189.google.com ([209.85.160.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBPHOR3CAMGQESRMROYI@googlegroups.com>)
	id 1ufLip-0007Ay-31
	for bitcoindev@gnusha.org; Fri, 25 Jul 2025 09:56:41 -0700
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-4ab969af6e3sf27775071cf.2
        for <bitcoindev@gnusha.org>; Fri, 25 Jul 2025 09:56:38 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1753462593; cv=pass;
        d=google.com; s=arc-20240605;
        b=c0qZF1LVCF98kHCuujHx5Cm9qXVi7bntVxN2u64o28XP/WnckV1LArrleeHlaltyG/
         E6NKVtTNBFg8lcjY01lEq7f5CVXSdfQKh8r4UWTqpXzwEh1cARiHR5A8Kn4xP5u8MnVr
         /Nl52sJZIMkkmYdnUQrrbC2CeEoAFjUszTdZ5kq4fV+iscM3L3dUZxoIVVedKWVLi1uQ
         b4Y7ZoE5n4103NrkmbSAKS3wpsDKZ+ttZF9ew/5TebfWWJpo0GniJSXsYBrbeJ/41zT4
         /thY7wycWoSLe8oxAXopIeiH8rDcoHGCN0dhRFlPq2a6eLvvYUckl69o8zIJKF3s5OtH
         6JVA==
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:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=;
        fh=CApDPYchAIEs7aq+YNl+giqjE3w2IszXfwQ+UtYhEmw=;
        b=PGoiEe/NbTDDLmqCIJXczi5nbGAQJkqbugf3bxjfpG4yWPWDc+ikuPbqDbYXR/joV+
         kPe3oIQPI8so9oR5tdW/gRKA8jSDbECGRxWJ3z14vbHqVIG7ylLhevUE181Jf8NBO80V
         nnWxCDf5NYSTWJqhVd0jF2klVX15UGMqj9jZriXZIx9EZdU6JfTZFpdGrYwShA4AWuE0
         uT4W8JVDekSrFANYAgy9R6Q2ZwAqNPd3no2+ALG4eGN5y8uhFOKwHV434415qlAQHkvX
         7GSiOOJi8ZWv/sRO4MhzDmppeIW1GlKRY0nGzUED658Nepo8ovi1VHjuF/MNdWpRE7Eq
         Zv2A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1753462593; x=1754067393; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=;
        b=WYmqn4Lxd6u2gh5CPVXvcmmWa9zXH4adhcXdTM1A2R4CJRqy8moaBtCtAbxkFyifLW
         k8PZUaNOcePsQ33lz8/RkNzLL+L38KZId0GblMGwvD7s/v8NudRZFME42D2Ymsk2WO/o
         GeVdeLxVvZ3AwJDLft8H/1H4oE87oEDlfQ2dZ4p/1mhg5s+xp9XVhRBnB+FB2dMG5di7
         gzgl8X872wP7OH6UA93Wd2VLA3orEtSZAXkCNc5ZlejlGkNPv8mCAxjfdX1CufahJ37v
         xsAq9O4MMbtFLjUkhKV/vZvouk3A9BpEJOcUD8sNQY2U3Ye/49xnZaeVBmo0Y/HURonI
         bhYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753462593; x=1754067393;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=;
        b=fb0Ju710MMUa1ZyVJVUQeoQaprxeiP1LA0P3eEuOSudfkA1E1u4L7+pr+SFakEHtuK
         wPReEyK8DwIChCcqDs+foVe1/IQ3hGH+z2W1v2xSvQBXncWUcc/VhnS5pvaGrsLGpwdO
         qw8xidggL4QzQymvj5B1wvSyURrJhvuQn7Udw1i++LxGD5GKA/E+/9UraMEbw1R1ZqXg
         yFEqg4gX/sNWyXdaUgoIsNa+aGGkt2WOwzBjwz8a9mjTy2Hn3kn9X8+4Qp2OrISXik2D
         VHRgecmPdCkulrbcDWmzM0fsA41UeJvpxCsHAy+il0xz1nTLUIlTwx9tCKTDlWiRGlP5
         RQUQ==
X-Forwarded-Encrypted: i=2; AJvYcCVlqhEpSKnAyu+w0aQ7lZbakjkDExInH3qWUnT/YFp1Bp+JxBRaaj1toHzGhS4upQ1bZCfyDywqCmE/@gnusha.org
X-Gm-Message-State: AOJu0Ywk0VA/Td7ElbTU0MwxmSwHYVYq0AT4uoV/a6X3inr7O4FGL8lj
	0VaMYq/p9MpTiXHPcUusnW5KXLftzv+FR7nSUCMqPCgQQOpN2/mQwDZp
X-Google-Smtp-Source: AGHT+IHc62kVsmdW8h1Jac+Pk9OjgvdlEzExvIKbS530js55BdLdAo8zd4KwvjtT+X4H91gWh9gomQ==
X-Received: by 2002:ac8:588c:0:b0:4a9:80f6:19ad with SMTP id d75a77b69052e-4ae8f0daa4fmr31713441cf.45.1753462592277;
        Fri, 25 Jul 2025 09:56:32 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf7JZJYZcz/a/HmcGsQqxkFsadfTZdYqEi5IrCcZH3SXw==
Received: by 2002:a05:622a:552:b0:4ab:8d30:5860 with SMTP id
 d75a77b69052e-4ae7bd33e2bls38984771cf.1.-pod-prod-08-us; Fri, 25 Jul 2025
 09:56:28 -0700 (PDT)
X-Received: by 2002:a05:620a:618e:b0:7e1:90b9:6cee with SMTP id af79cd13be357-7e63c1bb434mr307391485a.58.1753462588360;
        Fri, 25 Jul 2025 09:56:28 -0700 (PDT)
Received: by 2002:a05:6402:455b:b0:609:bcd7:3415 with SMTP id 4fb4d7f45d1cf-61496efaafcmsa12;
        Wed, 23 Jul 2025 14:12:33 -0700 (PDT)
X-Received: by 2002:a17:907:3fa0:b0:ad8:a935:b8e8 with SMTP id a640c23a62f3a-af2f64bf8f4mr451001066b.5.1753305150253;
        Wed, 23 Jul 2025 14:12:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1753305150; cv=none;
        d=google.com; s=arc-20240605;
        b=FYcJ9wlkeaqd294JgxHhhjJaMWZa4lqpgoIf7Rg2YJ5wrq3C/3h8w6WVEdTqiVnw7D
         AilzhQi7DFFHyu2bUwddvNEm2rHUf8hwLQGf/8tWW4K7XR4ucJln/vzppIUtN6RQBmaL
         OMFeKwsmmh5mQvp43FyC1j9D9BzDTBfO3XuKD3OQk2pLl+N/AJPz7cNiEzARKo3IwvWk
         fVn2ldwkwZI6A9brN9PLUuyfxm6CF4KiSK/2r0EiDyKoVsUbHG9i7PMQwIv5bEfPZqY4
         th+aqVuigF/tHh2y9SHDSlhmoPRA/Z7Pk98ozusVXgeuLAPS8EE7tui6rf3Rbu8mrhOy
         tyqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=wxlJvZX7RoVmxIuljNs9mlMKiGizy+QEcMpzpxdGqcY=;
        fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=;
        b=XTPPBhcUtu+zEFZGOyUyvVKg02sDa5px60cw5uzRL19zOt6ijnEbvo952oU6j8ovpX
         hJ7yAm25I6F4odHYLp8HrSI4/gXsnu4KZWHPMYKdUiYTxUNC51MmQG8xKb0ZqrRPcRni
         975+I2O6Qnn0/ShJiFOJwWiCOh/9SX3bZ9Mm9iayaSg0NFlzHbSD0Hq7nn7L6oB87V0K
         PdMgLDfGKCkjP3tDM6NldWdz2Ezbc57iSyyZjFHnV9/jB+GXE64eJJ3tRd5h7GHWFUJw
         r28c+5414EVa+0d7WcodijzL/MDV03DPaVp7w3P0ywTFFamGkl4N5jd5Zxh50XdXDAjd
         cX3A==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id a640c23a62f3a-af47d14ab95si371666b.1.2025.07.23.14.12.30
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 23 Jul 2025 14:12:30 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Wed, 23 Jul 2025 21:12:26 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Make pathological transactions with more than
 2500 legacy signature operations non-standard
Message-ID: <wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx866JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU=@protonmail.com>
In-Reply-To: <CALZpt+EHhUdJPu1Ydn+9QmccvMuRW-m+VcgG5qp-pEbO4AxGyQ@mail.gmail.com>
References: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@protonmail.com> <eb191c75-e245-4c40-8288-1d102477ccfdn@googlegroups.com> <MAx6mRL1iR7e7zNHtWs39IvM2y0rSJQxLZEEyic_LAcA-QzuuursCSRH8zuTaqum8rMXYFdyJZO6wGcX5dRP7gyx8iwZNgjFP5VDNxYEJLw=@protonmail.com> <e27c5b87-3be2-4ed0-9000-84822ca84c23n@googlegroups.com> <baUD_4coLcyQ0vkoOaIzl8KFWTo3Mer27YYzDDCbffdbiJyOktRD_Y5u5OkfzSA3m9uJ84EZuEdbybdKTDElD_8_70vbJimDgen252hVRIo=@protonmail.com> <CALZpt+EHhUdJPu1Ydn+9QmccvMuRW-m+VcgG5qp-pEbO4AxGyQ@mail.gmail.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: e24753ae22b4ab8533c2974878f84a1786b09250
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

--b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Antoine,

Attempting to contribute a non-standard input to a multiparty transaction c=
reation protocol is not an "attack" nor something you can prevent participa=
nt are not trusted. I am not sure where this is going.

Regarding the test at the end of your email, it is spending p2wsh inputs. T=
he newly introduced limit only applies to inputs spending legacy scripts. T=
hat said, it is indeed possible to create a transaction which is standard t=
oday but would run in this new limit. Otherwise introducing the limit would=
n't be necessary in the first place. My point is just that any such transac=
tion would be pathological. Examples are constructed in the tests of the PR=
 linked in OP. Your test, although it's using Segwit input, is also a good =
example of the type of pathological transactions i am talking about.

Best,
Antoine

On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard <antoine.riard@gmail.c=
om> wrote:

> Hi Poinsot,
>
>> Could you please clearly describe the "attack" with a clear threat model=
? I don't think what you describe is an issue under any
>> realistic threat model, much less how it would only materialize with BIP=
54's sigop limit but not with the existing sigop limit.
>
> Yes, for sure. So let's say you have a Coinjoin collaborated among 10 pse=
udonymous peers (...they rely as much as they can on
> the chain as the source of truth to preserve the overall pseudonymity so =
hardness to evaluate "trustworthiness" of a specific peer),
> where there is a single peer randomly designated as the coordinator. Each=
 peer contributes an input towards the common transaction.
>
> Let says the 1st participant is the coordinator, the 2nd to 9th participa=
nt are participants only contributing P2WPKH, for which
> the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participan=
t deliberately contribute a legacy input with empty junk
> OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MULTISIG wh=
ile being space-wise efficient.
>
> This legacy input is of minimal satoshi value (<=3D to inputs 1th to 9th =
while still > to Coinjoin protocol-defined limit),
> so the cost for the malicious 10th participant is minimized. All the inpu=
ts are assembled together in the multi-party transaction,
> however this transaction is now policy invalid in reason of MAX_TX_LEGACY=
_SIGOPS due to the single redeem script contributed by
> the 10th input.
>
> In the lack of awareness of the policy rule by the coordinator, or by any=
 participant if the Coinkoin protocol is fully distributed
> among participants, identifying the source of error can be a hard task. U=
nless the latest flavour of the policy rules are run, it
> might be just a generic policy error caught by the coordinator, or even w=
orst if the transaction is just flow with a raw TX message,
> in the lack of REJCT msgs to discover the source of non-propagation.
>
> Of course there is always the option to bypass the policy rules by reachi=
ng out to a miner private API, though if you''re doing
> a coinjoin it is less than optimal to maximize confidentiality of the flo=
w.
>
> Note this threat model has been already considered in the past here:
> that://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail=
/lightning-dev/2021-May/003033.txt
>
> Those are the reasons e.g for lightning only segwit inputs are accepted t=
o be contributed for a collaborative transaction and
> other limits are checked to sanitize the flow towards policy rule ("MAY f=
ail the negotiation if `script` is non-standard" at
> `tx_add_output` reception).
>
> Currently, the problem would exist though only if the built Coinjoin tran=
saction would have more than 80k sigops. The reduction
> to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in the cost =
to mount that DoS attack for an adversary. I think it's
> cheaper fee-wise to contribute an input to reach the ~2500 limit, than th=
e upper 80k limit itself.
>
> In my view, it's not really the responsibility of a full-node to care abo=
ut that kind of issues for downstream softwares. However,
> mentioning in release notes that the limit might affect tx collaborative =
construction for downstream softwares devs and that action
> might have to be taken at their appreciation (as they're the ones with th=
e best know-how about their protocols) can be a courteous
> note. IMHO, assuming those kinds of threat models are realistic, it would=
 be welcome to be more verbose everytime there is a
> _tightening_ of the policy rules. Even if the _tightening_ is in view of =
a future consensus change, there are all the transitory
> phase during which there are more exposures to those kinds of DoS.
>
>> The BIP54 specifications are written from the perspective of an implemen=
ter and clearly states "count the number of [sigops] in
>> the input scriptSig and previous output's scriptPubKey". Signature opera=
tions in these fields preceded Segwit (which requires the
>> scriptSig to be empty and the prevout's scriptPubKey to be pushonly).
>
> Yes, I read again BIP141 around writing my previous email. BIP141 clearly=
 says that "a push of a version byte, plus a push of a
> witness program. The scriptSig must be exactly empty or validation fails.=
" So unless you have a different validation logic which
> is introduced in an unknown future for any segwit spends (OP_01 to OP_16 =
version byte + a push of the witness program), I don't
> see how the limit could be understood to be applied to segwit spends, and=
 more concerning implemented by mistake to concern segwit
> spends. For bitcoin core, the code is very proper here in `VerifyScript` =
and commented accordingly.
>
> I'm still thinking it would be good BIP stylistic to have BIP54 making an=
 explicit referral to BIP141 to define "legacy" inputs
> by opposition to "segwit" inputs, which have a precise technical definiti=
on. Less a BIP is ambiguous, better it is.
>
>> Any remotely sane transaction would run into the standardness size limit=
 before running into this limit.
>
> No, I'm not sure of that. I was having fun recently with scriptsig junkin=
g transaction leveraring OP_CHECKMULTISIG:
> https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a6=
8da9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756=
547R42
> It sounds you can generate transaction which are perfectly standard (i.e =
under MAX_STANDARD_TX_WEIGHT) with a very high
> number of sigops stuffed within. I don't remember checking all the policy=
 rule scenarios, but MAX_STANDAD_TX_WEIGHT is
> one of the rule you _cannot_ disable or turn off on the CLI iirc.
>
> Best,
> Riard
> OTS hash: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac7=
1
>
> Le lun. 14 juil. 2025 =C3=A0 15:44, Antoine Poinsot <darosior@protonmail.=
com> a =C3=A9crit :
>
>> Hi Antoine,
>>
>> Could you please clearly describe the "attack" with a clear threat model=
? I don't think what you describe is an issue under any realistic threat mo=
del, much less how it would only materialize with BIP54's sigop limit but n=
ot with the existing sigop limit.
>>
>>> Anyway, the current BIP54 says the following nothing about legacy input=
s:
>>
>> The BIP54 specifications are written from the perspective of an implemen=
ter and clearly states "count the number of [sigops] in the input scriptSig=
 and previous output's scriptPubKey". Signature operations in these fields =
preceded Segwit (which requires the scriptSig to be empty and the prevout's=
 scriptPubKey to be pushonly).
>>
>>> I think there are some implications about all of this for some use-case=
s designers,
>>> e.g for massive Coinjoin
>>
>> Any remotely sane transaction would run into the standardness size limit=
 before running into this limit. Only a pathological transaction which trie=
s to increase its validation cost may run into this limit while being stand=
ard according to today's Core policy. See https://github.com/bitcoin/bips/b=
lob/master/bip-0054.md#user-content-fn-7-21829941cd04259d86862ad3baa11d05.
>>
>> Best,
>> Antoine
>> On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard <antoine.riard@gm=
ail.com> wrote:
>>
>>> Hi Poinsot,
>>>
>>> Not necessarily, if you go to multi-sign the first input of your second=
-stage txn with
>>> SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence ar=
e not commited.
>>> The second input can be a legacy input, even if it's altered in-flight =
(e.g flipping
>>> the S component of the ECDSA sig), it's breaking your sig hash for the =
second input,
>>> but not the sighash for the "contract" multi-signed input. Very practic=
al for doing
>>> unilateral fee-bumping.
>>>
>>> It's a problem if you do multi-stage for an off-chain construction, as =
the third order
>>> tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and impl=
icitly the
>>> parent txid of the malleable second input.
>>>
>>> ...
>>>
>>> Anyway, the current BIP54 says the following nothing about legacy input=
s:
>>>
>>> "A limit is set on the number of potentially executed signature operati=
ons in validating
>>> a transaction. It applies to all transactions in the block except the c=
oinbase transaction.
>>> For each input in the transaction, count the number of CHECKSIG and CHE=
CKMULTISIG in the
>>> input scriptSig and previous output's scriptPubKey, including the P2SH =
redeemScript".
>>>
>>> I do think it would be clearer to say that Segwit spends are logically =
excluded due
>>> to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size(=
) !=3D 0 in
>>> `VerifyScript()`) and b) a witness program must be a data push and as s=
uch it's
>>> never a scriptCode that can contain a CHECKSIG ops. Accounting is impli=
citly always
>>> 0 for Segwit spends.
>>>
>>> There is no definition of what make a spend a "legacy" input, other tha=
n it's not
>>> a Segwit spend. Technically, the CHECKSIG operations are committed in t=
he witness
>>> program, which is itself part of the scriptPubkey... While indeed, curr=
ently the code
>>> is properly dissociating the verifcation of the legacy spends from the =
witness program,
>>> it's hard to say the limit is correctly implemented in the complete lac=
k of available code.
>>>
>>> The limit could be implemented in EvalScript(), but I'm not sure it's e=
xactly what
>>> you have in mind. Thanks by advance if there is code and specification =
defining
>>> more precisly what is understood as a legacy input under this BIP propo=
sal.
>>>
>>> ...
>>>
>>> I think there are some implications about all of this for some use-case=
s designers,
>>> e.g for massive Coinjoin, if in the collaborative transaction construct=
ion any party
>>> proposes a scriptpubkey with a huge number of sigs to reach the limit, =
now if you
>>> don't verify the script sanity against this new rule, you might have co=
ntributed
>>> an input in a transaction that is never going to be valid. Some kind of=
 denial-of-service,
>>> and the reason initially opt-in rbf was proposed to be remove.
>>>
>>> While this is not a concern for lightning (bc the dual funding spec exp=
lictly
>>> requests segwit input at `tx_add_input` reception), I'm not sure for an=
y coinjoin
>>> or multi-party tx construction stuff that might be affected by a new Do=
S vector
>>> as soon as this starts to be a policy rule spread substantially on the =
network.
>>>
>>> It's not to say that this limit shouldn't be deployed, but in my opinio=
n it's
>>> wise to advertise more towards multi-party use-cases maintainers and de=
vs the
>>> potential implications of the deployment of this rule, as soon as it's =
policy.
>>>
>>> Best,
>>> Riard
>>> OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc=
902
>>>
>>> Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9=
crit :
>>>
>>>> This limit only concerns legacy signature operations. Off-chain constr=
uctions use Segwit inputs, as they would be trivially broken by txid mallea=
bility otherwise.
>>>>
>>>> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard <antoin...@gmail.=
com> wrote:
>>>>
>>>>> Hi Poinsot,
>>>>>
>>>>> Thanks for the collection of historical txn hitting the proposed new =
limit.
>>>>>
>>>>> The only long-term downside coming immediately out of mind, if the ru=
le becomes consensus
>>>>> in the future, it's the implicit limitation it would make on the mult=
i-party dimensions
>>>>> of off-chain constructions. In the past, I made really rough math for=
 1000-sized participants
>>>>> payments pools, where for the funding_tx, you have the 1000 participa=
nts contributing
>>>>> one input with one sig for each [0].
>>>>>
>>>>> In my understanding the new limit of 2500 signatures operation would =
make a hard-limit
>>>>> for the number of participants entering in such construction, without=
 other tricks that
>>>>> are consuming more block space. One can note the downside on funding =
tx of high-order
>>>>> off-chain construction, if a max tx size consensus limit is introduce=
d in the future.
>>>>>
>>>>> Of course, I do not deny the DoS rational of introducing the 2500 sig=
 limit and it's
>>>>> very needed. At the same time, we should be careful of not closing to=
o much doors for
>>>>> future off-chain constructions and long-term tx throughput scalabilit=
y.
>>>>>
>>>>> I do believe, it's always technically possible in the future to intro=
duce new opcode
>>>>> or segwit versions scripts (e.g grafroot or entroot-based pool constr=
uction), which
>>>>> wouldn't be subject to the new limit, and as such more scalable. If I=
'm correct, I
>>>>> think it's all about how the limit is implemented to parse current sc=
ripts to be
>>>>> spent.
>>>>>
>>>>> But it's hard to say without code available to review and reason. May=
 I kindly note
>>>>> there is no reference implementation attached in the current BIP54 do=
cument [1]. Even,
>>>>> if it's often updated, it's always fruitful to have code under the ey=
es for review.
>>>>>
>>>>> This might be the kind of concern (very) far down the line...but pres=
erving the
>>>>> evolvability of the consensus rules is a good property to care about,=
 in my humble
>>>>> opinion.
>>>>>
>>>>> Best,
>>>>> Riard
>>>>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2
>>>>>
>>>>> [0] [https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@ma=
il.gmail.com/](https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i=
5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/)
>>>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
>>>>>
>>>>> Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =
=C3=A9crit :
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> To mitigate high block validation time, BIP54 proposes to make trans=
actions which require more than
>>>>>> 2500 legacy signature operations invalid by consensus. The 2500 figu=
re was chosen as the tightest
>>>>>> value that did not make any non-pathological currently standard tran=
saction invalid.
>>>>>>
>>>>>> No transaction in Bitcoin's history would have both hit the BIP54 si=
gop limit and been standard
>>>>>> according to today's Bitcoin Core policy[^0]. But what happened in t=
he past doesn't matter as much
>>>>>> as the fact that it is possible today to create a pathological stand=
ard transaction that is
>>>>>> BIP54-invalid.
>>>>>>
>>>>>> This opens up a major DoS vector against unupgraded miners if BIP54 =
ever gets activated in these
>>>>>> conditions. Therefore i propose to make such transactions non-standa=
rd and hold off activation of
>>>>>> BIP54 until we have good reasons to believe that the vast majority o=
f the hashrate won't create a
>>>>>> block containing such a transaction.
>>>>>>
>>>>>> Doing so gives better guarantees in case BIP54 is ever considered fo=
r activation, and comes at
>>>>>> virtually no cost since these pathological transactions have never b=
een used and serve no purpose
>>>>>> beyond increasing the cost of validation. Bitcoin Core PR #32521 imp=
lements this change, which i
>>>>>> hope to get into the upcoming 30.0 release as well as backported to =
previous versions.
>>>>>>
>>>>>> Best,
>>>>>> Antoine Poinsot
>>>>>>
>>>>>> [^0]: Here the full list of historical transactions that would have =
hit the BIP54 sigops limit:
>>>>>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
>>>>>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
>>>>>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
>>>>>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
>>>>>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
>>>>>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
>>>>>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
>>>>>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
>>>>>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
>>>>>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
>>>>>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
>>>>>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
>>>>>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
>>>>>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
>>>>>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
>>>>>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
>>>>>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
>>>>>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
>>>>>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
>>>>>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
>>>>>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
>>>>>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
>>>>>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
>>>>>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
>>>>>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
>>>>>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
>>>>>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
>>>>>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
>>>>>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
>>>>>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
>>>>>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
>>>>>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
>>>>>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
>>>>>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
>>>>>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
>>>>>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
>>>>>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
>>>>>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
>>>>>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
>>>>>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
>>>>>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
>>>>>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
>>>>>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
>>>>>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
>>>>>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
>>>>>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
>>>>>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
>>>>>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
>>>>>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
>>>>>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
>>>>>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
>>>>>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
>>>>>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
>>>>>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
>>>>>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
>>>>>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
>>>>>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
>>>>>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
>>>>>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
>>>>>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
>>>>>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
>>>>>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
>>>>>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
>>>>>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
>>>>>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
>>>>>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
>>>>>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
>>>>>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
>>>>>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
>>>>>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
>>>>>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
>>>>>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
>>>>>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
>>>>>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
>>>>>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
>>>>>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
>>>>>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
>>>>>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
>>>>>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
>>>>>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
>>>>>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
>>>>>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
>>>>>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
>>>>>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
>>>>>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
>>>>>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
>>>>>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
>>>>>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
>>>>>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
>>>>>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
>>>>>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
>>>>>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9
>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+...@googlegroups.com.
>>>>> To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Grou=
ps "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/bitcoin=
dev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.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/=
wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx8=
66JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU%3D%40protonmail.com.

--b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Antoine,</d=
iv><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></di=
v><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Attemptin=
g to contribute a non-standard input to a multiparty transaction creation p=
rotocol is not an "attack" nor something you can prevent participant are no=
t trusted. I am not sure where this is going.<br></div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fa=
mily: Arial, sans-serif; font-size: 14px;">Regarding the test at the end of=
 your email, it is spending p2wsh inputs. The newly introduced limit only a=
pplies to inputs spending legacy scripts. That said, it is indeed possible =
to create a transaction which is standard today but would run in this new l=
imit. Otherwise introducing the limit wouldn't be necessary in the first pl=
ace. My point is just that any such transaction would be pathological. Exam=
ples are constructed in the tests of the PR linked in OP. Your test, althou=
gh it's using Segwit input, is also a good example of the type of pathologi=
cal transactions i am talking about.<br></div><div style=3D"font-family: Ar=
ial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;">Best,<br>Antoine<br></div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;" class=3D"pr=
otonmail_signature_block protonmail_signature_block-empty">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div class=3D"protonmail_quote">
        On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard &lt;antoine.ri=
ard@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div dir=3D"ltr">Hi Poinsot,<br><br>&gt; Could you please clear=
ly describe the "attack" with a clear threat model? I don't think what you =
describe is an issue under any<br>&gt; realistic threat model, much less ho=
w it would only materialize with BIP54's sigop limit but not with the exist=
ing sigop limit.<br><br>Yes, for sure. So let's say you have a Coinjoin col=
laborated among 10 pseudonymous peers (...they rely as much as they can on<=
br>the chain as the source of truth to preserve the overall pseudonymity so=
 hardness to evaluate "trustworthiness" of a specific peer),<br>where there=
 is a single peer randomly designated as the coordinator. Each peer contrib=
utes an input towards the common transaction.<br><br>Let says the 1st parti=
cipant is the coordinator, the 2nd to 9th participant are participants only=
 contributing P2WPKH, for which<br>the new MAX_TX_LEGACY_SIGOPS is not a pr=
oblem at all. The 10th participant deliberately contribute a legacy input w=
ith empty junk<br>OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS=
_PER_MULTISIG while being space-wise efficient.<br><br>This legacy input is=
 of minimal satoshi value (&lt;=3D to inputs 1th to 9th while still &gt; to=
 Coinjoin protocol-defined limit),<br>so the cost for the malicious 10th pa=
rticipant is minimized. All the inputs are assembled together in the multi-=
party transaction,<br>however this transaction is now policy invalid in rea=
son of MAX_TX_LEGACY_SIGOPS due to the single redeem script contributed by<=
br>the 10th input.<br><br>In the lack of awareness of the policy rule by th=
e coordinator, or by any participant if the Coinkoin protocol is fully dist=
ributed<br>among participants, identifying the source of error can be a har=
d task. Unless the latest flavour of the policy rules are run, it<br>might =
be just a generic policy error caught by the coordinator, or even worst if =
the transaction is just flow with a raw TX message,<br>in the lack of REJCT=
 msgs to discover the source of non-propagation.<br> <br>Of course there is=
 always the option to bypass the policy rules by reaching out to a miner pr=
ivate API, though if you''re doing<br>a coinjoin it is less than optimal to=
 maximize confidentiality of the flow.<br><br>Note this threat model has be=
en already considered in the past here:<br>that://<a href=3D"http://diyhpl.=
us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2=
021-May/003033.txt" target=3D"_blank" rel=3D"noreferrer nofollow noopener">=
diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightnin=
g-dev/2021-May/003033.txt</a><br><br>Those are the reasons e.g for lightnin=
g only segwit inputs are accepted to be contributed for a collaborative tra=
nsaction and<br>other limits are checked to sanitize the flow towards polic=
y rule ("MAY fail the negotiation if `script` is non-standard" at<br>`tx_ad=
d_output` reception).<br><br>Currently, the problem would exist though only=
 if the built Coinjoin transaction would have more than 80k sigops. The red=
uction<br>to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in t=
he cost to mount that DoS attack for an adversary. I think it's<br>cheaper =
fee-wise to contribute an input to reach the ~2500 limit, than the upper 80=
k limit itself.<br><br>In my view, it's not really the responsibility of a =
full-node to care about that kind of issues for downstream softwares. Howev=
er,<br>mentioning in release notes that the limit might affect tx collabora=
tive construction for downstream softwares devs and that action<br>might ha=
ve to be taken at their appreciation (as they're the ones with the best kno=
w-how about their protocols) can be a courteous<br>note. IMHO, assuming tho=
se kinds of threat models are realistic, it would be welcome to be more ver=
bose everytime there is a<br>_tightening_ of the policy rules. Even if the =
_tightening_ is in view of a future consensus change, there are all the tra=
nsitory<br>phase during which there are more exposures to those kinds of Do=
S.<br><br>&gt; The BIP54 specifications are written from the perspective of=
 an implementer and clearly states "count the number of [sigops] in<br>&gt;=
 the input scriptSig and previous output's scriptPubKey". Signature operati=
ons in these fields preceded Segwit (which requires the<br>&gt; scriptSig t=
o be empty and the prevout's scriptPubKey to be pushonly).<br><br>Yes, I re=
ad again BIP141 around writing my previous email. BIP141 clearly says that =
"a push of a version byte, plus a push of a<br>witness program. The scriptS=
ig must be exactly empty or validation fails." So unless you have a differe=
nt validation logic which<br>is introduced in an unknown future for any seg=
wit spends (OP_01 to OP_16 version byte + a push of the witness program), I=
 don't<br>see how the limit could be understood to be applied to segwit spe=
nds, and more concerning implemented by mistake to concern segwit<br>spends=
. For bitcoin core, the code is very proper here in `VerifyScript` and comm=
ented accordingly.<br><br>I'm still thinking it would be good BIP stylistic=
 to have BIP54 making an explicit referral to BIP141 to define "legacy" inp=
uts<br>by opposition to "segwit" inputs, which have a precise technical def=
inition. Less a BIP is ambiguous, better it is.<br><br>&gt; Any remotely sa=
ne transaction would run into the standardness size limit before running in=
to this limit. <br><br>No, I'm not sure of that. I was having fun recently =
with scriptsig junking transaction leveraring OP_CHECKMULTISIG:<br><a href=
=3D"https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73=
a68da9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b7=
56547R42" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://gi=
thub.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#dif=
f-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42</a><b=
r>It sounds you can generate transaction which are perfectly standard (i.e =
under MAX_STANDARD_TX_WEIGHT) with a very high<br>number of sigops stuffed =
within. I don't remember checking all the policy rule scenarios, but MAX_ST=
ANDAD_TX_WEIGHT is<br>one of the rule you _cannot_ disable or turn off on t=
he CLI iirc.<br><br>Best,<br>Riard<br>OTS hash: 91fad050b8b9ffdc0a25f997cc6=
f77e701e039ba4415a9a7cfe7809f1aafac71<br></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le lun. 14 j=
uil. 2025 =C3=A0 15:44, Antoine Poinsot &lt;<a href=3D"mailto:darosior@prot=
onmail.com" rel=3D"noreferrer nofollow noopener">darosior@protonmail.com</a=
>&gt; a =C3=A9crit :<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div>Hi Antoine,</div><div style=3D"font-family:Arial,sans-serif;font-=
size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><di=
v style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);bac=
kground-color:rgb(255,255,255)">Could you please clearly describe the "atta=
ck" with a clear threat model? I don't think what you describe is an issue =
under any realistic threat model, much less how it would only materialize w=
ith BIP54's sigop limit but not with the existing sigop limit.<br></div><di=
v style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);bac=
kground-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,s=
ans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)=
"><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-top-co=
lor:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-colo=
r:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div><span><sp=
an>Anyway, the current BIP54 says the following nothing about legacy inputs=
:</span></span></div><div><span><span></span></span></div></blockquote></di=
v><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0=
);background-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px">
    <div>

            </div>

            <div>

            </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">The BIP54 specif=
ications are written from the perspective of an implementer and clearly sta=
tes "count the number of [sigops] in the input
scriptSig and previous output's scriptPubKey". Signature operations in thes=
e fields preceded Segwit (which requires the scriptSig to be empty and the =
prevout's scriptPubKey to be pushonly).</div><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px"><br></div><blockquote style=3D"border-left:3px=
 solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-colo=
r:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:10px;c=
olor:rgb(102,102,102)"><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">I think there are some implications about all of this for some use-c=
ases designers,<br></div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px">e.g for massive Coinjoin</div></blockquote><br><div><span style=3D=
"font-family:Arial,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,=
0);background-color:rgb(255,255,255)">Any remotely sane transaction would r=
un</span> into the standardness size limit before running into this limit. =
Only a pathological transaction which tries to increase its validation cost=
 may run into this limit while being standard according to today's Core pol=
icy. See <span><a rel=3D"noreferrer nofollow noopener" href=3D"https://gith=
ub.com/bitcoin/bips/blob/master/bip-0054.md#user-content-fn-7-21829941cd042=
59d86862ad3baa11d05" target=3D"_blank">https://github.com/bitcoin/bips/blob=
/master/bip-0054.md#user-content-fn-7-21829941cd04259d86862ad3baa11d05</a><=
/span>.</div><div><br></div><div>Best,<br>Antoine<br></div><div>
        On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard &lt;<a href=
=3D"mailto:antoine.riard@gmail.com" target=3D"_blank" rel=3D"noreferrer nof=
ollow noopener">antoine.riard@gmail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            Hi Poinsot,<br><br>Not necessarily, if you go to multi-sign the=
 first input of your second-stage txn with<br>SIGHASH_SINGLE | ANYONECANPAY=
, the hashPrevouts and the hashSequence are not commited.<br>The second inp=
ut can be a legacy input, even if it's altered in-flight (e.g flipping<br>t=
he S component of the ECDSA sig), it's breaking your sig hash for the secon=
d input,<br>but not the sighash for the "contract" multi-signed input. Very=
 practical for doing<br>unilateral fee-bumping.<br><br>It's a problem if yo=
u do multi-stage for an off-chain construction, as the third order<br>tx, e=
ven with SIGHASH_SINGLE would commit to `outpoint` field, and implicitly th=
e<br>parent txid of the malleable second input.<br><br>...<br><br>Anyway, t=
he current BIP54 says the following nothing about legacy inputs:<br><br>"A =
limit is set on the number of potentially executed signature operations in =
validating<br>a transaction. It applies to all transactions in the block ex=
cept the coinbase transaction.<br>For each input in the transaction, count =
the number of CHECKSIG and CHECKMULTISIG in the<br>input scriptSig and prev=
ious output's scriptPubKey, including the P2SH redeemScript".<br><br>I do t=
hink it would be clearer to say that Segwit spends are logically excluded d=
ue<br>to a) a Segwit spend's scriptSig must be always empty (`scriptSig.siz=
e() !=3D 0 in<br>`VerifyScript()`) and b) a witness program must be a data =
push and as such it's<br>never a scriptCode that can contain a CHECKSIG ops=
. Accounting is implicitly always<br>0 for Segwit spends.<br><br>There is n=
o definition of what make a spend a "legacy" input, other than it's not<br>=
a Segwit spend. Technically, the CHECKSIG operations are committed in the w=
itness<br>program, which is itself part of the scriptPubkey... While indeed=
, currently the code<br>is properly dissociating the verifcation of the leg=
acy spends from the witness program,<br>it's hard to say the limit is corre=
ctly implemented in the complete lack of available code.<br><br>The limit c=
ould be implemented in EvalScript(), but I'm not sure it's exactly what<br>=
you have in mind. Thanks by advance if there is code and specification defi=
ning<br>more precisly what is understood as a legacy input under this BIP p=
roposal.<br><br>...<br><br>I think there are some implications about all of=
 this for some use-cases designers,<br>e.g for massive Coinjoin, if in the =
collaborative transaction construction any party<br>proposes a scriptpubkey=
 with a huge number of sigs to reach the limit, now if you<br>don't verify =
the script sanity against this new rule, you might have contributed<br>an i=
nput in a transaction that is never going to be valid. Some kind of denial-=
of-service,<br>and the reason initially opt-in rbf was proposed to be remov=
e.<br><br>While this is not a concern for lightning (bc the dual funding sp=
ec explictly<br>requests segwit input at `tx_add_input` reception), I'm not=
 sure for any coinjoin<br>or multi-party tx construction stuff that might b=
e affected by a new DoS vector<br>as soon as this starts to be a policy rul=
e spread substantially on the network.<br><br>It's not to say that this lim=
it shouldn't be deployed, but in my opinion it's<br>wise to advertise more =
towards multi-party use-cases maintainers and devs the<br>potential implica=
tions of the deployment of this rule, as soon as it's policy.<br><br>Best,<=
br>Riard<br>OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06b=
bbac2afc902<br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
attr">Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=
=A9crit :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px">This limit only concer=
ns legacy signature operations. Off-chain constructions use Segwit inputs, =
as they would be trivially broken by txid malleability otherwise.<br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>

            </div>

            <div>

            </div>
</div>
<div></div><div>
        On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard &lt;<a rel=3D"=
noreferrer nofollow noopener">antoin...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            Hi Poinsot,<br><br>Thanks for the collection of historical txn =
hitting the proposed new limit.<br><br>The only long-term downside coming i=
mmediately out of mind, if the rule becomes consensus<br>in the future, it'=
s the implicit limitation it would make on the multi-party dimensions<br>of=
 off-chain constructions. In the past, I made really rough math for 1000-si=
zed participants<br>payments pools, where for the funding_tx, you have the =
1000 participants contributing<br>one input with one sig for each [0]. <br>=
<br>In my understanding the new limit of 2500 signatures operation would ma=
ke a hard-limit<br>for the number of participants entering in such construc=
tion, without other tricks that<br>are consuming more block space. One can =
note the downside on funding tx of high-order<br>off-chain construction, if=
 a max tx size consensus limit is introduced in the future.<br><br>Of cours=
e, I do not deny the DoS rational of introducing the 2500 sig limit and it'=
s<br>very needed. At the same time, we should be careful of not closing too=
 much doors for<br>future off-chain constructions and long-term tx throughp=
ut scalability.<br><br>I do believe, it's always technically possible in th=
e future to introduce new opcode<br>or segwit versions scripts (e.g grafroo=
t or entroot-based pool construction), which<br>wouldn't be subject to the =
new limit, and as such more scalable. If I'm correct, I<br>think it's all a=
bout how the limit is implemented to parse current scripts to be<br>spent.<=
br><br>But it's hard to say without code available to review and reason. Ma=
y I kindly note<br>there is no reference implementation attached in the cur=
rent BIP54 document [1]. Even,<br>if it's often updated, it's always fruitf=
ul to have code under the eyes for review.<br><br>This might be the kind of=
 concern (very) far down the line...but preserving the<br>evolvability of t=
he consensus rules is a good property to care about, in my humble<br>opinio=
n.<br><br>Best,<br>Riard<br>OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0a=
db2<br><br>[0] <a href=3D"https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd=
-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/" rel=3D"noreferrer nofo=
llow noopener" target=3D"_blank">https://gnusha.org/pi/bitcoindev/CALZpt+E+=
eKKtOXd-8A6oThw-...@mail.gmail.com/</a><br>[1] <a href=3D"https://github.co=
m/bitcoin/bips/blob/master/bip-0054.md" rel=3D"noreferrer nofollow noopener=
" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0054.md=
</a><br><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att=
r">Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3=
=A9crit :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi eve=
ryone,
<br>
<br>To mitigate high block validation time, BIP54 proposes to make transact=
ions which require more than
<br>2500 legacy signature operations invalid by consensus. The 2500 figure =
was chosen as the tightest
<br>value that did not make any non-pathological currently standard transac=
tion invalid.
<br>
<br>No transaction in Bitcoin's history would have both hit the BIP54 sigop=
 limit and been standard
<br>according to today's Bitcoin Core policy[^0]. But what happened in the =
past doesn't matter as much
<br>as the fact that it is possible today to create a pathological standard=
 transaction that is
<br>BIP54-invalid.
<br>
<br>This opens up a major DoS vector against unupgraded miners if BIP54 eve=
r gets activated in these
<br>conditions. Therefore i propose to make such transactions non-standard =
and hold off activation of
<br>BIP54 until we have good reasons to believe that the vast majority of t=
he hashrate won't create a
<br>block containing such a transaction.
<br>
<br>Doing so gives better guarantees in case BIP54 is ever considered for a=
ctivation, and comes at
<br>virtually no cost since these pathological transactions have never been=
 used and serve no purpose
<br>beyond increasing the cost of validation. Bitcoin Core PR #32521 implem=
ents this change, which i
<br>hope to get into the upcoming 30.0 release as well as backported to pre=
vious versions.
<br>
<br>Best,
<br>Antoine Poinsot
<br>
<br>[^0]: Here the full list of historical transactions that would have hit=
 the BIP54 sigops limit:
<br>    - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
<br>    - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
<br>    - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
<br>    - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
<br>    - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
<br>    - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
<br>    - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
<br>    - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
<br>    - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
<br>    - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
<br>    - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
<br>    - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
<br>    - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
<br>    - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
<br>    - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
<br>    - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
<br>    - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
<br>    - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
<br>    - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
<br>    - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
<br>    - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
<br>    - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
<br>    - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
<br>    - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
<br>    - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
<br>    - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
<br>    - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
<br>    - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
<br>    - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
<br>    - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
<br>    - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
<br>    - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
<br>    - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
<br>    - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
<br>    - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
<br>    - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
<br>    - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
<br>    - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
<br>    - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
<br>    - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
<br>    - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
<br>    - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
<br>    - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
<br>    - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
<br>    - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
<br>    - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
<br>    - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
<br>    - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
<br>    - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
<br>    - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
<br>    - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
<br>    - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
<br>    - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
<br>    - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
<br>    - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
<br>    - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
<br>    - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
<br>    - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
<br>    - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
<br>    - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
<br>    - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
<br>    - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
<br>    - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
<br>    - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
<br>    - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
<br>    - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
<br>    - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
<br>    - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
<br>    - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
<br>    - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
<br>    - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
<br>    - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
<br>    - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
<br>    - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
<br>    - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
<br>    - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
<br>    - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
<br>    - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
<br>    - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
<br>    - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
<br>    - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
<br>    - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
<br>    - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
<br>    - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
<br>    - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
<br>    - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
<br>    - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
<br>    - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
<br>    - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
<br>    - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
<br>    - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
<br>    - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9
<br></blockquote></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://groups.google.com/=
d/msgid/bitcoindev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank">https://groups.google.com/=
d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDu=
SxvdSNEdqx866JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx8=
66JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU%3D%40protonmail.com</a>.<br />

--b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4--