path: root/5e/5abf4e8ec9fe2a11aff2a3c49f1b0e4220b850

Delivery-date: Fri, 25 Jul 2025 09:56:41 -0700
Received: from mail-qt1-f183.google.com ([209.85.160.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBPHOR3CAMGQEAFHZIFY@googlegroups.com>)
	id 1ufLio-0007Av-PC
	for bitcoindev@gnusha.org; Fri, 25 Jul 2025 09:56:41 -0700
Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4ab401e333bsf71502761cf.1
        for <bitcoindev@gnusha.org>; Fri, 25 Jul 2025 09:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1753462592; x=1754067392; 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=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=;
        b=AQcLGo7E4WDY/RQpbbjPhmdRTL5X4z5NxD0X0MEmlsbdc3+EXQAuwQ8xEqJuVkAdbQ
         z0VLNkDDC19F6msioO7zpuzG3sE+M6z+tHQiXd0DaQ+HyP0uqkwHj261k1g8qOoZsdtJ
         PqjNUDTxuNI2TLVtQo93dcAX65wtyCiaKGr+bBrovs3RAGoJHQUKCU4/2Ki7WdvXD0b/
         R/wmST6k0vzZaIspkxvaFKwTNBvLL1wSRp9OUrQZC1iCsRBWbPefTvt5jBdc9ErDZnaD
         w9m6W7z2Gs6tRBq6S6NgVbuh+Qf6nuYU/tVOFagezm/8pkMDeV5EwMdMrnwKsqsZ7DhP
         BKDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1753462592; x=1754067392; 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=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=;
        b=Jb0uBcGdjeG4RTPiSclB/0vrr/vF/mFw3b0sZ3HTL3ZsGxOQgtTqkVqtt08M9II3S4
         ACPIdtyO60BUok3/l46GMuTriB0U5ydKABpIKUoYg1WYMx74OWQyq8jjWP7I/4fldNT4
         3j8y6Xt3BNAZ9sh76mI4W1eI3unpibOfUGJUuw2D2QpD+6CrLuQeu2EW8/mIVIQZjTco
         XUEGNjCc2XD1KrR6OY7s6nDsjyXPECpQY5di33UrEuyVpnDCOi2VpF6CYaPezRdadZec
         Jy4hRjmesrTL/72vYzoJbs7q9+FcoYmnxPIzOqfaNySwQgsLwb1IXM+HLVC63gGfWbGa
         D3zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753462592; x=1754067392;
        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=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=;
        b=OSIPa3UyYJ3ocrpIts833HcfZbVgIZ3twESDxVin+ZDX5saj5/Iw0nOaIeJnUnuo2I
         qNfaDkXkAqQ5o5/BHRJU4jef67hVEPzUp4dRQgr9Q0DjtRpB3jbHRPStgqkasJWmqtUh
         veEjwPavfCPQgt3tr9B5QBBA9mfdcK0b2JPexCWmUi6pDX+t8eUiWkGbzbwKEfs85gA6
         8L2/B21wkeIsm8pVp+LCeg9ttNqeCn93VvHM2baNuWLlRqVRVSsXwOvEy2GOWZVM6hbU
         e52Y/Yui99bx+30goTfKTLdzxOseOPCuac9NegJCnITpWkF+QoZSW8S6I3HXqhkp+NOI
         Pksg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUesqNDtyTPOcUhR7Poj4Iq1lNmxIK1tWiPs2vlLCP09nJx0RumU037WTukyHE3h96IrW3EGdZLAez7@gnusha.org
X-Gm-Message-State: AOJu0YyscgLdYMHFAsHS4ZuN9pWaZeNnDofvVKs2pMyJOVpYvsMmit2l
	H6abi9CcCGS9+/r51SSo+E1QMkY81gFevLwRcanwacRVKHfd0NF8h4sZ
X-Google-Smtp-Source: AGHT+IH8wn/azt0TQPVkdE9c3fgIxPzhPdwGc8g7d4HOgjItYc3TrEecypdcZ6wdIWhu+fR9n4CBYg==
X-Received: by 2002:ad4:5aae:0:b0:6fa:a5c9:2ee7 with SMTP id 6a1803df08f44-70713bb257cmr83638196d6.8.1753462592204;
        Fri, 25 Jul 2025 09:56:32 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe7SdzZZEskfK0kQCAeHa1tzxxOeTvkQ/9wKiW8WhzKhg==
Received: by 2002:a05:622a:607:b0:4ab:6f41:1efe with SMTP id
 d75a77b69052e-4ae7bbd6630ls45865661cf.0.-pod-prod-01-us; Fri, 25 Jul 2025
 09:56:28 -0700 (PDT)
X-Received: by 2002:a05:620a:8cf:b0:7e3:46da:9e2f with SMTP id af79cd13be357-7e63bfa932dmr175212485a.34.1753462588356;
        Fri, 25 Jul 2025 09:56:28 -0700 (PDT)
Received: by 2002:a0d:d0c4:0:b0:718:5fd:a4e7 with SMTP id 00721157ae682-719b273ca77ms7b3;
        Wed, 23 Jul 2025 10:56:29 -0700 (PDT)
X-Received: by 2002:a05:690c:3683:b0:719:5d76:74b with SMTP id 00721157ae682-719b42d1908mr49494987b3.33.1753293388276;
        Wed, 23 Jul 2025 10:56:28 -0700 (PDT)
Date: Wed, 23 Jul 2025 10:56:27 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n@googlegroups.com>
In-Reply-To: <baUD_4coLcyQ0vkoOaIzl8KFWTo3Mer27YYzDDCbffdbiJyOktRD_Y5u5OkfzSA3m9uJ84EZuEdbybdKTDElD_8_70vbJimDgen252hVRIo=@protonmail.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>
Subject: Re: [bitcoindev] Re: Make pathological transactions with more than
 2500 legacy signature operations non-standard
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_90820_1343623919.1753293387988"
X-Original-Sender: antoine.riard@gmail.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: -0.5 (/)

------=_Part_90820_1343623919.1753293387988
Content-Type: multipart/alternative; 
	boundary="----=_Part_90821_386474536.1753293387988"

------=_Part_90821_386474536.1753293387988
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Poinsot,

> Could you please clearly describe the "attack" with a clear threat model?=
=20
I don't think what you describe is an issue under any
> realistic threat model, much less how it would only materialize with=20
BIP54's sigop limit but not with the existing sigop limit.

Yes, for sure. So let's say you have a Coinjoin collaborated among 10=20
pseudonymous peers (...they rely as much as they can on
the chain as the source of truth to preserve the overall pseudonymity so=20
hardness to evaluate "trustworthiness" of a specific peer),
where there is a single peer randomly designated as the coordinator. Each=
=20
peer contributes an input towards the common transaction.

Let says the 1st participant is the coordinator, the 2nd to 9th participant=
=20
are participants only contributing P2WPKH, for which
the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participant=
=20
deliberately contribute a legacy input with empty junk
OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MULTISIG=20
while being space-wise efficient.

This legacy input is of minimal satoshi value (<=3D to inputs 1th to 9th=20
while still > to Coinjoin protocol-defined limit),
so the cost for the malicious 10th participant is minimized. All the inputs=
=20
are assembled together in the multi-party transaction,
however this transaction is now policy invalid in reason of=20
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=
=20
participant if the Coinkoin protocol is fully distributed
among participants, identifying the source of error can be a hard task.=20
Unless the latest flavour of the policy rules are run, it
might be just a generic policy error caught by the coordinator, or even=20
worst if the transaction is just flow with a raw TX message,
in the lack of REJCT msgs to discover the source of non-propagation.
=20
Of course there is always the option to bypass the policy rules by reaching=
=20
out to a miner private API, though if you''re doing
a coinjoin it is less than optimal to maximize confidentiality of the flow.

Note this threat model has been already considered in the past here:
that://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/l=
ightning-dev/2021-May/003033.txt

Those are the reasons e.g for lightning only segwit inputs are accepted to=
=20
be contributed for a collaborative transaction and
other limits are checked to sanitize the flow towards policy rule ("MAY=20
fail the negotiation if `script` is non-standard" at
`tx_add_output` reception).

Currently, the problem would exist though only if the built Coinjoin=20
transaction would have more than 80k sigops. The reduction
to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in the cost to=
=20
mount that DoS attack for an adversary. I think it's
cheaper fee-wise to contribute an input to reach the ~2500 limit, than the=
=20
upper 80k limit itself.

In my view, it's not really the responsibility of a full-node to care about=
=20
that kind of issues for downstream softwares. However,
mentioning in release notes that the limit might affect tx collaborative=20
construction for downstream softwares devs and that action
might have to be taken at their appreciation (as they're the ones with the=
=20
best know-how about their protocols) can be a courteous
note. IMHO, assuming those kinds of threat models are realistic, it would=
=20
be welcome to be more verbose everytime there is a
_tightening_ of the policy rules. Even if the _tightening_ is in view of a=
=20
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=20
implementer and clearly states "count the number of [sigops] in
> the input scriptSig and previous output's scriptPubKey". Signature=20
operations 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=
=20
says that "a push of a version byte, plus a push of a
witness program. The scriptSig must be exactly empty or validation fails."=
=20
So unless you have a different validation logic which
is introduced in an unknown future for any segwit spends (OP_01 to OP_16=20
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=
=20
more concerning implemented by mistake to concern segwit
spends. For bitcoin core, the code is very proper here in `VerifyScript`=20
and commented accordingly.

I'm still thinking it would be good BIP stylistic to have BIP54 making an=
=20
explicit referral to BIP141 to define "legacy" inputs
by opposition to "segwit" inputs, which have a precise technical=20
definition. Less a BIP is ambiguous, better it is.

> Any remotely sane transaction would run into the standardness size limit=
=20
before running into this limit.=20

No, I'm not sure of that. I was having fun recently with scriptsig junking=
=20
transaction leveraring OP_CHECKMULTISIG:
https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68d=
a9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b75654=
7R42
It sounds you can generate transaction which are perfectly standard (i.e=20
under MAX_STANDARD_TX_WEIGHT) with a very high
number of sigops stuffed within. I don't remember checking all the policy=
=20
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: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac71

Le mardi 15 juillet 2025 =C3=A0 12:37:50 UTC+1, Antoine Poinsot a =C3=A9cri=
t :

> Hi Antoine,
>
> Could you please clearly describe the "attack" with a clear threat model?=
=20
> I don't think what you describe is an issue under any realistic threat=20
> model, much less how it would only materialize with BIP54's sigop limit b=
ut=20
> not with the existing sigop limit.
>
> Anyway, the current BIP54 says the following nothing about legacy inputs:
>
>
> The BIP54 specifications are written from the perspective of an=20
> implementer and clearly states "count the number of [sigops] in the input=
=20
> scriptSig and previous output's scriptPubKey". Signature operations in=20
> these fields preceded Segwit (which requires the scriptSig to be empty an=
d=20
> the prevout's scriptPubKey to be pushonly).
>
> I think there are some implications about all of this for some use-cases=
=20
> designers,
> e.g for massive Coinjoin
>
>
> Any remotely sane transaction would run into the standardness size limit=
=20
> before running into this limit. Only a pathological transaction which tri=
es=20
> to increase its validation cost may run into this limit while being=20
> standard according to today's Core policy. See=20
> https://github.com/bitcoin/bips/blob/master/bip-0054.md#user-content-fn-7=
-21829941cd04259d86862ad3baa11d05
> .
>
> Best,
> Antoine
> On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard <
> antoin...@gmail.com> wrote:
>
> Hi Poinsot,
>
> Not necessarily, if you go to multi-sign the first input of your=20
> second-stage txn with
> SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are=
=20
> not commited.
> The second input can be a legacy input, even if it's altered in-flight=20
> (e.g flipping
> the S component of the ECDSA sig), it's breaking your sig hash for the=20
> second input,
> but not the sighash for the "contract" multi-signed input. Very practical=
=20
> for doing
> unilateral fee-bumping.
>
> It's a problem if you do multi-stage for an off-chain construction, as th=
e=20
> third order
> tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and=20
> implicitly the
> parent txid of the malleable second input.
>
> ...
>
> Anyway, the current BIP54 says the following nothing about legacy inputs:
>
> "A limit is set on the number of potentially executed signature operation=
s=20
> in validating
> a transaction. It applies to all transactions in the block except the=20
> coinbase transaction.
> For each input in the transaction, count the number of CHECKSIG and=20
> CHECKMULTISIG in the
> input scriptSig and previous output's scriptPubKey, including the P2SH=20
> redeemScript".
>
> I do think it would be clearer to say that Segwit spends are logically=20
> excluded due
> to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size()=
=20
> !=3D 0 in
> `VerifyScript()`) and b) a witness program must be a data push and as suc=
h=20
> it's
> never a scriptCode that can contain a CHECKSIG ops. Accounting is=20
> implicitly always
> 0 for Segwit spends.
>
> There is no definition of what make a spend a "legacy" input, other than=
=20
> it's not
> a Segwit spend. Technically, the CHECKSIG operations are committed in the=
=20
> witness
> program, which is itself part of the scriptPubkey... While indeed,=20
> currently the code
> is properly dissociating the verifcation of the legacy spends from the=20
> witness program,
> it's hard to say the limit is correctly implemented in the complete lack=
=20
> of available code.
>
> The limit could be implemented in EvalScript(), but I'm not sure it's=20
> exactly what
> you have in mind. Thanks by advance if there is code and specification=20
> defining
> more precisly what is understood as a legacy input under this BIP proposa=
l.
>
> ...
>
> I think there are some implications about all of this for some use-cases=
=20
> designers,
> e.g for massive Coinjoin, if in the collaborative transaction constructio=
n=20
> any party
> proposes a scriptpubkey with a huge number of sigs to reach the limit, no=
w=20
> if you
> don't verify the script sanity against this new rule, you might have=20
> contributed
> an input in a transaction that is never going to be valid. Some kind of=
=20
> 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=20
> explictly
> requests segwit input at `tx_add_input` reception), I'm not sure for any=
=20
> coinjoin
> or multi-party tx construction stuff that might be affected by a new DoS=
=20
> vector
> as soon as this starts to be a policy rule spread substantially on the=20
> network.
>
> It's not to say that this limit shouldn't be deployed, but in my opinion=
=20
> it's
> wise to advertise more towards multi-party use-cases maintainers and devs=
=20
> the
> potential implications of the deployment of this rule, as soon as it's=20
> policy.
>
> Best,
> Riard
> OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc90=
2
> Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9cr=
it :
>
>> This limit only concerns legacy signature operations. Off-chain=20
>> constructions use Segwit inputs, as they would be trivially broken by tx=
id=20
>> malleability otherwise.
>> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard <antoin...@gmail.co=
m>=20
>> wrote:
>>
>> Hi Poinsot,
>>
>> Thanks for the collection of historical txn hitting the proposed new=20
>> limit.
>>
>> The only long-term downside coming immediately out of mind, if the rule=
=20
>> becomes consensus
>> in the future, it's the implicit limitation it would make on the=20
>> multi-party dimensions
>> of off-chain constructions. In the past, I made really rough math for=20
>> 1000-sized participants
>> payments pools, where for the funding_tx, you have the 1000 participants=
=20
>> contributing
>> one input with one sig for each [0].=20
>>
>> In my understanding the new limit of 2500 signatures operation would mak=
e=20
>> a hard-limit
>> for the number of participants entering in such construction, without=20
>> other tricks that
>> are consuming more block space. One can note the downside on funding tx=
=20
>> of high-order
>> off-chain construction, if a max tx size consensus limit is introduced i=
n=20
>> the future.
>>
>> Of course, I do not deny the DoS rational of introducing the 2500 sig=20
>> limit and it's
>> very needed. At the same time, we should be careful of not closing too=
=20
>> much doors for
>> future off-chain constructions and long-term tx throughput scalability.
>>
>> I do believe, it's always technically possible in the future to introduc=
e=20
>> new opcode
>> or segwit versions scripts (e.g grafroot or entroot-based pool=20
>> construction), which
>> wouldn't be subject to the new limit, and as such more scalable. If I'm=
=20
>> correct, I
>> think it's all about how the limit is implemented to parse current=20
>> scripts to be
>> spent.
>>
>> But it's hard to say without code available to review and reason. May I=
=20
>> kindly note
>> there is no reference implementation attached in the current BIP54=20
>> document [1]. Even,
>> if it's often updated, it's always fruitful to have code under the eyes=
=20
>> for review.
>>
>> This might be the kind of concern (very) far down the line...but=20
>> preserving the
>> evolvability of the consensus rules is a good property to care about, in=
=20
>> my humble
>> opinion.
>>
>> Best,
>> Riard
>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2
>>
>> [0]=20
>> https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.gmail=
.com/=20
>> <https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8=
tnWswqbfAnRdA@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,=20
>>>
>>> To mitigate high block validation time, BIP54 proposes to make=20
>>> transactions which require more than=20
>>> 2500 legacy signature operations invalid by consensus. The 2500 figure=
=20
>>> was chosen as the tightest=20
>>> value that did not make any non-pathological currently standard=20
>>> transaction invalid.=20
>>>
>>> No transaction in Bitcoin's history would have both hit the BIP54 sigop=
=20
>>> limit and been standard=20
>>> according to today's Bitcoin Core policy[^0]. But what happened in the=
=20
>>> past doesn't matter as much=20
>>> as the fact that it is possible today to create a pathological standard=
=20
>>> transaction that is=20
>>> BIP54-invalid.=20
>>>
>>> This opens up a major DoS vector against unupgraded miners if BIP54 eve=
r=20
>>> gets activated in these=20
>>> conditions. Therefore i propose to make such transactions non-standard=
=20
>>> and hold off activation of=20
>>> BIP54 until we have good reasons to believe that the vast majority of=
=20
>>> the hashrate won't create a=20
>>> block containing such a transaction.=20
>>>
>>> Doing so gives better guarantees in case BIP54 is ever considered for=
=20
>>> activation, and comes at=20
>>> virtually no cost since these pathological transactions have never been=
=20
>>> used and serve no purpose=20
>>> beyond increasing the cost of validation. Bitcoin Core PR #32521=20
>>> implements this change, which i=20
>>> hope to get into the upcoming 30.0 release as well as backported to=20
>>> previous versions.=20
>>>
>>> Best,=20
>>> Antoine Poinsot=20
>>>
>>> [^0]: Here the full list of historical transactions that would have hit=
=20
>>> the BIP54 sigops limit:=20
>>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2=20
>>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683=20
>>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179=20
>>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0=20
>>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6=20
>>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09=20
>>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e=20
>>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f=20
>>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327=20
>>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f=20
>>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc=20
>>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3=20
>>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3=20
>>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08=20
>>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363=20
>>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841=20
>>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf=20
>>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34=20
>>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e=20
>>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b=20
>>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007=20
>>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d=20
>>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e=20
>>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3=20
>>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a=20
>>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235=20
>>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629=20
>>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530=20
>>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5=20
>>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60=20
>>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57=20
>>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7=20
>>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311=20
>>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2=20
>>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f=20
>>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a=20
>>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7=20
>>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9=20
>>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f=20
>>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921=20
>>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597=20
>>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d=20
>>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8=20
>>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711=20
>>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6=20
>>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec=20
>>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda=20
>>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652=20
>>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e=20
>>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508=20
>>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261=20
>>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2=20
>>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663=20
>>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436=20
>>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7=20
>>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d=20
>>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649=20
>>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4=20
>>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1=20
>>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4=20
>>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640=20
>>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9=20
>>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404=20
>>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b=20
>>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b=20
>>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5=20
>>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd=20
>>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517=20
>>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4=20
>>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd=20
>>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04=20
>>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3=20
>>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f=20
>>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef=20
>>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e=20
>>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545=20
>>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b=20
>>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0=20
>>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276=20
>>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d=20
>>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c=20
>>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8=20
>>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641=20
>>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf=20
>>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278=20
>>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a=20
>>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521=20
>>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c=20
>>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b=20
>>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15=20
>>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797=20
>>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9=20
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion visit=20
>> https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-1d1=
02477ccfdn%40googlegroups.com
>> .
>>
>>
>> --=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/e27c5b87-3be2-4ed0-9000-8482=
2ca84c23n%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/=
8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n%40googlegroups.com.

------=_Part_90821_386474536.1753293387988
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Poinsot,<br /><br />&gt; Could you please clearly describe the "attack" =
with a clear threat model? I don't think what you describe is an issue unde=
r any<br />&gt; realistic threat model, much less how it would only materia=
lize with BIP54's sigop limit but not with the existing sigop limit.<br /><=
br />Yes, for sure. So let's say you have a Coinjoin collaborated among 10 =
pseudonymous peers (...they rely as much as they can on<br />the chain as t=
he source of truth to preserve the overall pseudonymity so hardness to eval=
uate "trustworthiness" of a specific peer),<br />where there is a single pe=
er randomly designated as the coordinator. Each peer contributes an input t=
owards the common transaction.<br /><br />Let says the 1st participant is t=
he coordinator, the 2nd to 9th participant are participants only contributi=
ng P2WPKH, for which<br />the new MAX_TX_LEGACY_SIGOPS is not a problem at =
all. The 10th participant deliberately contribute a legacy input with empty=
 junk<br />OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MU=
LTISIG 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 Co=
injoin protocol-defined limit),<br />so the cost for the malicious 10th par=
ticipant is minimized. All the inputs are assembled together in the multi-p=
arty transaction,<br />however this transaction is now policy invalid in re=
ason 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 rul=
e by the coordinator, or by any participant if the Coinkoin protocol is ful=
ly distributed<br />among participants, identifying the source of error can=
 be a hard 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 eve=
n 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 />=C2=A0<b=
r />Of course there is always the option to bypass the policy rules by reac=
hing out to a miner private API, though if you''re doing<br />a coinjoin it=
 is less than optimal to maximize confidentiality of the flow.<br /><br />N=
ote this threat model has been already considered in the past here:<br />th=
at://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lig=
htning-dev/2021-May/003033.txt<br /><br />Those are the reasons e.g for lig=
htning only segwit inputs are accepted to be contributed for a collaborativ=
e transaction and<br />other limits are checked to sanitize the flow toward=
s policy rule ("MAY fail the negotiation if `script` is non-standard" at<br=
 />`tx_add_output` reception).<br /><br />Currently, the problem would exis=
t though only if the built Coinjoin transaction would have more than 80k si=
gops. The reduction<br />to MAX_TX_LEGACY_SIGOPS is somehow a corresponding=
 reduction in the cost to mount that DoS attack for an adversary. I think i=
t's<br />cheaper fee-wise to contribute an input to reach the ~2500 limit, =
than the upper 80k 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 downst=
ream softwares. However,<br />mentioning in release notes that the limit mi=
ght affect tx collaborative construction for downstream softwares devs and =
that action<br />might have to be taken at their appreciation (as they're t=
he ones with the best know-how about their protocols) can be a courteous<br=
 />note. IMHO, assuming those kinds of threat models are realistic, it woul=
d be welcome to be more verbose everytime there is a<br />_tightening_ of t=
he policy rules. Even if the _tightening_ is in view of a future consensus =
change, there are all the transitory<br />phase during which there are more=
 exposures to those kinds of DoS.<br /><br />&gt; The BIP54 specifications =
are written from the perspective of an implementer and clearly states "coun=
t the number of [sigops] in<br />&gt; the input scriptSig and previous outp=
ut's scriptPubKey". Signature operations in these fields preceded Segwit (w=
hich requires the<br />&gt; scriptSig to be empty and the prevout's scriptP=
ubKey to be pushonly).<br /><br />Yes, I read again BIP141 around writing m=
y previous email. BIP141 clearly says that "a push of a version byte, plus =
a push of a<br />witness program. The scriptSig must be exactly empty or va=
lidation fails." So unless you have a different validation logic which<br /=
>is introduced in an unknown future for any segwit spends (OP_01 to OP_16 v=
ersion byte + a push of the witness program), I don't<br />see how the limi=
t could be understood to be applied to segwit spends, and more concerning i=
mplemented by mistake to concern segwit<br />spends. For bitcoin core, the =
code is very proper here in `VerifyScript` and commented accordingly.<br />=
<br />I'm still thinking it would be good BIP stylistic to have BIP54 makin=
g an explicit referral to BIP141 to define "legacy" inputs<br />by oppositi=
on to "segwit" inputs, which have a precise technical definition. Less a BI=
P is ambiguous, better it is.<br /><br />&gt; Any remotely sane transaction=
 would run into the standardness size limit before running into this limit.=
 <br /><br />No, I'm not sure of that. I was having fun recently with scrip=
tsig junking transaction leveraring OP_CHECKMULTISIG:<br />https://github.c=
om/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#diff-a304=
e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42<br />It sou=
nds you can generate transaction which are perfectly standard (i.e under MA=
X_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_STANDAD_=
TX_WEIGHT is<br />one of the rule you _cannot_ disable or turn off on the C=
LI iirc.<br /><br />Best,<br />Riard<br />OTS hash: 91fad050b8b9ffdc0a25f99=
7cc6f77e701e039ba4415a9a7cfe7809f1aafac71<br /><br /><div class=3D"gmail_qu=
ote"><div dir=3D"auto" class=3D"gmail_attr">Le mardi 15 juillet 2025 =C3=A0=
 12:37:50 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:<br/></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0 0 0 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-co=
lor:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-serif;=
font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Could yo=
u please clearly describe the &quot;attack&quot; with a clear threat model?=
 I don&#39;t think what you describe is an issue under any realistic threat=
 model, much less how it would only materialize with BIP54&#39;s sigop limi=
t but not with the existing sigop limit.<br></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><div style=3D"font-family:Arial,sans-serif;font-size:14=
px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><blockquote style=3D=
"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);paddi=
ng-left:10px;color:rgb(102,102,102)"><div><span><span>Anyway, the current B=
IP54 says the following nothing about legacy inputs:</span></span></div><di=
v><span><span></span></span></div></blockquote></div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(2=
55,255,255)"><br></div><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </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 &quot;count the number of [sigops] in the input
scriptSig and previous output&#39;s scriptPubKey&quot;. Signature operation=
s in these fields preceded Segwit (which requires the scriptSig to be empty=
 and the prevout&#39;s scriptPubKey to be pushonly).</div><div style=3D"fon=
t-family:Arial,sans-serif;font-size:14px"><br></div><blockquote style=3D"bo=
rder-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-=
left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px">I think there are some implications about all of this for=
 some use-cases designers,<br></div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px">e.g for massive Coinjoin</div></blockquote><br><div><sp=
an style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;col=
or:rgb(0,0,0);background-color:rgb(255,255,255)">Any remotely sane transact=
ion would run</span> into the standardness size limit before running into t=
his limit. Only a pathological transaction which tries to increase its vali=
dation cost may run into this limit while being standard according to today=
&#39;s Core policy. See <span><a rel=3D"noreferrer nofollow noopener" href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0054.md#user-content-fn=
-7-21829941cd04259d86862ad3baa11d05" target=3D"_blank" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/b=
ips/blob/master/bip-0054.md%23user-content-fn-7-21829941cd04259d86862ad3baa=
11d05&amp;source=3Dgmail&amp;ust=3D1753379716725000&amp;usg=3DAOvVaw25Q6XPr=
OuHL71CD803Sx6O">https://github.com/bitcoin/bips/blob/master/bip-0054.md#us=
er-content-fn-7-21829941cd04259d86862ad3baa11d05</a></span>.</div><div><br>=
</div><div>Best,<br>Antoine<br></div><div></div><div>
        On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard &lt;<a href =
data-email-masked rel=3D"nofollow">antoin...@gmail.com</a>&gt; wrote:<br>
        </div><div><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&#39;s altered in-flight (e.g flipping<=
br>the S component of the ECDSA sig), it&#39;s breaking your sig hash for t=
he second input,<br>but not the sighash for the &quot;contract&quot; multi-=
signed input. Very practical for doing<br>unilateral fee-bumping.<br><br>It=
&#39;s a problem if you do multi-stage for an off-chain construction, as th=
e third order<br>tx, even with SIGHASH_SINGLE would commit to `outpoint` fi=
eld, and implicitly the<br>parent txid of the malleable second input.<br><b=
r>...<br><br>Anyway, the current BIP54 says the following nothing about leg=
acy inputs:<br><br>&quot;A limit is set on the number of potentially execut=
ed signature operations in validating<br>a transaction. It applies to all t=
ransactions in the block except the coinbase transaction.<br>For each input=
 in the transaction, count the number of CHECKSIG and CHECKMULTISIG in the<=
br>input scriptSig and previous output&#39;s scriptPubKey, including the P2=
SH redeemScript&quot;.<br><br>I do think it would be clearer to say that Se=
gwit spends are logically excluded due<br>to a) a Segwit spend&#39;s script=
Sig must be always empty (`scriptSig.size() !=3D 0 in<br>`VerifyScript()`) =
and b) a witness program must be a data push and as such it&#39;s<br>never =
a scriptCode that can contain a CHECKSIG ops. Accounting is implicitly alwa=
ys<br>0 for Segwit spends.<br><br>There is no definition of what make a spe=
nd a &quot;legacy&quot; input, other than it&#39;s not<br>a Segwit spend. T=
echnically, the CHECKSIG operations are committed in the witness<br>program=
, which is itself part of the scriptPubkey... While indeed, currently the c=
ode<br>is properly dissociating the verifcation of the legacy spends from t=
he witness program,<br>it&#39;s hard to say the limit is correctly implemen=
ted in the complete lack of available code.<br><br>The limit could be imple=
mented in EvalScript(), but I&#39;m not sure it&#39;s exactly what<br>you h=
ave in mind. Thanks by advance if there is code and specification defining<=
br>more precisly what is understood as a legacy input under this BIP propos=
al.<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 colla=
borative transaction construction any party<br>proposes a scriptpubkey with=
 a huge number of sigs to reach the limit, now if you<br>don&#39;t verify t=
he script sanity against this new rule, you might have contributed<br>an in=
put in a transaction that is never going to be valid. Some kind of denial-o=
f-service,<br>and the reason initially opt-in rbf was proposed to be remove=
.<br><br>While this is not a concern for lightning (bc the dual funding spe=
c explictly<br>requests segwit input at `tx_add_input` reception), I&#39;m =
not sure for any coinjoin<br>or multi-party tx construction stuff that migh=
t be affected by a new DoS vector<br>as soon as this starts to be a policy =
rule spread substantially on the network.<br><br>It&#39;s not to say that t=
his limit shouldn&#39;t be deployed, but in my opinion it&#39;s<br>wise to =
advertise more towards multi-party use-cases maintainers and devs the<br>po=
tential implications of the deployment of this rule, as soon as it&#39;s po=
licy.<br><br>Best,<br>Riard<br>OTS hash: c236ba440e27f6bf89db9d21f1650d945c=
92fc941bb9177dbf06bbbac2afc902<br><div class=3D"gmail_quote"><div dir=3D"au=
to" class=3D"gmail_attr">Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Ant=
oine Poinsot a =C3=A9crit :<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px">This limit=
 only concerns legacy signature operations. Off-chain constructions use Seg=
wit inputs, as they would be trivially broken by txid malleability otherwis=
e.<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&=
#39;s the implicit limitation it would make on the multi-party dimensions<b=
r>of off-chain constructions. In the past, I made really rough math for 100=
0-sized 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 woul=
d make a hard-limit<br>for the number of participants entering in such cons=
truction, 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 c=
ourse, I do not deny the DoS rational of introducing the 2500 sig limit and=
 it&#39;s<br>very needed. At the same time, we should be careful of not clo=
sing too much doors for<br>future off-chain constructions and long-term tx =
throughput scalability.<br><br>I do believe, it&#39;s always technically po=
ssible in the future to introduce new opcode<br>or segwit versions scripts =
(e.g grafroot or entroot-based pool construction), which<br>wouldn&#39;t be=
 subject to the new limit, and as such more scalable. If I&#39;m correct, I=
<br>think it&#39;s all about how the limit is implemented to parse current =
scripts to be<br>spent.<br><br>But it&#39;s hard to say without code availa=
ble to review and reason. May I kindly note<br>there is no reference implem=
entation attached in the current BIP54 document [1]. Even,<br>if it&#39;s o=
ften updated, it&#39;s always fruitful to have code under the eyes for revi=
ew.<br><br>This might be the kind of concern (very) far down the line...but=
 preserving the<br>evolvability of the consensus rules is a good property t=
o care about, in my humble<br>opinion.<br><br>Best,<br>Riard<br>OTS hash: a=
2bb9a1faf79309b039d8ae7e0b951644ca0adb2<br><br>[0] <a href=3D"https://gnush=
a.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mai=
l.gmail.com/" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-s=
aferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha=
.org/pi/bitcoindev/CALZpt%2BE%2BeKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@=
mail.gmail.com/&amp;source=3Dgmail&amp;ust=3D1753379716725000&amp;usg=3DAOv=
Vaw1RcLPFnyD-Hl5rZysvsD0x">https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOX=
d-8A6oThw-...@mail.gmail.com/</a><br>[1] <a href=3D"https://github.com/bitc=
oin/bips/blob/master/bip-0054.md" rel=3D"noreferrer nofollow noopener" targ=
et=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&am=
p;q=3Dhttps://github.com/bitcoin/bips/blob/master/bip-0054.md&amp;source=3D=
gmail&amp;ust=3D1753379716725000&amp;usg=3DAOvVaw3ihXJuvoZWzPD5yshIsI8R">ht=
tps://github.com/bitcoin/bips/blob/master/bip-0054.md</a><br><br><div class=
=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le mercredi 2 juill=
et 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3=A9crit :<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Hi everyone,
<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&#39;s history would have both hit the BIP54 s=
igop limit and been standard
<br>according to today&#39;s Bitcoin Core policy[^0]. But what happened in =
the past doesn&#39;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&#39;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 &=
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 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" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/=
bitcoindev/eb191c75-e245-4c40-8288-1d102477ccfdn%2540googlegroups.com&amp;s=
ource=3Dgmail&amp;ust=3D1753379716725000&amp;usg=3DAOvVaw1B4VtuWX3ies_x0bPL=
jvoJ">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 &=
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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br></blockquote></div><div><blockquote typ=
e=3D"cite">
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" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/=
bitcoindev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%2540googlegroups.com&amp;s=
ource=3Dgmail&amp;ust=3D1753379716725000&amp;usg=3DAOvVaw3PUxAzUw_7cPVDsulB=
S2VD">https://groups.google.com/d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-=
84822ca84c23n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></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/8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n%40googlegroups.com</a>.<br />

------=_Part_90821_386474536.1753293387988--

------=_Part_90820_1343623919.1753293387988--