path: root/57/42328bce0695f5f367e1302ed1fe5659bc8790

Delivery-date: Tue, 29 Jul 2025 13:28:57 -0700
Received: from mail-qt1-f188.google.com ([209.85.160.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRB665UTCAMGQE5VYGYIQ@googlegroups.com>)
	id 1ugqwQ-0002Iq-Aw
	for bitcoindev@gnusha.org; Tue, 29 Jul 2025 13:28:57 -0700
Received: by mail-qt1-f188.google.com with SMTP id d75a77b69052e-4ab3b89760bsf137723871cf.1
        for <bitcoindev@gnusha.org>; Tue, 29 Jul 2025 13:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1753820928; x=1754425728; 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=LOKIfeEWVkdwfFhHH2FmMHC5Cz8cJze/XuDkGslgpas=;
        b=ZVhsP/3hToMgnfn8i/wVJ+8alJKYmqhth6cd8sF+Z+4FrjDAOtSUc8DHTKRkCutZ28
         DhtmuMjD4KXUULqDS8CfN1WTSMSgJWgx4USSJjm2pxeM2y0QpC8ZV+BVGoorxIjM5UbV
         +ln7bzEXppNO1LMVNrK4bzHcD3XtCihi3OXaQSA+gAWAHb0xVRecaScsEmCTo/WWbich
         R2Yy5u7HtfshIAS+amvEhUjMXixstjcUMddq21xIvDTV0lA5RYrOTPvlOljCJgYxooh/
         z5ETi36LHQ7Imbvdy9MjsRDUjmqRAFqSECtgmWiT7dkRTBPRiK0IpVH+E6ugMP5PzNSj
         lm2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1753820928; x=1754425728; 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=LOKIfeEWVkdwfFhHH2FmMHC5Cz8cJze/XuDkGslgpas=;
        b=cD36fbRCHMZEqcMm0BxQRc2Te6rcBgdgdJW1A7ZKM2nd331iyIf5lcqc2iSPdAHFa8
         j9Ix4y1A7oDVL3U7eXLHhRTWS7maN1Oav6HUS651H4CsrDzvpgkUve8cWvZ6HK84euHm
         bDLjotNdmJeZtzfnqPJDiEPIqISTUYg+617hVUrMTRJ2xOdp8920CNXlbzSMySWNX40C
         aam3GYtBC29Ab3feHko7HuRxUgzZ1j/PKynbogthQmK59JLTSAD3P86dnGH2Ne5oo8kc
         h/10T4qcvve+cspi5cdtL13I6bMp6PrbrZK02R9OQYiOy/d7raUjgxgdMutInvUlYAty
         1Ayw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1753820928; x=1754425728;
        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=LOKIfeEWVkdwfFhHH2FmMHC5Cz8cJze/XuDkGslgpas=;
        b=hYzVyeFSJhGmhynGNzG4yfoWt1nYUO0rk43t1luHDT8WDyhriABXtydTYITSY7oJdc
         m5YmU600O3bT9xq/+6/us/Z9neus66CywtDquzgkN0dSljLacoG7SJFsEEJuS0FaQhdk
         EVF1m6WrVndqm7mKvqApZHXhuENIONwDSA1X6tMYm2UcUO9ng0ivURi/45XOS4SRD/8z
         f1RDxKpW8CWoCQEkJY9WhqloGgnrisdrzrNarxzqdjlmFVjt6jJjhLASvU/xdPgJJUjm
         590ctne6K9k/CifeRZjDzVyH9CRBi/FL0duP8T1PMRlSeay70+uuuyOMxBYAxOZxTqZ2
         G8DQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVJAeQ+6e1se3BCAg0n7kPdK9R3cIhxArbk6JbNnTboC659Z35sPhM7Q1yVZsSrFaWeHk/Tqi9tTXfw@gnusha.org
X-Gm-Message-State: AOJu0Yxozzk/aXPIUMSmhFdbU41E4mYD6pisoXMZZP0kfPjvhlVh24e3
	qV/JTIzgr5SNLAhhs84BpxQfjIQh5AzbScFKX4eYRooAkhv7OIIjrTM9
X-Google-Smtp-Source: AGHT+IGFMsUCTjFdyjTG9bed/DUB9G6gGQUJFuNvvm9RRMVGjUdweSzBWXl4y4OScbneX5/Y68qgsA==
X-Received: by 2002:ac8:5f8a:0:b0:4ae:5952:a54c with SMTP id d75a77b69052e-4aedbf90d07mr15678491cf.55.1753820927494;
        Tue, 29 Jul 2025 13:28:47 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcjfcogUzg4CU7BLs3BIXiU4SzC3bxAzLmClEUTXfvLgg==
Received: by 2002:ac8:5714:0:b0:4a7:f568:5323 with SMTP id d75a77b69052e-4ae7bb9122dls94375631cf.0.-pod-prod-07-us;
 Tue, 29 Jul 2025 13:28:43 -0700 (PDT)
X-Received: by 2002:a05:620a:a482:b0:7e3:2c14:2319 with SMTP id af79cd13be357-7e66f391395mr125901985a.44.1753820923456;
        Tue, 29 Jul 2025 13:28:43 -0700 (PDT)
Received: by 2002:a0d:d0c4:0:b0:718:5fd:a4e7 with SMTP id 00721157ae682-719b273ca77ms7b3;
        Sun, 27 Jul 2025 14:40:56 -0700 (PDT)
X-Received: by 2002:a05:690c:60c4:b0:70e:2ced:6f5f with SMTP id 00721157ae682-719e38d322cmr105868357b3.37.1753652455203;
        Sun, 27 Jul 2025 14:40:55 -0700 (PDT)
Date: Sun, 27 Jul 2025 14:40:54 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5e84e244-c99d-4825-8387-8333a6587d77n@googlegroups.com>
In-Reply-To: <wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx866JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU=@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>
 <CALZpt+EHhUdJPu1Ydn+9QmccvMuRW-m+VcgG5qp-pEbO4AxGyQ@mail.gmail.com>
 <wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx866JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU=@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_425458_945405268.1753652454875"
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_425458_945405268.1753652454875
Content-Type: multipart/alternative; 
	boundary="----=_Part_425459_1446440751.1753652454875"

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

Hi Poinsot,

> Attempting to contribute a non-standard input to a multiparty transaction=
=20
creation protocol is not an "attack" nor something you can prevent=20
participant are not trusted

I agree there is a sense of proportion to have for sure. It's not an attack=
=20
in the sense of loss of funds
for a second-layers failing to include a time-sensitive tx, typically a=20
commiment tx. But if you're a participant
in a multi-party flow and you're deliberately contributing a non standard=
=20
input to a collaborative tx, because
you know that the software of the collaborative tx finalizer won't verify=
=20
and tx propagation will fail, what it
is if it's not DoS attack, I don't know.

One has to put itself in the shoes of a LSP, for which liquidity to=20
allocate is scarce (in a world where
`MAX_MONEY` is true), and of which its propagation collaborative tx=20
allocating liquidity is DoSed. E.g if you
take core-lightning, i think a software you're familiar with, it implements=
=20
such standardness script sanitization
during the collaborative flow construction (in `common/interactivetx.c`):

            /* BOLT #2:
                         * The receiving node: ...
                         * - MAY fail the negotiation if `script`
                         *   is non-standard */
                        if (!is_known_scripttype(scriptpubkey,=20
tal_bytelen(scriptpubkey)))
                                return tal_fmt(ctx, "Script is not=20
standard");

For the how to you sort trusted vs non-trusted participant in a=20
collaborative txn flow, on the image
of a coinjoin or lightning dual-funding, it's not a solved problem.=20
Especially if the idea is to automate
as much as you can of the protocol flow, without necessarily Bob the=20
sysadmin manually clicking on each
`tx_add_input` proposal from each multi-party tx participant to allow them=
=20
in at 3AM in the morning...

Of course Bob can be very successful in sorting standard vs non-standard=20
input, but still he would have to
be aware of the standardness rules, documented somewhere.

See that old email, the alternatives the end which is detailing this DoS=20
threat model in a realistic fashion:
https://gnusha.org/pi/bitcoindev/CALZpt+HXB=3Dxh3qtxJFM7yUzRu1uj-pPtLQmT=3D=
5QV0dNfVuTpfQ@mail.gmail.com/

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

True, my test spending p2wsh inputs. But it was a demo on how you can=20
generate space-wise efficient scriptsig junking tx under
the MAX_STANDARD_TX_WEIGHT by leveraging the MAX_PUBKEYS_PER_MULTISIG=20
account limit. MAX_SCRIPT_SIZE is the same for legacy and
SegWit V0.

The point being, and in my understanding where we're diverging, is that=20
this new limit should be in a best effort reflected
in multi-party tx softwares that are accepting contributing input for=20
collaborative tx flow. Lack of adherence of this new
limit might lead them to exposure the style of DoS described above, as they=
=20
might start to take part in pathological tx
post 0.30.

I fully grant it's somehow lightweighted by the fact it generally takes 2=
=20
or 3 releases of bitcoin core to have a new policy
rule widely deployed on the network, and until then it's okay if the=20
multi-party tx stack do not upgrade its own full-node
(i.e the initial tx broadcaster), as it's should still find among its=20
tx-relay peers "pathological"-acceptance nodes for a while.

Best,
Riard
OTS hash: 610a08345b4e79f0203904948b2ad2f689140ae0373732b31d6d981756e2e698
Le vendredi 25 juillet 2025 =C3=A0 17:56:32 UTC+1, Antoine Poinsot a =C3=A9=
crit :

> Antoine,
>
> Attempting to contribute a non-standard input to a multiparty transaction=
=20
> creation protocol is not an "attack" nor something you can prevent=20
> participant 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.=
=20
> The newly introduced limit only applies to inputs spending legacy scripts=
.=20
> That said, it is indeed possible to create a transaction which is standar=
d=20
> today but would run in this new limit. Otherwise introducing the limit=20
> wouldn't be necessary in the first place. My point is just that any such=
=20
> transaction would be pathological. Examples are constructed in the tests =
of=20
> the PR linked in OP. Your test, although it's using Segwit input, is also=
 a=20
> 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 <antoin...@gmail.com=
>=20
> wrote:
>
> Hi Poinsot,
>
> > Could you please clearly describe the "attack" with a clear threat=20
> model? 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=20
> participant are participants only contributing P2WPKH, for which
> the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participan=
t=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=20
> inputs 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.
>
> Of course there is always the option to bypass the policy rules by=20
> reaching 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/lightn=
ing-dev/2021-May/003033.txt
>
> Those are the reasons e.g for lightning only segwit inputs are accepted t=
o=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=
=20
> 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=20
> upper 80k limit itself.
>
> In my view, it's not really the responsibility of a full-node to care=20
> about 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 th=
e=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 limi=
t=20
> before running into this limit.=20
>
> No, I'm not sure of that. I was having fun recently with scriptsig junkin=
g=20
> 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=
=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: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac7=
1
>
>
> Le lun. 14 juil. 2025 =C3=A0 15:44, Antoine Poinsot <daro...@protonmail.c=
om> a=20
> =C3=A9crit :
>
>> 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 =
but=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 inpu=
t=20
>> scriptSig and previous output's scriptPubKey". Signature operations in=
=20
>> these fields preceded Segwit (which requires the scriptSig to be empty a=
nd=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 tr=
ies=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 practica=
l=20
>> for doing
>> unilateral fee-bumping.
>>
>> It's a problem if you do multi-stage for an off-chain construction, as=
=20
>> the 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=20
>> operations 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=20
>> such 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 th=
e=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=20
>> proposal.
>>
>> ...
>>
>> 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=20
>> construction any party
>> proposes a scriptpubkey with a huge number of sigs to reach the limit,=
=20
>> now 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 dev=
s=20
>> the
>> potential implications of the deployment of this rule, as soon as it's=
=20
>> policy.
>>
>> Best,
>> Riard
>> OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc9=
02
>> Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9c=
rit :
>>
>>> This limit only concerns legacy signature operations. Off-chain=20
>>> constructions use Segwit inputs, as they would be trivially broken by t=
xid=20
>>> malleability 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=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 participant=
s=20
>>> contributing
>>> one input with one sig for each [0].=20
>>>
>>> In my understanding the new limit of 2500 signatures operation would=20
>>> make 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=
=20
>>> in 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=20
>>> introduce 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, i=
n=20
>>> my humble
>>> opinion.
>>>
>>> Best,
>>> Riard
>>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2
>>>
>>> [0]=20
>>> https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.gmai=
l.com/=20
>>> <https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG=
8tnWswqbfAnRdA@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 sigo=
p=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 standar=
d=20
>>>> transaction that is=20
>>>> BIP54-invalid.=20
>>>>
>>>> This opens up a major DoS vector against unupgraded miners if BIP54=20
>>>> ever 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 bee=
n=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 hi=
t=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=20
>>> Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to bitcoindev+...@googlegroups.com.
>>> To view this discussion visit=20
>>> https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-1d=
102477ccfdn%40googlegroups.com
>>> .
>>>
>>>
>>> --=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/e27c5b87-3be2-4ed0-9000-848=
22ca84c23n%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/=
5e84e244-c99d-4825-8387-8333a6587d77n%40googlegroups.com.

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

Hi Poinsot,<br /><br />&gt; Attempting to contribute a non-standard input t=
o a multiparty transaction creation protocol is not an "attack" nor somethi=
ng you can prevent participant are not trusted<br /><br />I agree there is =
a sense of proportion to have for sure. It's not an attack in the sense of =
loss of funds<br />for a second-layers failing to include a time-sensitive =
tx, typically a commiment tx. But if you're a participant<br />in a multi-p=
arty flow and you're deliberately contributing a non standard input to a co=
llaborative tx, because<br />you know that the software of the collaborativ=
e tx finalizer won't verify and tx propagation will fail, what it<br />is i=
f it's not DoS attack, I don't know.<br /><br />One has to put itself in th=
e shoes of a LSP, for which liquidity to allocate is scarce (in a world whe=
re<br />`MAX_MONEY` is true), and of which its propagation collaborative tx=
 allocating liquidity is DoSed. E.g if you<br />take core-lightning, i thin=
k a software you're familiar with, it implements such standardness script s=
anitization<br />during the collaborative flow construction (in `common/int=
eractivetx.c`):<br /><br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* BOL=
T #2:<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0* The receiving node: ...<br />=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =
- MAY fail the negotiation if `script`<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 is non-=
standard */<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!is_known_scripttype(scriptpubkey, tal_byte=
len(scriptpubkey)))<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return tal_f=
mt(ctx, "Script is not standard");<br /><br />For the how to you sort trust=
ed vs non-trusted participant in a collaborative txn flow, on the image<br =
/>of a coinjoin or lightning dual-funding, it's not a solved problem. Espec=
ially if the idea is to automate<br />as much as you can of the protocol fl=
ow, without necessarily Bob the sysadmin manually clicking on each<br />`tx=
_add_input` proposal from each multi-party tx participant to allow them in =
at 3AM in the morning...<br /><br />Of course Bob can be very successful in=
 sorting standard vs non-standard input, but still he would have to<br />be=
 aware of the standardness rules, documented somewhere.<br /><br />See that=
 old email, the alternatives the end which is detailing this DoS threat mod=
el in a realistic fashion:<br />https://gnusha.org/pi/bitcoindev/CALZpt+HXB=
=3Dxh3qtxJFM7yUzRu1uj-pPtLQmT=3D5QV0dNfVuTpfQ@mail.gmail.com/<br /><br />&g=
t; Regarding the test at the end of your email, it is spending p2wsh inputs=
. The newly introduced limit only applies to inputs spending legacy scripts=
. That said, it is indeed possible to create a transaction which is standar=
d today but would run in this new limit. Otherwise introducing the limit wo=
uldn't be necessary in the first place. My point is just that any such tran=
saction 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 go=
od example of the type of pathological transactions i am talking about.<br =
/><br />True, my test spending p2wsh inputs. But it was a demo on how you c=
an generate space-wise efficient scriptsig junking tx under<br />the MAX_ST=
ANDARD_TX_WEIGHT by leveraging the MAX_PUBKEYS_PER_MULTISIG account limit. =
MAX_SCRIPT_SIZE is the same for legacy and<br />SegWit V0.<br /><br />The p=
oint being, and in my understanding where we're diverging, is that this new=
 limit should be in a best effort reflected<br />in multi-party tx software=
s that are accepting contributing input for collaborative tx flow. Lack of =
adherence of this new<br />limit might lead them to exposure the style of D=
oS described above, as they might start to take part in pathological tx<br =
/>post 0.30.<br /><br />I fully grant it's somehow lightweighted by the fac=
t it generally takes 2 or 3 releases of bitcoin core to have a new policy<b=
r />rule widely deployed on the network, and until then it's okay if the mu=
lti-party tx stack do not upgrade its own full-node<br />(i.e the initial t=
x broadcaster), as it's should still find among its tx-relay peers "patholo=
gical"-acceptance nodes for a while.<br /><br />Best,<br />Riard<br />OTS h=
ash: 610a08345b4e79f0203904948b2ad2f689140ae0373732b31d6d981756e2e698<br />=
<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le vendre=
di 25 juillet 2025 =C3=A0 17:56:32 UTC+1, Antoine Poinsot a =C3=A9crit=C2=
=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px">Antoine,</div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px">Attempting to contribute a non-s=
tandard input to a multiparty transaction creation protocol is not an &quot=
;attack&quot; nor something you can prevent participant are not trusted. I =
am not sure where this is going.<br></div><div style=3D"font-family:Arial,s=
ans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px">Regarding the test at the end of your email, it is spen=
ding p2wsh inputs. The newly introduced limit only applies to inputs spendi=
ng legacy scripts. That said, it is indeed possible to create a transaction=
 which is standard today but would run in this new limit. Otherwise introdu=
cing the limit wouldn&#39;t be necessary in the first place. My point is ju=
st that any such transaction would be pathological. Examples are constructe=
d in the tests of the PR linked in OP. Your test, although it&#39;s using S=
egwit input, is also a good example of the type of pathological transaction=
s i am talking about.<br></div><div style=3D"font-family:Arial,sans-serif;f=
ont-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px">Best,<br>Antoine<br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
<div></div><div>
        On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard &lt;<a href da=
ta-email-masked rel=3D"nofollow">antoin...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            <div dir=3D"ltr">Hi Poinsot,<br><br></div></blockquote></div><d=
iv><blockquote type=3D"cite"><div dir=3D"ltr">&gt; Could you please clearly=
 describe the &quot;attack&quot; with a clear threat model? I don&#39;t thi=
nk what you describe is an issue under any<br>&gt; realistic threat model, =
much less how it would only materialize with BIP54&#39;s sigop limit but no=
t with the existing sigop limit.<br><br></div></blockquote></div><div><bloc=
kquote type=3D"cite"><div dir=3D"ltr">Yes, for sure. So let&#39;s say you h=
ave a Coinjoin collaborated among 10 pseudonymous peers (...they rely as mu=
ch as they can on<br>the chain as the source of truth to preserve the overa=
ll pseudonymity so hardness to evaluate &quot;trustworthiness&quot; of a sp=
ecific peer),<br>where there is a single peer randomly designated as the co=
ordinator. Each peer contributes an input towards the common transaction.<b=
r><br>Let says the 1st participant is the coordinator, the 2nd to 9th parti=
cipant are participants only contributing 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_MULTISIG while being space-wise efficient.=
<br><br>This legacy input is of minimal satoshi value (&lt;=3D to inputs 1t=
h to 9th while still &gt; to Coinjoin protocol-defined limit),<br>so the co=
st for the malicious 10th participant is minimized. All the inputs are asse=
mbled together in the multi-party transaction,<br>however this transaction =
is now policy invalid in reason of MAX_TX_LEGACY_SIGOPS due to the single r=
edeem script contributed by<br>the 10th input.<br><br>In the lack of awaren=
ess of the policy rule by the coordinator, or by any participant if the Coi=
nkoin protocol is fully 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 co=
ordinator, or even worst if the transaction is just flow with a raw TX mess=
age,<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 b=
y reaching out to a miner private API, though if you&#39;&#39;re doing<br>a=
 coinjoin it is less than optimal to maximize confidentiality of the flow.<=
br><br>Note this threat model has been already considered in the past here:=
<br>that://<a href=3D"http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linux=
foundation-pipermail/lightning-dev/2021-May/003033.txt" rel=3D"noreferrer n=
ofollow noopener" target=3D"_blank" data-saferedirecturl=3D"https://www.goo=
gle.com/url?hl=3Dfr&amp;q=3Dhttp://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev=
/linuxfoundation-pipermail/lightning-dev/2021-May/003033.txt&amp;source=3Dg=
mail&amp;ust=3D1753738758743000&amp;usg=3DAOvVaw00EKq99cjAhH7d-bO8ClG8">diy=
hpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-d=
ev/2021-May/003033.txt</a><br><br>Those are the reasons e.g for lightning o=
nly segwit inputs are accepted to be contributed for a collaborative transa=
ction and<br>other limits are checked to sanitize the flow towards policy r=
ule (&quot;MAY fail the negotiation if `script` is non-standard&quot; at<br=
>`tx_add_output` reception).<br><br>Currently, the problem would exist thou=
gh only if the built Coinjoin transaction would have more than 80k sigops. =
The reduction<br>to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reducti=
on in the cost to mount that DoS attack for an adversary. I think it&#39;s<=
br>cheaper fee-wise to contribute an input to reach the ~2500 limit, than t=
he upper 80k limit itself.<br><br>In my view, it&#39;s not really the respo=
nsibility of a full-node to care about that kind of issues for downstream s=
oftwares. However,<br>mentioning in release notes that the limit might affe=
ct tx collaborative construction for downstream softwares devs and that act=
ion<br>might have to be taken at their appreciation (as they&#39;re the one=
s with the best know-how about their protocols) can be a courteous<br>note.=
 IMHO, assuming those kinds of threat models are realistic, it would be wel=
come to be more verbose everytime there is a<br>_tightening_ of the policy =
rules. Even if the _tightening_ is in view of a future consensus change, th=
ere are all the transitory<br>phase during which there are more exposures t=
o those kinds of DoS.<br><br></div></blockquote></div><div><blockquote type=
=3D"cite"><div dir=3D"ltr">&gt; The BIP54 specifications are written from t=
he perspective of an implementer and clearly states &quot;count the number =
of [sigops] in<br>&gt; the input scriptSig and previous output&#39;s script=
PubKey&quot;. Signature operations in these fields preceded Segwit (which r=
equires the<br>&gt; scriptSig to be empty and the prevout&#39;s scriptPubKe=
y to be pushonly).<br><br></div></blockquote></div><div><blockquote type=3D=
"cite"><div dir=3D"ltr">Yes, I read again BIP141 around writing my previous=
 email. BIP141 clearly says that &quot;a push of a version byte, plus a pus=
h of a<br>witness program. The scriptSig must be exactly empty or validatio=
n fails.&quot; 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 versi=
on byte + a push of the witness program), I don&#39;t<br>see how the limit =
could be understood to be applied to segwit spends, and more concerning imp=
lemented by mistake to concern segwit<br>spends. For bitcoin core, the code=
 is very proper here in `VerifyScript` and commented accordingly.<br><br>I&=
#39;m still thinking it would be good BIP stylistic to have BIP54 making an=
 explicit referral to BIP141 to define &quot;legacy&quot; inputs<br>by oppo=
sition to &quot;segwit&quot; inputs, which have a precise technical definit=
ion. Less a BIP is ambiguous, better it is.<br><br></div></blockquote></div=
><div><blockquote type=3D"cite"><div dir=3D"ltr">&gt; Any remotely sane tra=
nsaction would run into the standardness size limit before running into thi=
s limit. <br><br></div></blockquote></div><div><blockquote type=3D"cite"><d=
iv dir=3D"ltr">No, I&#39;m not sure of that. I was having fun recently with=
 scriptsig junking transaction leveraring OP_CHECKMULTISIG:<br><a href=3D"h=
ttps://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da=
9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547=
R42" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/aria=
rd/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e%23diff-a304e7524=
7f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42&amp;source=3Dgma=
il&amp;ust=3D1753738758744000&amp;usg=3DAOvVaw1WTExPdTZ50iZEeOZyfBrH">https=
://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4=
e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42<=
/a><br>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 stu=
ffed within. I don&#39;t remember checking all the policy rule scenarios, b=
ut MAX_STANDAD_TX_WEIGHT is<br>one of the rule you _cannot_ disable or turn=
 off on the CLI iirc.<br><br>Best,<br>Riard<br>OTS hash: 91fad050b8b9ffdc0a=
25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac71<br></div></blockquote></div>=
<div><blockquote type=3D"cite"><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">Le lun. 14 juil. 2025 =C3=A0 15:44, Antoine Poinso=
t &lt;<a href rel=3D"noreferrer nofollow noopener" data-email-masked>daro..=
.@protonmail.com</a>&gt; a =C3=A9crit :<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: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:Ari=
al,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:14px;c=
olor:rgb(0,0,0);background-color:rgb(255,255,255)">Could you please clearly=
 describe the &quot;attack&quot; with a clear threat model? I don&#39;t thi=
nk what you describe is an issue under any realistic threat model, much les=
s how it would only materialize with BIP54&#39;s sigop limit but not with t=
he existing sigop limit.<br></div><div style=3D"font-family:Arial,sans-seri=
f;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: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-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><span><span>Anyway, the current BIP54 says the =
following nothing about legacy inputs:</span></span></div><div><span><span>=
</span></span></div></blockquote></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: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 &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-top-color:rgb(200,200,200);bord=
er-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);paddin=
g-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px">I think there are some implications about all of this f=
or some use-cases designers,<br></div><div style=3D"font-family:Arial,sans-=
serif;font-size:14px">e.g for massive Coinjoin</div></blockquote><br><div><=
span style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;c=
olor:rgb(0,0,0);background-color:rgb(255,255,255)">Any remotely sane transa=
ction would run</span> into the standardness size limit before running into=
 this limit. Only a pathological transaction which tries to increase its va=
lidation cost may run into this limit while being standard according to tod=
ay&#39;s Core policy. See <span><a rel=3D"noreferrer nofollow noopener" hre=
f=3D"https://github.com/bitcoin/bips/blob/master/bip-0054.md#user-content-f=
n-7-21829941cd04259d86862ad3baa11d05" target=3D"_blank" data-saferedirectur=
l=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/=
bips/blob/master/bip-0054.md%23user-content-fn-7-21829941cd04259d86862ad3ba=
a11d05&amp;source=3Dgmail&amp;ust=3D1753738758744000&amp;usg=3DAOvVaw21eqge=
vXLIDh6uqxohM20r">https://github.com/bitcoin/bips/blob/master/bip-0054.md#u=
ser-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 =
rel=3D"noreferrer nofollow noopener" data-email-masked>antoin...@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&#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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px">This=
 limit only concerns legacy signature operations. Off-chain constructions u=
se Segwit inputs, as they would be trivially broken by txid malleability ot=
herwise.<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=3D1753738758744000&amp;usg=3DAOv=
Vaw1phl8DXpXd2mV0NlAJfv_6">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=3D1753738758744000&amp;usg=3DAOvVaw0KHs7JRROvsSn5zjcZmwsl">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:0px 0px 0px 0.8ex;border-left=
:1px solid 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=3D1753738758744000&amp;usg=3DAOvVaw2Js46Fa6AOv5KFRzpE=
avwT">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>
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=3D1753738758744000&amp;usg=3DAOvVaw2wcixGKu6iRTgdkJ4X=
FgST">https://groups.google.com/d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-=
84822ca84c23n%40googlegroups.com</a>.<br>

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

        </blockquote></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/5e84e244-c99d-4825-8387-8333a6587d77n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/5e84e244-c99d-4825-8387-8333a6587d77n%40googlegroups.com</a>.<br />

------=_Part_425459_1446440751.1753652454875--

------=_Part_425458_945405268.1753652454875--