path: root/53/77690db677d561c1650c8cc2b3119cb6feb7f5

Delivery-date: Tue, 15 Jul 2025 04:37:58 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBCX33DBQMGQEFXIWLHA@googlegroups.com>)
	id 1ubdyu-0002qi-BY
	for bitcoindev@gnusha.org; Tue, 15 Jul 2025 04:37:58 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e85e148288bsf6039698276.0
        for <bitcoindev@gnusha.org>; Tue, 15 Jul 2025 04:37:56 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1752579470; cv=pass;
        d=google.com; s=arc-20240605;
        b=NfSEkrkm2JmRZDyANxZo17m3+CusmveN1Nt36e2M04ogAWmsrE2PFQki6lRHzZ8G91
         9ajyWEsK04j3nfraWNvQZvPIDHfLb/gb2lwCw9eZ0ukzC7JBZjXzvbp0uybAoerWxuVS
         v6NQJCA74G2k7t/9jF6FJyGZXVJ03pMG6U2naitdvpHBgd5nu2F/n46Dbq4HCv3eU3E+
         /1leGizoT1thJrfi+ItkUnJX3ovyDZ1vZFjne8IcEauVFBKsE0k2q0KVndqVz3PvC9bZ
         hOc8zTGvvQSdHo9QNl7zc4yrm8h3zZm8f6d2YR1LsV+zztolC5m8+dwWsSvyHvuTing9
         iK7g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=;
        fh=6B/Wx2cBGqmbqy4P0CkkRa/hLl0uSHxUaLwVKj8nuUM=;
        b=cB0sX8vIETWtjtj5H4YNDslQLvEMg0WalOs8hExI3wmjMBUhlkZ/Ugmw2EEqLh6Rl7
         SMGD0ovfErKerq1NtDg8WTLo8CjiVESQpkXCjTYEmU0LBHJrDVlzlHF7eLcNpFHFJweS
         WcK+mnkYyrYnO5iIPh14NSH8otwOIh6Js3iDDl5QBDCLV0NG7/bZjiWh/oCcfT6DCJrV
         I2H50ZL3wXDWPeuJUktPPYaNNGTzykcTz1+VynLfwPjII+OzMwRpEUxzFjstAkMZmSHG
         F8RBQKkyIfBJvX1cXKODQKLRgYlzSVDgLR/COKaf+TnoaMdPMhsnzALTtTK+gO5KyA5O
         kbBw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1752579470; x=1753184270; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=;
        b=HkEHedv9ksKRO2FB9dBPo//GlyFwcmzK6XSSNnd4rAmjzYUtbjdzSe4MVfY1zl7uer
         b5bKFYhwlJnsUD8UEapIeI+xd4Pq3txlaSebA1c9EPyniqRv1MUNkA5qjhsfw44KWhzM
         P9o4bTPZdOEwbwPHcX5EWwV24OM4Vxzn7lha8TeddFs1RyzCfkBEmelhk9aLYkEuB2AV
         EYizUCgqHKvuvRBMz6u+n1Rq1NSxTlWJanV6K6fdRu7B+uLpEc7c87OYBBdgRC+xeC5Q
         Sm4M7zo5/Tt0uNrHA9kM+GyGhypttcAbIMbVdKl6WMuMcANgLunO6jOtR5DjTgQ10Eq+
         9S6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1752579470; x=1753184270;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=;
        b=gBYy6Ll/hS/dgbXOFMwu2IyXuFm1zIjhpCeINEPlOpKP5UUowO3O3n93qC1t/UBu2q
         4H36BLhlJoYMV4AAwXANFTjV6FwwdgyhgGG5k8mRvDv+sfkt+CW/hGe8CdELkOtm5Xn2
         NzNjyzr5xuVfGc3yNd6vl27m59D36tZRms8JyL9z1YCu+HdfLacYilTV+c7pHmtZ9UCH
         U0XnLqpekbsaq+RaUhdzbRD5PIJAPGd72OrqgrzaRKqBNYSxpc7Vfn/vgetZ2BAnCMM7
         iboAMT/3oiEz+uERpAneDYej8Djoy5XhnWi1w2FuM9HzpETepkfTMCradpCWb4iQMQbk
         rdtA==
X-Forwarded-Encrypted: i=2; AJvYcCUU/qZtoeqph/t9GWZSKgidj+njVTpYtB/7U2ViiXc0X/oHmrzFkcCA/u5Be1V7OUqKO5pEIAJrl6Xu@gnusha.org
X-Gm-Message-State: AOJu0YxNC6hSro3nsxkG6g5eNmcp97plVa607ODa3nkRXtNdVw9l0DlG
	Gj+T7atBR74f2JZPXc5axUCY1f26mrFkTX5TPgtzfNEhjg2e3BVWaQCn
X-Google-Smtp-Source: AGHT+IFNGC0/pqfByk85TQiuVQRn6V95uT5AGNcvF9qxW2Yk6Uk2JqCj5OrlEG+z/U8OA3x3VdZNSw==
X-Received: by 2002:a05:6902:2208:b0:e82:13f4:6156 with SMTP id 3f1490d57ef6-e8bb6d10a9emr3162361276.13.1752579470120;
        Tue, 15 Jul 2025 04:37:50 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe1sJL7ZILYhX9uIRpA+TYfgZ+Ux3iCuzjXXwo138mzOQ==
Received: by 2002:a25:e052:0:b0:e8b:861f:5117 with SMTP id 3f1490d57ef6-e8b861f51c4ls3672665276.0.-pod-prod-02-us;
 Tue, 15 Jul 2025 04:37:46 -0700 (PDT)
X-Received: by 2002:a05:690c:9c0b:b0:717:c649:7849 with SMTP id 00721157ae682-71824c41569mr32328397b3.31.1752579465942;
        Tue, 15 Jul 2025 04:37:45 -0700 (PDT)
Received: by 2002:a05:600c:1c1f:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-4561334fd09ms5e9;
        Mon, 14 Jul 2025 07:44:39 -0700 (PDT)
X-Received: by 2002:a05:6000:2406:b0:3a4:f744:e00e with SMTP id ffacd0b85a97d-3b5f187d05cmr8855855f8f.4.1752504276951;
        Mon, 14 Jul 2025 07:44:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1752504276; cv=none;
        d=google.com; s=arc-20240605;
        b=kJ8+VjsxtDJ3bb1tPCaFlD6nY8Q2zr2u+ndjUdy9revC+8oJMfz6MNzeJ3qMNPmVWr
         67p+bq3nh/0T9Q8LaEnTmGxAIIYQozXTcn0J+SPawC4gTzysc2HPB6F7/+RkwUOMrdwn
         ePs/us8SYfPeqkU2K+oNYX9X0cnqnQgPO8L2PsKNYgSJO+JxYWUe5RMSHafDSankDBUw
         aNn1rDyqC7BNqy/UVvj6T95o03Y6+IRRFA3U1zCprmlhMSL53Dt360cLfF8Y/TPDb+Ks
         NZ+kCENMkSijMEv5bsIsJ4Dp+fW5f87io80oSQbQpjhVF0UPnK21FLsx4H3Mf5Z8VcGK
         MPeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=Pv4vObT/XoJYjvfwTXYNDegke/0Mx5gjlK5189q0hPs=;
        fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=;
        b=JMSE7GRbaUS/Qukr6Gph7yf1AnPJd4t94oqw0sPEiX8Dozjc+n8DrQWRF6455Vs7mb
         qywwrKinV3I38lWI3IwLs5wF8PUNFmLP73I8W+0KJ3OMVvzmrXL/IXfxBdJDTrjdRF+r
         azxxDlR9AT6Bc6McZ+SGT6DHjbYx4xAi3C67Az7TSBaBXCpoMVJU/sLr/1QH8a75JVNP
         s8AjF3TN1JF9C5sbqXPMEY9M0VicQeK54jD1i30rCbDd5jGUMcUEgYh558DQZpf1uG9d
         lssrkwZD8Y9qpULTJXRC1i3Rm3Nhta2erbstCeD1WcNZ4f17JpXp9zjVp7OJvShA+fk0
         lJkA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-454dd26d5b4si1644195e9.0.2025.07.14.07.44.36
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 14 Jul 2025 07:44:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16;
Date: Mon, 14 Jul 2025 14:44:32 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Make pathological transactions with more than
 2500 legacy signature operations non-standard
Message-ID: <baUD_4coLcyQ0vkoOaIzl8KFWTo3Mer27YYzDDCbffdbiJyOktRD_Y5u5OkfzSA3m9uJ84EZuEdbybdKTDElD_8_70vbJimDgen252hVRIo=@protonmail.com>
In-Reply-To: <e27c5b87-3be2-4ed0-9000-84822ca84c23n@googlegroups.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>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 01f4e102f6ffd4548f33cde3d4f6ef04d3451a22
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_5m6BPY2mbFkeLO89WuAhY5z9fogv3SBKrsyYBZFYyo"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

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

Hi Antoine,

Could you please clearly describe the "attack" with a clear threat model? I=
 don't think what you describe is an issue under any realistic threat model=
, much less how it would only materialize with BIP54's sigop limit but 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 implementer=
 and clearly states "count the number of [sigops] in the input scriptSig an=
d previous output's scriptPubKey". Signature operations in these fields pre=
ceded Segwit (which requires the scriptSig to be empty and the prevout's sc=
riptPubKey to be pushonly).

> I think there are some implications about all of this for some use-cases =
designers,
> e.g for massive Coinjoin

Any remotely sane transaction would run into the standardness size limit be=
fore running into this limit. Only a pathological transaction which tries t=
o increase its validation cost may run into this limit while being standard=
 according to today's Core policy. See 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 <antoine.riard@gmail=
.com> wrote:

> Hi Poinsot,
>
> Not necessarily, if you go to multi-sign the first input of your second-s=
tage txn with
> SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are =
not commited.
> The second input can be a legacy input, even if it's altered in-flight (e=
.g flipping
> the S component of the ECDSA sig), it's breaking your sig hash for the se=
cond input,
> but not the sighash for the "contract" multi-signed input. Very practical=
 for doing
> unilateral fee-bumping.
>
> It's a problem if you do multi-stage for an off-chain construction, as th=
e third order
> tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and implic=
itly 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 in validating
> a transaction. It applies to all transactions in the block except the coi=
nbase transaction.
> For each input in the transaction, count the number of CHECKSIG and CHECK=
MULTISIG in the
> input scriptSig and previous output's scriptPubKey, including the P2SH re=
deemScript".
>
> I do think it would be clearer to say that Segwit spends are logically ex=
cluded due
> to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size() =
!=3D 0 in
> `VerifyScript()`) and b) a witness program must be a data push and as suc=
h it's
> never a scriptCode that can contain a CHECKSIG ops. Accounting is implici=
tly always
> 0 for Segwit spends.
>
> There is no definition of what make a spend a "legacy" input, other than =
it's not
> a Segwit spend. Technically, the CHECKSIG operations are committed in the=
 witness
> program, which is itself part of the scriptPubkey... While indeed, curren=
tly the code
> is properly dissociating the verifcation of the legacy spends from the wi=
tness program,
> it's hard to say the limit is correctly implemented in the complete lack =
of available code.
>
> The limit could be implemented in EvalScript(), but I'm not sure it's exa=
ctly what
> you have in mind. Thanks by advance if there is code and specification de=
fining
> 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 =
designers,
> e.g for massive Coinjoin, if in the collaborative transaction constructio=
n any party
> proposes a scriptpubkey with a huge number of sigs to reach the limit, no=
w if you
> don't verify the script sanity against this new rule, you might have cont=
ributed
> an input in a transaction that is never going to be valid. Some kind of d=
enial-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 expli=
ctly
> requests segwit input at `tx_add_input` reception), I'm not sure for any =
coinjoin
> or multi-party tx construction stuff that might be affected by a new DoS =
vector
> as soon as this starts to be a policy rule spread substantially on the ne=
twork.
>
> It's not to say that this limit shouldn't be deployed, but in my opinion =
it's
> wise to advertise more towards multi-party use-cases maintainers and devs=
 the
> potential implications of the deployment of this rule, as soon as it's po=
licy.
>
> 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 construc=
tions use Segwit inputs, as they would be trivially broken by txid malleabi=
lity otherwise.
>>
>> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard <antoin...@gmail.co=
m> wrote:
>>
>>> Hi Poinsot,
>>>
>>> Thanks for the collection of historical txn hitting the proposed new li=
mit.
>>>
>>> The only long-term downside coming immediately out of mind, if the rule=
 becomes consensus
>>> in the future, it's the implicit limitation it would make on the multi-=
party dimensions
>>> of off-chain constructions. In the past, I made really rough math for 1=
000-sized participants
>>> payments pools, where for the funding_tx, you have the 1000 participant=
s contributing
>>> one input with one sig for each [0].
>>>
>>> In my understanding the new limit of 2500 signatures operation would ma=
ke a hard-limit
>>> for the number of participants entering in such construction, without o=
ther tricks that
>>> are consuming more block space. One can note the downside on funding tx=
 of high-order
>>> off-chain construction, if a max tx size consensus limit is introduced =
in the future.
>>>
>>> Of course, I do not deny the DoS rational of introducing the 2500 sig l=
imit and it's
>>> very needed. At the same time, we should be careful of not closing too =
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 introdu=
ce new opcode
>>> or segwit versions scripts (e.g grafroot or entroot-based pool construc=
tion), which
>>> wouldn't be subject to the new limit, and as such more scalable. If I'm=
 correct, I
>>> think it's all about how the limit is implemented to parse current scri=
pts to be
>>> spent.
>>>
>>> But it's hard to say without code available to review and reason. May I=
 kindly note
>>> there is no reference implementation attached in the current BIP54 docu=
ment [1]. Even,
>>> if it's often updated, it's always fruitful to have code under the eyes=
 for review.
>>>
>>> This might be the kind of concern (very) far down the line...but preser=
ving the
>>> evolvability of the consensus rules is a good property to care about, i=
n my humble
>>> opinion.
>>>
>>> Best,
>>> Riard
>>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2
>>>
>>> [0] [https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail=
.gmail.com/](https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5c=
J4h12TuG8tnWswqbfAnRdA@mail.gmail.com/)
>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
>>>
>>> Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3=
=A9crit :
>>>
>>>> Hi everyone,
>>>>
>>>> To mitigate high block validation time, BIP54 proposes to make transac=
tions which require more than
>>>> 2500 legacy signature operations invalid by consensus. The 2500 figure=
 was chosen as the tightest
>>>> value that did not make any non-pathological currently standard transa=
ction invalid.
>>>>
>>>> No transaction in Bitcoin's history would have both hit the BIP54 sigo=
p limit and been standard
>>>> according to today's Bitcoin Core policy[^0]. But what happened in the=
 past doesn't matter as much
>>>> as the fact that it is possible today to create a pathological standar=
d transaction that is
>>>> BIP54-invalid.
>>>>
>>>> This opens up a major DoS vector against unupgraded miners if BIP54 ev=
er gets activated in these
>>>> conditions. Therefore i propose to make such transactions non-standard=
 and hold off activation of
>>>> BIP54 until we have good reasons to believe that the vast majority of =
the hashrate won't create a
>>>> block containing such a transaction.
>>>>
>>>> Doing so gives better guarantees in case BIP54 is ever considered for =
activation, and comes at
>>>> virtually no cost since these pathological transactions have never bee=
n used and serve no purpose
>>>> beyond increasing the cost of validation. Bitcoin Core PR #32521 imple=
ments this change, which i
>>>> hope to get into the upcoming 30.0 release as well as backported to pr=
evious versions.
>>>>
>>>> Best,
>>>> Antoine Poinsot
>>>>
>>>> [^0]: Here the full list of historical transactions that would have hi=
t the BIP54 sigops limit:
>>>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
>>>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
>>>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
>>>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
>>>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
>>>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
>>>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
>>>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
>>>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
>>>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
>>>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
>>>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
>>>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
>>>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
>>>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
>>>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
>>>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
>>>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
>>>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
>>>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
>>>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
>>>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
>>>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
>>>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
>>>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
>>>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
>>>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
>>>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
>>>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
>>>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
>>>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
>>>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
>>>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
>>>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
>>>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
>>>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
>>>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
>>>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
>>>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
>>>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
>>>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
>>>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
>>>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
>>>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
>>>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
>>>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
>>>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
>>>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
>>>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
>>>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
>>>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
>>>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
>>>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
>>>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
>>>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
>>>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
>>>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
>>>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
>>>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
>>>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
>>>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
>>>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
>>>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
>>>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
>>>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
>>>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
>>>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
>>>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
>>>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
>>>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
>>>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
>>>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
>>>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
>>>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
>>>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
>>>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
>>>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
>>>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
>>>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
>>>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
>>>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
>>>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
>>>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
>>>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
>>>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
>>>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
>>>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
>>>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
>>>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
>>>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
>>>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
>>>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9
>>
>>> --
>>> You received this message because you are subscribed to the Google Grou=
ps "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an email to bitcoindev+...@googlegroups.com.
>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoin=
dev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com.
>
> --
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com.

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
baUD_4coLcyQ0vkoOaIzl8KFWTo3Mer27YYzDDCbffdbiJyOktRD_Y5u5OkfzSA3m9uJ84EZuEd=
bybdKTDElD_8_70vbJimDgen252hVRIo%3D%40protonmail.com.

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

<div>Hi Antoine,</div><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 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);">Could you please clear=
ly describe the "attack" with a clear threat model? I don't think what you =
describe is an issue under any realistic threat model, much less how it wou=
ld only materialize with BIP54's sigop limit but not with the existing sigo=
p 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: 14px; color: rgb(=
0, 0, 0); background-color: rgb(255, 255, 255);"><blockquote style=3D"borde=
r-left: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); pad=
ding-left: 10px; color: rgb(102, 102, 102);"><div><span><span>Anyway, the c=
urrent 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); backg=
round-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;" class=3D"protonmail_signature_block proton=
mail_signature_block-empty">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">The BIP54 s=
pecifications are written from the perspective of an implementer and clearl=
y states "count the number of [sigops] in the input
scriptSig and previous output's scriptPubKey". Signature operations in thes=
e fields preceded Segwit (which requires the scriptSig to be empty and the =
prevout's scriptPubKey to be pushonly).</div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;"><br></div><blockquote style=3D"border-lef=
t: 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, s=
ans-serif; 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: A=
rial, sans-serif; font-size: 14px;">e.g for massive Coinjoin</div></blockqu=
ote><br><div style=3D""><span style=3D"font-family: Arial, sans-serif; font=
-size: 14px; font-weight: 400; color: rgb(0, 0, 0); background-color: rgb(2=
55, 255, 255);">Any remotely sane transaction would run</span> into the sta=
ndardness size limit before running into this limit. Only a pathological tr=
ansaction which tries to increase its validation cost may run into this lim=
it while being standard according to today's Core policy. See <span><a targ=
et=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://github.c=
om/bitcoin/bips/blob/master/bip-0054.md#user-content-fn-7-21829941cd04259d8=
6862ad3baa11d05">https://github.com/bitcoin/bips/blob/master/bip-0054.md#us=
er-content-fn-7-21829941cd04259d86862ad3baa11d05</a></span>.</div><div styl=
e=3D""><br></div><div style=3D"">Best,<br>Antoine<br></div><div class=3D"pr=
otonmail_quote">
        On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard &lt;antoine.=
riard@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            Hi Poinsot,<br><br>Not necessarily, if you go to multi-sign the=
 first input of your second-stage txn with<br>SIGHASH_SINGLE | ANYONECANPAY=
, the hashPrevouts and the hashSequence are not commited.<br>The second inp=
ut can be a legacy input, even if it's altered in-flight (e.g flipping<br>t=
he S component of the ECDSA sig), it's breaking your sig hash for the secon=
d input,<br>but not the sighash for the "contract" multi-signed input. Very=
 practical for doing<br>unilateral fee-bumping.<br><br>It's a problem if yo=
u do multi-stage for an off-chain construction, as the third order<br>tx, e=
ven with SIGHASH_SINGLE would commit to `outpoint` field, and implicitly th=
e<br>parent txid of the malleable second input.<br><br>...<br><br>Anyway, t=
he current BIP54 says the following nothing about legacy inputs:<br><br>"A =
limit is set on the number of potentially executed signature operations in =
validating<br>a transaction. It applies to all transactions in the block ex=
cept the coinbase transaction.<br>For each input in the transaction, count =
the number of CHECKSIG and CHECKMULTISIG in the<br>input scriptSig and prev=
ious output's scriptPubKey, including the P2SH redeemScript".<br><br>I do t=
hink it would be clearer to say that Segwit spends are logically excluded d=
ue<br>to a) a Segwit spend's scriptSig must be always empty (`scriptSig.siz=
e() !=3D 0 in<br>`VerifyScript()`) and b) a witness program must be a data =
push and as such it's<br>never a scriptCode that can contain a CHECKSIG ops=
. Accounting is implicitly always<br>0 for Segwit spends.<br><br>There is n=
o definition of what make a spend a "legacy" input, other than it's not<br>=
a Segwit spend. Technically, the CHECKSIG operations are committed in the w=
itness<br>program, which is itself part of the scriptPubkey... While indeed=
, currently the code<br>is properly dissociating the verifcation of the leg=
acy spends from the witness program,<br>it's hard to say the limit is corre=
ctly implemented in the complete lack of available code.<br><br>The limit c=
ould be implemented in EvalScript(), but I'm not sure it's exactly what<br>=
you have in mind. Thanks by advance if there is code and specification defi=
ning<br>more precisly what is understood as a legacy input under this BIP p=
roposal.<br><br>...<br><br>I think there are some implications about all of=
 this for some use-cases designers,<br>e.g for massive Coinjoin, if in the =
collaborative transaction construction any party<br>proposes a scriptpubkey=
 with a huge number of sigs to reach the limit, now if you<br>don't verify =
the script sanity against this new rule, you might have contributed<br>an i=
nput in a transaction that is never going to be valid. Some kind of denial-=
of-service,<br>and the reason initially opt-in rbf was proposed to be remov=
e.<br><br>While this is not a concern for lightning (bc the dual funding sp=
ec explictly<br>requests segwit input at `tx_add_input` reception), I'm not=
 sure for any coinjoin<br>or multi-party tx construction stuff that might b=
e affected by a new DoS vector<br>as soon as this starts to be a policy rul=
e spread substantially on the network.<br><br>It's not to say that this lim=
it shouldn't be deployed, but in my opinion it's<br>wise to advertise more =
towards multi-party use-cases maintainers and devs the<br>potential implica=
tions of the deployment of this rule, as soon as it's policy.<br><br>Best,<=
br>Riard<br>OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06b=
bbac2afc902<br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
attr">Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=
=A9crit :<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 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 conc=
erns legacy signature operations. Off-chain constructions use Segwit inputs=
, as they would be trivially broken by txid malleability otherwise.<br></di=
v>
<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 href=3D=
"" data-email-masked=3D"" rel=3D"noreferrer nofollow noopener" style=3D"poi=
nter-events: none;">antoin...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            Hi Poinsot,<br><br>Thanks for the collection of historical txn =
hitting the proposed new limit.<br><br>The only long-term downside coming i=
mmediately out of mind, if the rule becomes consensus<br>in the future, it'=
s the implicit limitation it would make on the multi-party dimensions<br>of=
 off-chain constructions. In the past, I made really rough math for 1000-si=
zed participants<br>payments pools, where for the funding_tx, you have the =
1000 participants contributing<br>one input with one sig for each [0]. <br>=
<br>In my understanding the new limit of 2500 signatures operation would ma=
ke a hard-limit<br>for the number of participants entering in such construc=
tion, without other tricks that<br>are consuming more block space. One can =
note the downside on funding tx of high-order<br>off-chain construction, if=
 a max tx size consensus limit is introduced in the future.<br><br>Of cours=
e, I do not deny the DoS rational of introducing the 2500 sig limit and it'=
s<br>very needed. At the same time, we should be careful of not closing too=
 much doors for<br>future off-chain constructions and long-term tx throughp=
ut scalability.<br><br>I do believe, it's always technically possible in th=
e future to introduce new opcode<br>or segwit versions scripts (e.g grafroo=
t or entroot-based pool construction), which<br>wouldn't be subject to the =
new limit, and as such more scalable. If I'm correct, I<br>think it's all a=
bout how the limit is implemented to parse current scripts to be<br>spent.<=
br><br>But it's hard to say without code available to review and reason. Ma=
y I kindly note<br>there is no reference implementation attached in the cur=
rent BIP54 document [1]. Even,<br>if it's often updated, it's always fruitf=
ul to have code under the eyes for review.<br><br>This might be the kind of=
 concern (very) far down the line...but preserving the<br>evolvability of t=
he consensus rules is a good property to care about, in my humble<br>opinio=
n.<br><br>Best,<br>Riard<br>OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0a=
db2<br><br>[0] <a href=3D"https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd=
-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/" target=3D"_blank" rel=
=3D"noreferrer nofollow noopener" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha.org/pi/bitcoindev/CALZpt%2BE%2BeKK=
tOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/&amp;source=3Dgmail&=
amp;ust=3D1752379906853000&amp;usg=3DAOvVaw2MSeddE4_aRmyLNy3zpS7Z">https://=
gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.gmail.com/</a><b=
r>[1] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0054.md" t=
arget=3D"_blank" rel=3D"noreferrer nofollow noopener" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/b=
ips/blob/master/bip-0054.md&amp;source=3Dgmail&amp;ust=3D1752379906853000&a=
mp;usg=3DAOvVaw2JCggeMRa2si0hVTFt8X4H">https://github.com/bitcoin/bips/blob=
/master/bip-0054.md</a><br><br><div class=3D"gmail_quote"><div dir=3D"auto"=
 class=3D"gmail_attr">Le mercredi 2 juillet 2025 =C3=A0 09:54:33 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">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's history would have both hit the BIP54 sigop=
 limit and been standard
<br>according to today's Bitcoin Core policy[^0]. But what happened in the =
past doesn't matter as much
<br>as the fact that it is possible today to create a pathological standard=
 transaction that is
<br>BIP54-invalid.
<br>
<br>This opens up a major DoS vector against unupgraded miners if BIP54 eve=
r gets activated in these
<br>conditions. Therefore i propose to make such transactions non-standard =
and hold off activation of
<br>BIP54 until we have good reasons to believe that the vast majority of t=
he hashrate won't create a
<br>block containing such a transaction.
<br>
<br>Doing so gives better guarantees in case BIP54 is ever considered for a=
ctivation, and comes at
<br>virtually no cost since these pathological transactions have never been=
 used and serve no purpose
<br>beyond increasing the cost of validation. Bitcoin Core PR #32521 implem=
ents this change, which i
<br>hope to get into the upcoming 30.0 release as well as backported to pre=
vious versions.
<br>
<br>Best,
<br>Antoine Poinsot
<br>
<br>[^0]: Here the full list of historical transactions that would have hit=
 the BIP54 sigops limit:
<br>    - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
<br>    - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
<br>    - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
<br>    - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
<br>    - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
<br>    - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
<br>    - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
<br>    - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
<br>    - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
<br>    - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
<br>    - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
<br>    - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
<br>    - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
<br>    - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
<br>    - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
<br>    - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
<br>    - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
<br>    - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
<br>    - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
<br>    - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
<br>    - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
<br>    - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
<br>    - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
<br>    - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
<br>    - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
<br>    - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
<br>    - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
<br>    - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
<br>    - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
<br>    - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
<br>    - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
<br>    - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
<br>    - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
<br>    - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
<br>    - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
<br>    - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
<br>    - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
<br>    - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
<br>    - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
<br>    - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
<br>    - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
<br>    - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
<br>    - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
<br>    - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
<br>    - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
<br>    - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
<br>    - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
<br>    - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
<br>    - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
<br>    - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
<br>    - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
<br>    - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
<br>    - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
<br>    - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
<br>    - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
<br>    - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
<br>    - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
<br>    - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
<br>    - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
<br>    - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
<br>    - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
<br>    - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
<br>    - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
<br>    - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
<br>    - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
<br>    - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
<br>    - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
<br>    - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
<br>    - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
<br>    - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
<br>    - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
<br>    - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
<br>    - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
<br>    - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
<br>    - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
<br>    - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
<br>    - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
<br>    - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
<br>    - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
<br>    - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
<br>    - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
<br>    - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
<br>    - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
<br>    - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
<br>    - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
<br>    - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
<br>    - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
<br>    - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
<br>    - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
<br>    - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
<br>    - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
<br>    - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9
<br></blockquote></div>

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

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"" rel=3D"noreferrer nofollow noopener" data-email-masked=
=3D"" style=3D"pointer-events: none;">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=3D1752379906853000&amp;usg=3DAOvVaw2mB64uSrvhu217d2jj=
Kcaw">https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-=
1d102477ccfdn%40googlegroups.com</a>.<br>

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

<p></p>

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

        </blockquote><br>
    </div>

<p></p>

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

--b1=_5m6BPY2mbFkeLO89WuAhY5z9fogv3SBKrsyYBZFYyo--