From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <5e84e244-c99d-4825-8387-8333a6587d77n@googlegroups.com> In-Reply-To: References: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 =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 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 >>> >>> [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,

> 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

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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* BOL= T #2:
=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: ...
=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`
=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 */
=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)))
=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");

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

Of course Bob can be very successful in= sorting standard vs non-standard 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 threat mod= el in a realistic fashion:
https://gnusha.org/pi/bitcoindev/CALZpt+HXB= =3Dxh3qtxJFM7yUzRu1uj-pPtLQmT=3D5QV0dNfVuTpfQ@mail.gmail.com/

&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.

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

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

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 policyrule 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
(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.

Best,
Riard
OTS h= ash: 610a08345b4e79f0203904948b2ad2f689140ae0373732b31d6d981756e2e698
=
Le vendre= di 25 juillet 2025 =C3=A0 17:56:32 UTC+1, Antoine Poinsot a =C3=A9crit=C2= =A0:
Antoine,

Attempting to contribute a non-s= tandard input to a multiparty transaction creation protocol is not an "= ;attack" nor something you can prevent participant are not trusted. I = am not sure where this is going.

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'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's using S= egwit input, is also a good example of the type of pathological transaction= s i am talking about.

Best,
Antoine
=20
=20
=20
On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard <antoin...@gmail.com> wrote:
Hi Poinsot,

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

Yes, for sure. So let's say you h= ave a Coinjoin collaborated among 10 pseudonymous peers (...they rely as mu= ch as they can on
the chain as the source of truth to preserve the overa= ll pseudonymity so hardness to evaluate "trustworthiness" of a sp= ecific peer),
where there is a single peer randomly designated as the co= ordinator. Each peer contributes an input towards the common transaction.
Let says the 1st participant is the coordinator, the 2nd to 9th parti= cipant are participants only contributing P2WPKH, for which
the new MAX_= TX_LEGACY_SIGOPS is not a problem at all. The 10th participant deliberately= contribute a legacy input with empty junk
OP_CHECKMULTISIGs for them to= be accounted at MAX_PUBKEYS_PER_MULTISIG while being space-wise efficient.=

This legacy input is of minimal satoshi value (<=3D to inputs 1t= h to 9th while still > to Coinjoin protocol-defined limit),
so the co= st for the malicious 10th participant is minimized. All the inputs are asse= mbled together in the multi-party transaction,
however this transaction = is now policy invalid in reason of MAX_TX_LEGACY_SIGOPS due to the single r= edeem script contributed by
the 10th input.

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
among participants, identifying the = source of error can be a hard task. Unless the latest flavour of the policy= rules are run, it
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,
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 b= y reaching out to a miner private API, though if you''re doing
a= coinjoin it is less than optimal to maximize confidentiality of the flow.<= br>
Note this threat model has been already considered in the past here:=
that://diy= hpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-d= ev/2021-May/003033.txt

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

Currently, the problem would exist thou= gh only if the built Coinjoin transaction would have more than 80k sigops. = The reduction
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's<= br>cheaper fee-wise to contribute an input to reach the ~2500 limit, than t= he upper 80k limit itself.

In my view, it's not really the respo= nsibility of a full-node to care about that kind of issues for downstream s= oftwares. However,
mentioning in release notes that the limit might affe= ct tx collaborative construction for downstream softwares devs and that act= ion
might have to be taken at their appreciation (as they're the one= s with the best know-how about their protocols) can be a courteous
note.= IMHO, assuming those kinds of threat models are realistic, it would be wel= come to be more verbose everytime there is a
_tightening_ of the policy = rules. Even if the _tightening_ is in view of a future consensus change, th= ere are all the transitory
phase during which there are more exposures t= o those kinds of DoS.

> The BIP54 specifications are written from t= he perspective of an implementer and clearly states "count the number = of [sigops] in
> the input scriptSig and previous output's script= PubKey". Signature operations in these fields preceded Segwit (which r= equires the
> scriptSig to be empty and the prevout's scriptPubKe= y to be pushonly).

Yes, I read again BIP141 around writing my previous= email. BIP141 clearly says that "a push of a version byte, plus a pus= h of a
witness program. The scriptSig must be exactly empty or validatio= n fails." So unless you have a different validation logic which
is = introduced in an unknown future for any segwit spends (OP_01 to OP_16 versi= on byte + a push of the witness program), I don't
see how the limit = could be understood to be applied to segwit spends, and more concerning imp= lemented by mistake to concern segwit
spends. For bitcoin core, the code= is very proper here in `VerifyScript` and commented accordingly.

I&= #39;m still thinking it would be good BIP stylistic to have BIP54 making an= explicit referral to BIP141 to define "legacy" inputs
by oppo= sition to "segwit" inputs, which have a precise technical definit= ion. Less a BIP is ambiguous, better it is.

> Any remotely sane tra= nsaction would run into the standardness size limit before running into thi= s limit.

=

Le lun. 14 juil. 2025 =C3=A0 15:44, Antoine Poinso= t <daro..= .@protonmail.com> a =C3=A9crit :
Hi Antoine,

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

Anyway, the current BIP54 says the = following nothing about legacy inputs:
=
<= br>
The BIP54 specif= ications are written from the perspective of an implementer and clearly sta= tes "count the number of [sigops] in the input scriptSig and previous output's scriptPubKey". Signature operation= s in these fields preceded Segwit (which requires the scriptSig to be empty= and the prevout's scriptPubKey to be pushonly).

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

<= 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 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's Core policy. See https://github.com/bitcoin/bips/blob/master/bip-0054.md#u= ser-content-fn-7-21829941cd04259d86862ad3baa11d05.
Best,
Antoine
On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard <antoin...@gmail.com<= /a>> wrote:
Hi Poinsot,

Not necessarily, if you go to multi-sign the= first input of your second-stage txn with
SIGHASH_SINGLE | ANYONECANPAY= , the hashPrevouts and the hashSequence are not commited.
The second inp= ut can be a legacy input, even if it's altered in-flight (e.g flipping<= br>the S component of the ECDSA sig), it's breaking your sig hash for t= he second 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` fi= eld, and implicitly the
parent txid of the malleable second input.
...

Anyway, the current BIP54 says the following nothing about leg= acy inputs:

"A limit is set on the number of potentially execut= ed signature operations in validating
a transaction. It applies to all t= ransactions in the block except the coinbase transaction.
For each input= in the transaction, count the number of CHECKSIG and CHECKMULTISIG in the<= br>input scriptSig and previous output's scriptPubKey, including the P2= SH redeemScript".

I do think it would be clearer to say that Se= gwit spends are logically excluded due
to a) a Segwit spend's script= Sig must be always empty (`scriptSig.size() !=3D 0 in
`VerifyScript()`) = and b) a witness program must be a data push and as such it's
never = a scriptCode that can contain a CHECKSIG ops. Accounting is implicitly alwa= ys
0 for Segwit spends.

There is no definition of what make a spe= nd a "legacy" input, other than it's not
a Segwit spend. T= echnically, the CHECKSIG operations are committed in the witness
program= , which is itself part of the scriptPubkey... While indeed, currently the c= ode
is properly dissociating the verifcation of the legacy spends from t= he witness program,
it's hard to say the limit is correctly implemen= ted in the complete lack of available code.

The limit could be imple= mented in EvalScript(), but I'm not sure it's exactly what
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.

...

I think there are some implications about all of this= for some use-cases designers,
e.g for massive Coinjoin, if in the colla= borative transaction construction any party
proposes a scriptpubkey with= a huge number of sigs to reach the limit, now if you
don't verify t= he script sanity against this new rule, you might have contributed
an in= put in a transaction that is never going to be valid. Some kind of denial-o= f-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 spe= c explictly
requests segwit input at `tx_add_input` reception), I'm = not sure for any coinjoin
or multi-party tx construction stuff that migh= t be affected by a new DoS vector
as soon as this starts to be a policy = rule spread substantially on the network.

It's not to say that t= his limit shouldn't be deployed, but in my opinion it's
wise to = advertise more towards multi-party use-cases maintainers and devs the
po= tential implications of the deployment of this rule, as soon as it's po= licy.

Best,
Riard
OTS hash: c236ba440e27f6bf89db9d21f1650d945c= 92fc941bb9177dbf06bbbac2afc902
Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Ant= oine Poinsot a =C3=A9crit :
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.
Hi Poinsot,

Thanks for the collection of historical txn = hitting the proposed new limit.

The only long-term downside coming i= mmediately out of mind, if the rule becomes consensus
in the future, it&= #39;s the implicit limitation it would make on the multi-party dimensionsof off-chain constructions. In the past, I made really rough math for 100= 0-sized participants
payments pools, where for the funding_tx, you have = the 1000 participants contributing
one input with one sig for each [0]. =

In my understanding the new limit of 2500 signatures operation woul= d make a hard-limit
for the number of participants entering in such cons= truction, without other tricks that
are consuming more block space. One = can note the downside on funding tx of high-order
off-chain construction= , if a max tx size consensus limit is introduced in the future.

Of c= ourse, I do not deny the DoS rational of introducing the 2500 sig limit and= it's
very needed. At the same time, we should be careful of not clo= sing too much doors for
future off-chain constructions and long-term tx = throughput scalability.

I do believe, it's always technically po= ssible in the future to introduce new opcode
or segwit versions scripts = (e.g grafroot or entroot-based pool construction), 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 = scripts to be
spent.

But it's hard to say without code availa= ble to review and reason. May I kindly note
there is no reference implem= entation attached in the current BIP54 document [1]. Even,
if it's o= ften updated, it's always fruitful to have code under the eyes for revi= ew.

This might be the kind of concern (very) far down the line...but= preserving the
evolvability of the consensus rules is a good property t= o care about, in my humble
opinion.

Best,
Riard
OTS hash: a= 2bb9a1faf79309b039d8ae7e0b951644ca0adb2

[0] https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOX= d-8A6oThw-...@mail.gmail.com/
[1] ht= tps://github.com/bitcoin/bips/blob/master/bip-0054.md

Le mercredi 2 juill= et 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 transact= ions 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 transac= tion invalid.

No transaction in Bitcoin's history would have both hit the BIP54 s= igop 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 standard= transaction that is
BIP54-invalid.

This opens up a major DoS vector against unupgraded miners if BIP54 eve= r 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 t= he hashrate won't create a
block containing such a transaction.

Doing so gives better guarantees in case BIP54 is ever considered for a= ctivation, and comes at
virtually no cost since these pathological transactions have never been= used and serve no purpose
beyond increasing the cost of validation. Bitcoin Core PR #32521 implem= ents this change, which i
hope to get into the upcoming 30.0 release as well as backported to pre= vious versions.

Best,
Antoine Poinsot

[^0]: Here the full list of historical transactions that would have hit= the BIP54 sigops limit:
- 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
- bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683
- 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179
- 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0
- ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6
- 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09
- 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e
- d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f
- 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327
- 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f
- b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc
- c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3
- 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3
- bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
- ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363
- ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841
- dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf
- 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34
- 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e
- ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b
- 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007
- dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d
- 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e
- e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3
- 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a
- 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235
- c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629
- 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530
- 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5
- f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60
- 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57
- 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7
- 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311
- 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2
- bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f
- a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a
- fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7
- 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9
- 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f
- d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921
- 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597
- 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d
- cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8
- 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711
- 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6
- 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec
- 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda
- 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652
- e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e
- b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508
- 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261
- 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2
- fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663
- 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436
- 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7
- 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d
- 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649
- 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4
- d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1
- e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4
- a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640
- f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9
- 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404
- 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b
- c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b
- e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5
- 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd
- 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517
- d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4
- 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd
- 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04
- 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3
- bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f
- 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef
- 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e
- 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545
- b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b
- 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0
- 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276
- e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d
- 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c
- b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8
- 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641
- 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf
- e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278
- c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a
- 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521
- 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c
- 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b
- 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15
- d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797
- b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-= 1d102477ccfdn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-= 84822ca84c23n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/5e84e244-c99d-4825-8387-8333a6587d77n%40googlegroups.com.
------=_Part_425459_1446440751.1753652454875-- ------=_Part_425458_945405268.1753652454875--