From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 25 Jul 2025 09:56:41 -0700 Received: from mail-qt1-f189.google.com ([209.85.160.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ufLip-0007Ay-31 for bitcoindev@gnusha.org; Fri, 25 Jul 2025 09:56:41 -0700 Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-4ab969af6e3sf27775071cf.2 for ; Fri, 25 Jul 2025 09:56:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1753462593; cv=pass; d=google.com; s=arc-20240605; b=c0qZF1LVCF98kHCuujHx5Cm9qXVi7bntVxN2u64o28XP/WnckV1LArrleeHlaltyG/ E6NKVtTNBFg8lcjY01lEq7f5CVXSdfQKh8r4UWTqpXzwEh1cARiHR5A8Kn4xP5u8MnVr /Nl52sJZIMkkmYdnUQrrbC2CeEoAFjUszTdZ5kq4fV+iscM3L3dUZxoIVVedKWVLi1uQ b4Y7ZoE5n4103NrkmbSAKS3wpsDKZ+ttZF9ew/5TebfWWJpo0GniJSXsYBrbeJ/41zT4 /thY7wycWoSLe8oxAXopIeiH8rDcoHGCN0dhRFlPq2a6eLvvYUckl69o8zIJKF3s5OtH 6JVA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=; fh=CApDPYchAIEs7aq+YNl+giqjE3w2IszXfwQ+UtYhEmw=; b=PGoiEe/NbTDDLmqCIJXczi5nbGAQJkqbugf3bxjfpG4yWPWDc+ikuPbqDbYXR/joV+ kPe3oIQPI8so9oR5tdW/gRKA8jSDbECGRxWJ3z14vbHqVIG7ylLhevUE181Jf8NBO80V nnWxCDf5NYSTWJqhVd0jF2klVX15UGMqj9jZriXZIx9EZdU6JfTZFpdGrYwShA4AWuE0 uT4W8JVDekSrFANYAgy9R6Q2ZwAqNPd3no2+ALG4eGN5y8uhFOKwHV434415qlAQHkvX 7GSiOOJi8ZWv/sRO4MhzDmppeIW1GlKRY0nGzUED658Nepo8ovi1VHjuF/MNdWpRE7Eq Zv2A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1753462593; x=1754067393; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=; b=WYmqn4Lxd6u2gh5CPVXvcmmWa9zXH4adhcXdTM1A2R4CJRqy8moaBtCtAbxkFyifLW k8PZUaNOcePsQ33lz8/RkNzLL+L38KZId0GblMGwvD7s/v8NudRZFME42D2Ymsk2WO/o GeVdeLxVvZ3AwJDLft8H/1H4oE87oEDlfQ2dZ4p/1mhg5s+xp9XVhRBnB+FB2dMG5di7 gzgl8X872wP7OH6UA93Wd2VLA3orEtSZAXkCNc5ZlejlGkNPv8mCAxjfdX1CufahJ37v xsAq9O4MMbtFLjUkhKV/vZvouk3A9BpEJOcUD8sNQY2U3Ye/49xnZaeVBmo0Y/HURonI bhYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753462593; x=1754067393; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BTYGtNusqF69SybJa1DeK9xj2sod5XOt1MD+bNx74fI=; b=fb0Ju710MMUa1ZyVJVUQeoQaprxeiP1LA0P3eEuOSudfkA1E1u4L7+pr+SFakEHtuK wPReEyK8DwIChCcqDs+foVe1/IQ3hGH+z2W1v2xSvQBXncWUcc/VhnS5pvaGrsLGpwdO qw8xidggL4QzQymvj5B1wvSyURrJhvuQn7Udw1i++LxGD5GKA/E+/9UraMEbw1R1ZqXg yFEqg4gX/sNWyXdaUgoIsNa+aGGkt2WOwzBjwz8a9mjTy2Hn3kn9X8+4Qp2OrISXik2D VHRgecmPdCkulrbcDWmzM0fsA41UeJvpxCsHAy+il0xz1nTLUIlTwx9tCKTDlWiRGlP5 RQUQ== X-Forwarded-Encrypted: i=2; AJvYcCVlqhEpSKnAyu+w0aQ7lZbakjkDExInH3qWUnT/YFp1Bp+JxBRaaj1toHzGhS4upQ1bZCfyDywqCmE/@gnusha.org X-Gm-Message-State: AOJu0Ywk0VA/Td7ElbTU0MwxmSwHYVYq0AT4uoV/a6X3inr7O4FGL8lj 0VaMYq/p9MpTiXHPcUusnW5KXLftzv+FR7nSUCMqPCgQQOpN2/mQwDZp X-Google-Smtp-Source: AGHT+IHc62kVsmdW8h1Jac+Pk9OjgvdlEzExvIKbS530js55BdLdAo8zd4KwvjtT+X4H91gWh9gomQ== X-Received: by 2002:ac8:588c:0:b0:4a9:80f6:19ad with SMTP id d75a77b69052e-4ae8f0daa4fmr31713441cf.45.1753462592277; Fri, 25 Jul 2025 09:56:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf7JZJYZcz/a/HmcGsQqxkFsadfTZdYqEi5IrCcZH3SXw== Received: by 2002:a05:622a:552:b0:4ab:8d30:5860 with SMTP id d75a77b69052e-4ae7bd33e2bls38984771cf.1.-pod-prod-08-us; Fri, 25 Jul 2025 09:56:28 -0700 (PDT) X-Received: by 2002:a05:620a:618e:b0:7e1:90b9:6cee with SMTP id af79cd13be357-7e63c1bb434mr307391485a.58.1753462588360; Fri, 25 Jul 2025 09:56:28 -0700 (PDT) Received: by 2002:a05:6402:455b:b0:609:bcd7:3415 with SMTP id 4fb4d7f45d1cf-61496efaafcmsa12; Wed, 23 Jul 2025 14:12:33 -0700 (PDT) X-Received: by 2002:a17:907:3fa0:b0:ad8:a935:b8e8 with SMTP id a640c23a62f3a-af2f64bf8f4mr451001066b.5.1753305150253; Wed, 23 Jul 2025 14:12:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1753305150; cv=none; d=google.com; s=arc-20240605; b=FYcJ9wlkeaqd294JgxHhhjJaMWZa4lqpgoIf7Rg2YJ5wrq3C/3h8w6WVEdTqiVnw7D AilzhQi7DFFHyu2bUwddvNEm2rHUf8hwLQGf/8tWW4K7XR4ucJln/vzppIUtN6RQBmaL OMFeKwsmmh5mQvp43FyC1j9D9BzDTBfO3XuKD3OQk2pLl+N/AJPz7cNiEzARKo3IwvWk fVn2ldwkwZI6A9brN9PLUuyfxm6CF4KiSK/2r0EiDyKoVsUbHG9i7PMQwIv5bEfPZqY4 th+aqVuigF/tHh2y9SHDSlhmoPRA/Z7Pk98ozusVXgeuLAPS8EE7tui6rf3Rbu8mrhOy tyqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=wxlJvZX7RoVmxIuljNs9mlMKiGizy+QEcMpzpxdGqcY=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=XTPPBhcUtu+zEFZGOyUyvVKg02sDa5px60cw5uzRL19zOt6ijnEbvo952oU6j8ovpX hJ7yAm25I6F4odHYLp8HrSI4/gXsnu4KZWHPMYKdUiYTxUNC51MmQG8xKb0ZqrRPcRni 975+I2O6Qnn0/ShJiFOJwWiCOh/9SX3bZ9Mm9iayaSg0NFlzHbSD0Hq7nn7L6oB87V0K PdMgLDfGKCkjP3tDM6NldWdz2Ezbc57iSyyZjFHnV9/jB+GXE64eJJ3tRd5h7GHWFUJw r28c+5414EVa+0d7WcodijzL/MDV03DPaVp7w3P0ywTFFamGkl4N5jd5Zxh50XdXDAjd cX3A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-af47d14ab95si371666b.1.2025.07.23.14.12.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jul 2025 14:12:30 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Wed, 23 Jul 2025 21:12:26 +0000 To: Antoine Riard From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Make pathological transactions with more than 2500 legacy signature operations non-standard Message-ID: In-Reply-To: References: <49dyqqkf5NqGlGdinp6SELIoxzE_ONh3UIj6-EB8S804Id5yROq-b1uGK8DUru66eIlWuhb5R3nhRRutwuYjemiuOOBS2FQ4KWDnEh0wLuA=@protonmail.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: e24753ae22b4ab8533c2974878f84a1786b09250 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UHFw8LSf; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) --b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Antoine, Attempting to contribute a non-standard input to a multiparty transaction c= reation protocol is not an "attack" nor something you can prevent participa= nt are not trusted. I am not sure where this is going. Regarding the test at the end of your email, it is spending p2wsh inputs. T= he newly introduced limit only applies to inputs spending legacy scripts. T= hat said, it is indeed possible to create a transaction which is standard t= oday but would run in this new limit. Otherwise introducing the limit would= n't be necessary in the first place. My point is just that any such transac= tion would be pathological. Examples are constructed in the tests of the PR= linked in OP. Your test, although it's using Segwit input, is also a good = example of the type of pathological transactions i am talking about. Best, Antoine On Monday, July 21st, 2025 at 6:14 PM, Antoine Riard wrote: > Hi Poinsot, > >> Could you please clearly describe the "attack" with a clear threat model= ? I don't think what you describe is an issue under any >> realistic threat model, much less how it would only materialize with BIP= 54's sigop limit but not with the existing sigop limit. > > Yes, for sure. So let's say you have a Coinjoin collaborated among 10 pse= udonymous peers (...they rely as much as they can on > the chain as the source of truth to preserve the overall pseudonymity so = hardness to evaluate "trustworthiness" of a specific peer), > where there is a single peer randomly designated as the coordinator. Each= peer contributes an input towards the common transaction. > > Let says the 1st participant is the coordinator, the 2nd to 9th participa= nt are participants only contributing P2WPKH, for which > the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participan= t deliberately contribute a legacy input with empty junk > OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MULTISIG wh= ile being space-wise efficient. > > This legacy input is of minimal satoshi value (<=3D to inputs 1th to 9th = while still > to Coinjoin protocol-defined limit), > so the cost for the malicious 10th participant is minimized. All the inpu= ts are assembled together in the multi-party transaction, > however this transaction is now policy invalid in reason of MAX_TX_LEGACY= _SIGOPS due to the single redeem script contributed by > the 10th input. > > In the lack of awareness of the policy rule by the coordinator, or by any= participant if the Coinkoin protocol is fully distributed > among participants, identifying the source of error can be a hard task. U= nless the latest flavour of the policy rules are run, it > might be just a generic policy error caught by the coordinator, or even w= orst if the transaction is just flow with a raw TX message, > in the lack of REJCT msgs to discover the source of non-propagation. > > Of course there is always the option to bypass the policy rules by reachi= ng out to a miner private API, though if you''re doing > a coinjoin it is less than optimal to maximize confidentiality of the flo= w. > > Note this threat model has been already considered in the past here: > that://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail= /lightning-dev/2021-May/003033.txt > > Those are the reasons e.g for lightning only segwit inputs are accepted t= o be contributed for a collaborative transaction and > other limits are checked to sanitize the flow towards policy rule ("MAY f= ail the negotiation if `script` is non-standard" at > `tx_add_output` reception). > > Currently, the problem would exist though only if the built Coinjoin tran= saction would have more than 80k sigops. The reduction > to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in the cost = to mount that DoS attack for an adversary. I think it's > cheaper fee-wise to contribute an input to reach the ~2500 limit, than th= e upper 80k limit itself. > > In my view, it's not really the responsibility of a full-node to care abo= ut that kind of issues for downstream softwares. However, > mentioning in release notes that the limit might affect tx collaborative = construction for downstream softwares devs and that action > might have to be taken at their appreciation (as they're the ones with th= e best know-how about their protocols) can be a courteous > note. IMHO, assuming those kinds of threat models are realistic, it would= be welcome to be more verbose everytime there is a > _tightening_ of the policy rules. Even if the _tightening_ is in view of = a future consensus change, there are all the transitory > phase during which there are more exposures to those kinds of DoS. > >> The BIP54 specifications are written from the perspective of an implemen= ter and clearly states "count the number of [sigops] in >> the input scriptSig and previous output's scriptPubKey". Signature opera= tions in these fields preceded Segwit (which requires the >> scriptSig to be empty and the prevout's scriptPubKey to be pushonly). > > Yes, I read again BIP141 around writing my previous email. BIP141 clearly= says that "a push of a version byte, plus a push of a > witness program. The scriptSig must be exactly empty or validation fails.= " So unless you have a different validation logic which > is introduced in an unknown future for any segwit spends (OP_01 to OP_16 = version byte + a push of the witness program), I don't > see how the limit could be understood to be applied to segwit spends, and= more concerning implemented by mistake to concern segwit > spends. For bitcoin core, the code is very proper here in `VerifyScript` = and commented accordingly. > > I'm still thinking it would be good BIP stylistic to have BIP54 making an= explicit referral to BIP141 to define "legacy" inputs > by opposition to "segwit" inputs, which have a precise technical definiti= on. Less a BIP is ambiguous, better it is. > >> Any remotely sane transaction would run into the standardness size limit= before running into this limit. > > No, I'm not sure of that. I was having fun recently with scriptsig junkin= g transaction leveraring OP_CHECKMULTISIG: > https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a6= 8da9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756= 547R42 > It sounds you can generate transaction which are perfectly standard (i.e = under MAX_STANDARD_TX_WEIGHT) with a very high > number of sigops stuffed within. I don't remember checking all the policy= rule scenarios, but MAX_STANDAD_TX_WEIGHT is > one of the rule you _cannot_ disable or turn off on the CLI iirc. > > Best, > Riard > OTS hash: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac7= 1 > > Le lun. 14 juil. 2025 =C3=A0 15:44, Antoine Poinsot a =C3=A9crit : > >> Hi Antoine, >> >> Could you please clearly describe the "attack" with a clear threat model= ? I don't think what you describe is an issue under any realistic threat mo= del, much less how it would only materialize with BIP54's sigop limit but n= ot with the existing sigop limit. >> >>> Anyway, the current BIP54 says the following nothing about legacy input= s: >> >> The BIP54 specifications are written from the perspective of an implemen= ter and clearly states "count the number of [sigops] in the input scriptSig= and previous output's scriptPubKey". Signature operations in these fields = preceded Segwit (which requires the scriptSig to be empty and the prevout's= scriptPubKey to be pushonly). >> >>> I think there are some implications about all of this for some use-case= s designers, >>> e.g for massive Coinjoin >> >> Any remotely sane transaction would run into the standardness size limit= before running into this limit. Only a pathological transaction which trie= s to increase its validation cost may run into this limit while being stand= ard according to today's Core policy. See https://github.com/bitcoin/bips/b= lob/master/bip-0054.md#user-content-fn-7-21829941cd04259d86862ad3baa11d05. >> >> Best, >> Antoine >> On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard wrote: >> >>> Hi Poinsot, >>> >>> Not necessarily, if you go to multi-sign the first input of your second= -stage txn with >>> SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence ar= e not commited. >>> The second input can be a legacy input, even if it's altered in-flight = (e.g flipping >>> the S component of the ECDSA sig), it's breaking your sig hash for the = second input, >>> but not the sighash for the "contract" multi-signed input. Very practic= al for doing >>> unilateral fee-bumping. >>> >>> It's a problem if you do multi-stage for an off-chain construction, as = the third order >>> tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and impl= icitly the >>> parent txid of the malleable second input. >>> >>> ... >>> >>> Anyway, the current BIP54 says the following nothing about legacy input= s: >>> >>> "A limit is set on the number of potentially executed signature operati= ons in validating >>> a transaction. It applies to all transactions in the block except the c= oinbase transaction. >>> For each input in the transaction, count the number of CHECKSIG and CHE= CKMULTISIG in the >>> input scriptSig and previous output's scriptPubKey, including the P2SH = redeemScript". >>> >>> I do think it would be clearer to say that Segwit spends are logically = excluded due >>> to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size(= ) !=3D 0 in >>> `VerifyScript()`) and b) a witness program must be a data push and as s= uch it's >>> never a scriptCode that can contain a CHECKSIG ops. Accounting is impli= citly always >>> 0 for Segwit spends. >>> >>> There is no definition of what make a spend a "legacy" input, other tha= n it's not >>> a Segwit spend. Technically, the CHECKSIG operations are committed in t= he witness >>> program, which is itself part of the scriptPubkey... While indeed, curr= ently the code >>> is properly dissociating the verifcation of the legacy spends from the = witness program, >>> it's hard to say the limit is correctly implemented in the complete lac= k of available code. >>> >>> The limit could be implemented in EvalScript(), but I'm not sure it's e= xactly what >>> you have in mind. Thanks by advance if there is code and specification = defining >>> more precisly what is understood as a legacy input under this BIP propo= sal. >>> >>> ... >>> >>> I think there are some implications about all of this for some use-case= s designers, >>> e.g for massive Coinjoin, if in the collaborative transaction construct= ion any party >>> proposes a scriptpubkey with a huge number of sigs to reach the limit, = now if you >>> don't verify the script sanity against this new rule, you might have co= ntributed >>> an input in a transaction that is never going to be valid. Some kind of= denial-of-service, >>> and the reason initially opt-in rbf was proposed to be remove. >>> >>> While this is not a concern for lightning (bc the dual funding spec exp= lictly >>> requests segwit input at `tx_add_input` reception), I'm not sure for an= y coinjoin >>> or multi-party tx construction stuff that might be affected by a new Do= S vector >>> as soon as this starts to be a policy rule spread substantially on the = network. >>> >>> It's not to say that this limit shouldn't be deployed, but in my opinio= n it's >>> wise to advertise more towards multi-party use-cases maintainers and de= vs the >>> potential implications of the deployment of this rule, as soon as it's = policy. >>> >>> Best, >>> Riard >>> OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc= 902 >>> >>> Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9= crit : >>> >>>> This limit only concerns legacy signature operations. Off-chain constr= uctions use Segwit inputs, as they would be trivially broken by txid mallea= bility otherwise. >>>> >>>> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard wrote: >>>> >>>>> Hi Poinsot, >>>>> >>>>> Thanks for the collection of historical txn hitting the proposed new = limit. >>>>> >>>>> The only long-term downside coming immediately out of mind, if the ru= le becomes consensus >>>>> in the future, it's the implicit limitation it would make on the mult= i-party dimensions >>>>> of off-chain constructions. In the past, I made really rough math for= 1000-sized participants >>>>> payments pools, where for the funding_tx, you have the 1000 participa= nts contributing >>>>> one input with one sig for each [0]. >>>>> >>>>> In my understanding the new limit of 2500 signatures operation would = make a hard-limit >>>>> for the number of participants entering in such construction, without= other tricks that >>>>> are consuming more block space. One can note the downside on funding = tx of high-order >>>>> off-chain construction, if a max tx size consensus limit is introduce= d in the future. >>>>> >>>>> Of course, I do not deny the DoS rational of introducing the 2500 sig= limit and it's >>>>> very needed. At the same time, we should be careful of not closing to= o much doors for >>>>> future off-chain constructions and long-term tx throughput scalabilit= y. >>>>> >>>>> I do believe, it's always technically possible in the future to intro= duce new opcode >>>>> or segwit versions scripts (e.g grafroot or entroot-based pool constr= uction), which >>>>> wouldn't be subject to the new limit, and as such more scalable. If I= 'm correct, I >>>>> think it's all about how the limit is implemented to parse current sc= ripts to be >>>>> spent. >>>>> >>>>> But it's hard to say without code available to review and reason. May= I kindly note >>>>> there is no reference implementation attached in the current BIP54 do= cument [1]. Even, >>>>> if it's often updated, it's always fruitful to have code under the ey= es for review. >>>>> >>>>> This might be the kind of concern (very) far down the line...but pres= erving the >>>>> evolvability of the consensus rules is a good property to care about,= in my humble >>>>> opinion. >>>>> >>>>> Best, >>>>> Riard >>>>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2 >>>>> >>>>> [0] [https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@ma= il.gmail.com/](https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i= 5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com/) >>>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md >>>>> >>>>> Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a = =C3=A9crit : >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> To mitigate high block validation time, BIP54 proposes to make trans= actions which require more than >>>>>> 2500 legacy signature operations invalid by consensus. The 2500 figu= re was chosen as the tightest >>>>>> value that did not make any non-pathological currently standard tran= saction invalid. >>>>>> >>>>>> No transaction in Bitcoin's history would have both hit the BIP54 si= gop limit and been standard >>>>>> according to today's Bitcoin Core policy[^0]. But what happened in t= he past doesn't matter as much >>>>>> as the fact that it is possible today to create a pathological stand= ard transaction that is >>>>>> BIP54-invalid. >>>>>> >>>>>> This opens up a major DoS vector against unupgraded miners if BIP54 = ever gets activated in these >>>>>> conditions. Therefore i propose to make such transactions non-standa= rd and hold off activation of >>>>>> BIP54 until we have good reasons to believe that the vast majority o= f the hashrate won't create a >>>>>> block containing such a transaction. >>>>>> >>>>>> Doing so gives better guarantees in case BIP54 is ever considered fo= r activation, and comes at >>>>>> virtually no cost since these pathological transactions have never b= een used and serve no purpose >>>>>> beyond increasing the cost of validation. Bitcoin Core PR #32521 imp= lements this change, which i >>>>>> hope to get into the upcoming 30.0 release as well as backported to = previous versions. >>>>>> >>>>>> Best, >>>>>> Antoine Poinsot >>>>>> >>>>>> [^0]: Here the full list of historical transactions that would have = hit the BIP54 sigops limit: >>>>>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2 >>>>>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683 >>>>>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179 >>>>>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0 >>>>>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6 >>>>>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09 >>>>>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e >>>>>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f >>>>>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327 >>>>>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f >>>>>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc >>>>>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3 >>>>>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3 >>>>>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 >>>>>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363 >>>>>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841 >>>>>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf >>>>>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34 >>>>>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e >>>>>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b >>>>>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007 >>>>>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d >>>>>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e >>>>>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3 >>>>>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a >>>>>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235 >>>>>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629 >>>>>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530 >>>>>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5 >>>>>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60 >>>>>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57 >>>>>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7 >>>>>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311 >>>>>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2 >>>>>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f >>>>>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a >>>>>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7 >>>>>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9 >>>>>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f >>>>>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921 >>>>>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597 >>>>>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d >>>>>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8 >>>>>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711 >>>>>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6 >>>>>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec >>>>>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda >>>>>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652 >>>>>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e >>>>>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508 >>>>>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261 >>>>>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2 >>>>>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663 >>>>>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436 >>>>>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7 >>>>>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d >>>>>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649 >>>>>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4 >>>>>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1 >>>>>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4 >>>>>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640 >>>>>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9 >>>>>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404 >>>>>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b >>>>>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b >>>>>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5 >>>>>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd >>>>>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517 >>>>>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4 >>>>>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd >>>>>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04 >>>>>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3 >>>>>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f >>>>>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef >>>>>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e >>>>>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545 >>>>>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b >>>>>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0 >>>>>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276 >>>>>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d >>>>>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c >>>>>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8 >>>>>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641 >>>>>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf >>>>>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278 >>>>>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a >>>>>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521 >>>>>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c >>>>>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b >>>>>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15 >>>>>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797 >>>>>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9 >>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com. >>> >>> -- >>> You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send = an email to bitcoindev+unsubscribe@googlegroups.com. >>> To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx8= 66JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU%3D%40protonmail.com. --b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Antoine,

Attemptin= g to contribute a non-standard input to a multiparty transaction creation p= rotocol is not an "attack" nor something you can prevent participant are no= t trusted. I am not sure where this is going.

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

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

> 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 ho= w it would only materialize with BIP54's sigop limit but not with the exist= ing sigop limit.

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

Let says the 1st parti= cipant is the coordinator, the 2nd to 9th participant are participants only= contributing P2WPKH, for which
the new MAX_TX_LEGACY_SIGOPS is not a pr= oblem at all. The 10th participant deliberately contribute a legacy input w= ith empty junk
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 1th to 9th while still > to= Coinjoin protocol-defined limit),
so the cost for the malicious 10th pa= rticipant is minimized. All the inputs are assembled together in the multi-= party transaction,
however this transaction is now policy invalid in rea= son of MAX_TX_LEGACY_SIGOPS due to the single redeem script contributed by<= br>the 10th input.

In the lack of awareness of the policy rule by th= e coordinator, or by any participant if the Coinkoin protocol is fully dist= ributed
among participants, identifying the source of error can be a har= d task. Unless the latest flavour of the policy rules are run, it
might = be just a generic policy error caught by the coordinator, or even worst if = the transaction is just flow with a raw TX message,
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 reaching out to a miner pr= ivate API, though if you''re doing
a coinjoin it is less than optimal to= maximize confidentiality of the flow.

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

Those are the reasons e.g for lightnin= g only segwit inputs are accepted to be contributed for a collaborative tra= nsaction and
other limits are checked to sanitize the flow towards polic= y rule ("MAY fail the negotiation if `script` is non-standard" at
`tx_ad= d_output` reception).

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

In my view, it's not really the responsibility of a = full-node to care about that kind of issues for downstream softwares. Howev= er,
mentioning in release notes that the limit might affect tx collabora= tive construction for downstream softwares devs and that action
might ha= ve to be taken at their appreciation (as they're the ones with the best kno= w-how about their protocols) can be a courteous
note. IMHO, assuming tho= se kinds of threat models are realistic, it would be welcome to be more ver= bose everytime there is a
_tightening_ of the policy rules. Even if the = _tightening_ is in view of a future consensus change, there are all the tra= nsitory
phase during which there are more exposures to those kinds of Do= S.

> The BIP54 specifications are written from the perspective of= an implementer and clearly states "count the number of [sigops] in
>= the input scriptSig and previous output's scriptPubKey". Signature operati= ons in these fields preceded Segwit (which requires the
> scriptSig t= o be empty and the prevout's scriptPubKey to be pushonly).

Yes, I re= ad again BIP141 around writing my previous email. BIP141 clearly says that = "a push of a version byte, plus a push of a
witness program. The scriptS= ig must be exactly empty or validation fails." So unless you have a differe= nt validation logic which
is introduced in an unknown future for any seg= wit spends (OP_01 to OP_16 version byte + a push of the witness program), I= don't
see how the limit could be understood to be applied to segwit spe= nds, and more concerning implemented by mistake to concern segwit
spends= . For bitcoin core, the code is very proper here in `VerifyScript` and comm= ented accordingly.

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

> Any remotely sa= ne transaction would run into the standardness size limit before running in= to this limit.

No, I'm not sure of that. I was having fun recently = with scriptsig junking transaction leveraring OP_CHECKMULTISIG:
https://gi= thub.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#dif= f-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42It sounds you can generate transaction which are perfectly standard (i.e = under MAX_STANDARD_TX_WEIGHT) with a very high
number of sigops stuffed = within. I don't remember checking all the policy rule scenarios, but MAX_ST= ANDAD_TX_WEIGHT is
one of the rule you _cannot_ disable or turn off on t= he CLI iirc.

Best,
Riard
OTS hash: 91fad050b8b9ffdc0a25f997cc6= f77e701e039ba4415a9a7cfe7809f1aafac71

Le lun. 14 j= uil. 2025 =C3=A0 15:44, Antoine Poinsot <darosior@protonmail.com> a =C3=A9crit :

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


The BIP54 specif= ications are written from the perspective of an implementer and clearly sta= tes "count the number of [sigops] in the input scriptSig and previous output's scriptPubKey". Signature operations in thes= e fields preceded Segwit (which requires the scriptSig to be empty and the = prevout's scriptPubKey to be pushonly).

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


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-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
t= he S component of the ECDSA sig), it's breaking your sig hash for the secon= d input,
but not the sighash for the "contract" multi-signed input. Very= practical for doing
unilateral fee-bumping.

It's a problem if yo= u do multi-stage for an off-chain construction, as the third order
tx, e= ven with SIGHASH_SINGLE would commit to `outpoint` field, and implicitly th= e
parent txid of the malleable second input.

...

Anyway, t= he current BIP54 says the following nothing about legacy inputs:

"A = limit is set on the number of potentially executed signature operations in = validating
a transaction. It applies to all transactions in the block ex= cept the coinbase transaction.
For each input in the transaction, count = the number of CHECKSIG and CHECKMULTISIG in the
input scriptSig and prev= ious output's scriptPubKey, including the P2SH redeemScript".

I do t= hink it would be clearer to say that Segwit spends are logically excluded d= ue
to a) a Segwit spend's scriptSig must be always empty (`scriptSig.siz= e() !=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 always
0 for Segwit spends.

There is n= o 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 w= itness
program, which is itself part of the scriptPubkey... While indeed= , currently the code
is properly dissociating the verifcation of the leg= acy spends from the witness program,
it's hard to say the limit is corre= ctly implemented in the complete lack of available code.

The limit c= ould be implemented in EvalScript(), but I'm not sure it's exactly what
= you have in mind. Thanks by advance if there is code and specification defi= ning
more precisly what is understood as a legacy input under this BIP p= roposal.

...

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 construction any party
proposes a scriptpubkey= with a huge number of sigs to reach the limit, now if you
don't verify = the script sanity against this new rule, you might have contributed
an i= nput in a transaction that is never going to be valid. Some kind of denial-= of-service,
and the reason initially opt-in rbf was proposed to be remov= e.

While this is not a concern for lightning (bc the dual funding sp= ec explictly
requests segwit input at `tx_add_input` reception), I'm not= sure for any coinjoin
or multi-party tx construction stuff that might b= e affected by a new DoS vector
as soon as this starts to be a policy rul= e spread substantially on the network.

It's not to say that this lim= it shouldn't be deployed, but in my opinion it's
wise to advertise more = towards multi-party use-cases maintainers and devs the
potential implica= tions of the deployment of this rule, as soon as it's policy.

Best,<= br>Riard
OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06b= bbac2afc902
Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3= =A9crit :
This limit only concer= ns legacy signature operations. Off-chain constructions use Segwit inputs, = as they would be trivially broken by txid 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 limit.

The only long-term downside coming i= mmediately 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 1000-si= zed 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 would ma= ke a hard-limit
for the number of participants entering in such construc= tion, 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 cours= e, I do not deny the DoS rational of introducing the 2500 sig limit and it'= s
very needed. At the same time, we should be careful of not closing too= much doors for
future off-chain constructions and long-term tx throughp= ut scalability.

I do believe, it's always technically possible in th= e future to introduce new opcode
or segwit versions scripts (e.g grafroo= t 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 a= bout how the limit is implemented to parse current scripts to be
spent.<= br>
But it's hard to say without code available to review and reason. Ma= y I kindly note
there is no reference implementation attached in the cur= rent BIP54 document [1]. Even,
if it's often updated, it's always fruitf= ul to have code under the eyes for review.

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

Best,
Riard
OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0a= db2

[0] https://gnusha.org/pi/bitcoindev/CALZpt+E+= eKKtOXd-8A6oThw-...@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 eve= ryone,

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 sigop= 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 "= 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 "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googl= egroups.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/bitcoindev/= wHR3jprr9bydDKLOi4J0cQIe4uO5zJPfhD4g2FK8qc0nD_tSa_VXFnbXGIaLLeDuSxvdSNEdqx8= 66JWCBuCEbFOm8nNUNw4G8N_qNkAGQXU%3D%40protonmail.com.
--b1=_c2c2MSO1XaPQDv4p4adw0s2L6eQsh2GeL6n4G3vl4--