From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 25 Jul 2025 09:56:41 -0700 Received: from mail-qt1-f183.google.com ([209.85.160.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ufLio-0007Av-PC for bitcoindev@gnusha.org; Fri, 25 Jul 2025 09:56:41 -0700 Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4ab401e333bsf71502761cf.1 for ; Fri, 25 Jul 2025 09:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1753462592; x=1754067392; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=; b=AQcLGo7E4WDY/RQpbbjPhmdRTL5X4z5NxD0X0MEmlsbdc3+EXQAuwQ8xEqJuVkAdbQ z0VLNkDDC19F6msioO7zpuzG3sE+M6z+tHQiXd0DaQ+HyP0uqkwHj261k1g8qOoZsdtJ PqjNUDTxuNI2TLVtQo93dcAX65wtyCiaKGr+bBrovs3RAGoJHQUKCU4/2Ki7WdvXD0b/ R/wmST6k0vzZaIspkxvaFKwTNBvLL1wSRp9OUrQZC1iCsRBWbPefTvt5jBdc9ErDZnaD w9m6W7z2Gs6tRBq6S6NgVbuh+Qf6nuYU/tVOFagezm/8pkMDeV5EwMdMrnwKsqsZ7DhP BKDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753462592; x=1754067392; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=; b=Jb0uBcGdjeG4RTPiSclB/0vrr/vF/mFw3b0sZ3HTL3ZsGxOQgtTqkVqtt08M9II3S4 ACPIdtyO60BUok3/l46GMuTriB0U5ydKABpIKUoYg1WYMx74OWQyq8jjWP7I/4fldNT4 3j8y6Xt3BNAZ9sh76mI4W1eI3unpibOfUGJUuw2D2QpD+6CrLuQeu2EW8/mIVIQZjTco XUEGNjCc2XD1KrR6OY7s6nDsjyXPECpQY5di33UrEuyVpnDCOi2VpF6CYaPezRdadZec Jy4hRjmesrTL/72vYzoJbs7q9+FcoYmnxPIzOqfaNySwQgsLwb1IXM+HLVC63gGfWbGa D3zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753462592; x=1754067392; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=uTr9vJv1Z67BeTn5OLommubHoUN+AjKtGnxyqaZ15GE=; b=OSIPa3UyYJ3ocrpIts833HcfZbVgIZ3twESDxVin+ZDX5saj5/Iw0nOaIeJnUnuo2I qNfaDkXkAqQ5o5/BHRJU4jef67hVEPzUp4dRQgr9Q0DjtRpB3jbHRPStgqkasJWmqtUh veEjwPavfCPQgt3tr9B5QBBA9mfdcK0b2JPexCWmUi6pDX+t8eUiWkGbzbwKEfs85gA6 8L2/B21wkeIsm8pVp+LCeg9ttNqeCn93VvHM2baNuWLlRqVRVSsXwOvEy2GOWZVM6hbU e52Y/Yui99bx+30goTfKTLdzxOseOPCuac9NegJCnITpWkF+QoZSW8S6I3HXqhkp+NOI Pksg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUesqNDtyTPOcUhR7Poj4Iq1lNmxIK1tWiPs2vlLCP09nJx0RumU037WTukyHE3h96IrW3EGdZLAez7@gnusha.org X-Gm-Message-State: AOJu0YyscgLdYMHFAsHS4ZuN9pWaZeNnDofvVKs2pMyJOVpYvsMmit2l H6abi9CcCGS9+/r51SSo+E1QMkY81gFevLwRcanwacRVKHfd0NF8h4sZ X-Google-Smtp-Source: AGHT+IH8wn/azt0TQPVkdE9c3fgIxPzhPdwGc8g7d4HOgjItYc3TrEecypdcZ6wdIWhu+fR9n4CBYg== X-Received: by 2002:ad4:5aae:0:b0:6fa:a5c9:2ee7 with SMTP id 6a1803df08f44-70713bb257cmr83638196d6.8.1753462592204; Fri, 25 Jul 2025 09:56:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe7SdzZZEskfK0kQCAeHa1tzxxOeTvkQ/9wKiW8WhzKhg== Received: by 2002:a05:622a:607:b0:4ab:6f41:1efe with SMTP id d75a77b69052e-4ae7bbd6630ls45865661cf.0.-pod-prod-01-us; Fri, 25 Jul 2025 09:56:28 -0700 (PDT) X-Received: by 2002:a05:620a:8cf:b0:7e3:46da:9e2f with SMTP id af79cd13be357-7e63bfa932dmr175212485a.34.1753462588356; Fri, 25 Jul 2025 09:56:28 -0700 (PDT) Received: by 2002:a0d:d0c4:0:b0:718:5fd:a4e7 with SMTP id 00721157ae682-719b273ca77ms7b3; Wed, 23 Jul 2025 10:56:29 -0700 (PDT) X-Received: by 2002:a05:690c:3683:b0:719:5d76:74b with SMTP id 00721157ae682-719b42d1908mr49494987b3.33.1753293388276; Wed, 23 Jul 2025 10:56:28 -0700 (PDT) Date: Wed, 23 Jul 2025 10:56:27 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n@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_90820_1343623919.1753293387988" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_90820_1343623919.1753293387988 Content-Type: multipart/alternative; boundary="----=_Part_90821_386474536.1753293387988" ------=_Part_90821_386474536.1753293387988 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot, > Could you please clearly describe the "attack" with a clear threat model?= =20 I don't think what you describe is an issue under any > realistic threat model, much less how it would only materialize with=20 BIP54's sigop limit but not with the existing sigop limit. Yes, for sure. So let's say you have a Coinjoin collaborated among 10=20 pseudonymous peers (...they rely as much as they can on the chain as the source of truth to preserve the overall pseudonymity so=20 hardness to evaluate "trustworthiness" of a specific peer), where there is a single peer randomly designated as the coordinator. Each= =20 peer contributes an input towards the common transaction. Let says the 1st participant is the coordinator, the 2nd to 9th participant= =20 are participants only contributing P2WPKH, for which the new MAX_TX_LEGACY_SIGOPS is not a problem at all. The 10th participant= =20 deliberately contribute a legacy input with empty junk OP_CHECKMULTISIGs for them to be accounted at MAX_PUBKEYS_PER_MULTISIG=20 while being space-wise efficient. This legacy input is of minimal satoshi value (<=3D to inputs 1th to 9th=20 while still > to Coinjoin protocol-defined limit), so the cost for the malicious 10th participant is minimized. All the inputs= =20 are assembled together in the multi-party transaction, however this transaction is now policy invalid in reason of=20 MAX_TX_LEGACY_SIGOPS due to the single redeem script contributed by the 10th input. In the lack of awareness of the policy rule by the coordinator, or by any= =20 participant if the Coinkoin protocol is fully distributed among participants, identifying the source of error can be a hard task.=20 Unless the latest flavour of the policy rules are run, it might be just a generic policy error caught by the coordinator, or even=20 worst if the transaction is just flow with a raw TX message, in the lack of REJCT msgs to discover the source of non-propagation. =20 Of course there is always the option to bypass the policy rules by reaching= =20 out to a miner private API, though if you''re doing a coinjoin it is less than optimal to maximize confidentiality of the flow. Note this threat model has been already considered in the past here: that://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/l= ightning-dev/2021-May/003033.txt Those are the reasons e.g for lightning only segwit inputs are accepted to= =20 be contributed for a collaborative transaction and other limits are checked to sanitize the flow towards policy rule ("MAY=20 fail the negotiation if `script` is non-standard" at `tx_add_output` reception). Currently, the problem would exist though only if the built Coinjoin=20 transaction would have more than 80k sigops. The reduction to MAX_TX_LEGACY_SIGOPS is somehow a corresponding reduction in the cost to= =20 mount that DoS attack for an adversary. I think it's cheaper fee-wise to contribute an input to reach the ~2500 limit, than the= =20 upper 80k limit itself. In my view, it's not really the responsibility of a full-node to care about= =20 that kind of issues for downstream softwares. However, mentioning in release notes that the limit might affect tx collaborative=20 construction for downstream softwares devs and that action might have to be taken at their appreciation (as they're the ones with the= =20 best know-how about their protocols) can be a courteous note. IMHO, assuming those kinds of threat models are realistic, it would= =20 be welcome to be more verbose everytime there is a _tightening_ of the policy rules. Even if the _tightening_ is in view of a= =20 future consensus change, there are all the transitory phase during which there are more exposures to those kinds of DoS. > The BIP54 specifications are written from the perspective of an=20 implementer and clearly states "count the number of [sigops] in > the input scriptSig and previous output's scriptPubKey". Signature=20 operations in these fields preceded Segwit (which requires the > scriptSig to be empty and the prevout's scriptPubKey to be pushonly). Yes, I read again BIP141 around writing my previous email. BIP141 clearly= =20 says that "a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails."= =20 So unless you have a different validation logic which is introduced in an unknown future for any segwit spends (OP_01 to OP_16=20 version byte + a push of the witness program), I don't see how the limit could be understood to be applied to segwit spends, and= =20 more concerning implemented by mistake to concern segwit spends. For bitcoin core, the code is very proper here in `VerifyScript`=20 and commented accordingly. I'm still thinking it would be good BIP stylistic to have BIP54 making an= =20 explicit referral to BIP141 to define "legacy" inputs by opposition to "segwit" inputs, which have a precise technical=20 definition. Less a BIP is ambiguous, better it is. > Any remotely sane transaction would run into the standardness size limit= =20 before running into this limit.=20 No, I'm not sure of that. I was having fun recently with scriptsig junking= =20 transaction leveraring OP_CHECKMULTISIG: https://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68d= a9ce4e#diff-a304e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b75654= 7R42 It sounds you can generate transaction which are perfectly standard (i.e=20 under MAX_STANDARD_TX_WEIGHT) with a very high number of sigops stuffed within. I don't remember checking all the policy= =20 rule scenarios, but MAX_STANDAD_TX_WEIGHT is one of the rule you _cannot_ disable or turn off on the CLI iirc. Best, Riard OTS hash: 91fad050b8b9ffdc0a25f997cc6f77e701e039ba4415a9a7cfe7809f1aafac71 Le mardi 15 juillet 2025 =C3=A0 12:37:50 UTC+1, Antoine Poinsot a =C3=A9cri= t : > Hi Antoine, > > Could you please clearly describe the "attack" with a clear threat model?= =20 > I don't think what you describe is an issue under any realistic threat=20 > model, much less how it would only materialize with BIP54's sigop limit b= ut=20 > not with the existing sigop limit. > > Anyway, the current BIP54 says the following nothing about legacy inputs: > > > The BIP54 specifications are written from the perspective of an=20 > implementer and clearly states "count the number of [sigops] in the input= =20 > scriptSig and previous output's scriptPubKey". Signature operations in=20 > these fields preceded Segwit (which requires the scriptSig to be empty an= d=20 > the prevout's scriptPubKey to be pushonly). > > I think there are some implications about all of this for some use-cases= =20 > designers, > e.g for massive Coinjoin > > > Any remotely sane transaction would run into the standardness size limit= =20 > before running into this limit. Only a pathological transaction which tri= es=20 > to increase its validation cost may run into this limit while being=20 > standard according to today's Core policy. See=20 > https://github.com/bitcoin/bips/blob/master/bip-0054.md#user-content-fn-7= -21829941cd04259d86862ad3baa11d05 > . > > Best, > Antoine > On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard < > antoin...@gmail.com> wrote: > > Hi Poinsot, > > Not necessarily, if you go to multi-sign the first input of your=20 > second-stage txn with > SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are= =20 > not commited. > The second input can be a legacy input, even if it's altered in-flight=20 > (e.g flipping > the S component of the ECDSA sig), it's breaking your sig hash for the=20 > second input, > but not the sighash for the "contract" multi-signed input. Very practical= =20 > for doing > unilateral fee-bumping. > > It's a problem if you do multi-stage for an off-chain construction, as th= e=20 > third order > tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and=20 > implicitly the > parent txid of the malleable second input. > > ... > > Anyway, the current BIP54 says the following nothing about legacy inputs: > > "A limit is set on the number of potentially executed signature operation= s=20 > in validating > a transaction. It applies to all transactions in the block except the=20 > coinbase transaction. > For each input in the transaction, count the number of CHECKSIG and=20 > CHECKMULTISIG in the > input scriptSig and previous output's scriptPubKey, including the P2SH=20 > redeemScript". > > I do think it would be clearer to say that Segwit spends are logically=20 > excluded due > to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size()= =20 > !=3D 0 in > `VerifyScript()`) and b) a witness program must be a data push and as suc= h=20 > it's > never a scriptCode that can contain a CHECKSIG ops. Accounting is=20 > implicitly always > 0 for Segwit spends. > > There is no definition of what make a spend a "legacy" input, other than= =20 > it's not > a Segwit spend. Technically, the CHECKSIG operations are committed in the= =20 > witness > program, which is itself part of the scriptPubkey... While indeed,=20 > currently the code > is properly dissociating the verifcation of the legacy spends from the=20 > witness program, > it's hard to say the limit is correctly implemented in the complete lack= =20 > of available code. > > The limit could be implemented in EvalScript(), but I'm not sure it's=20 > exactly what > you have in mind. Thanks by advance if there is code and specification=20 > defining > more precisly what is understood as a legacy input under this BIP proposa= l. > > ... > > I think there are some implications about all of this for some use-cases= =20 > designers, > e.g for massive Coinjoin, if in the collaborative transaction constructio= n=20 > any party > proposes a scriptpubkey with a huge number of sigs to reach the limit, no= w=20 > if you > don't verify the script sanity against this new rule, you might have=20 > contributed > an input in a transaction that is never going to be valid. Some kind of= =20 > denial-of-service, > and the reason initially opt-in rbf was proposed to be remove. > > While this is not a concern for lightning (bc the dual funding spec=20 > explictly > requests segwit input at `tx_add_input` reception), I'm not sure for any= =20 > coinjoin > or multi-party tx construction stuff that might be affected by a new DoS= =20 > vector > as soon as this starts to be a policy rule spread substantially on the=20 > network. > > It's not to say that this limit shouldn't be deployed, but in my opinion= =20 > it's > wise to advertise more towards multi-party use-cases maintainers and devs= =20 > the > potential implications of the deployment of this rule, as soon as it's=20 > policy. > > Best, > Riard > OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc90= 2 > Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9cr= it : > >> This limit only concerns legacy signature operations. Off-chain=20 >> constructions use Segwit inputs, as they would be trivially broken by tx= id=20 >> malleability otherwise. >> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard =20 >> wrote: >> >> Hi Poinsot, >> >> Thanks for the collection of historical txn hitting the proposed new=20 >> limit. >> >> The only long-term downside coming immediately out of mind, if the rule= =20 >> becomes consensus >> in the future, it's the implicit limitation it would make on the=20 >> multi-party dimensions >> of off-chain constructions. In the past, I made really rough math for=20 >> 1000-sized participants >> payments pools, where for the funding_tx, you have the 1000 participants= =20 >> contributing >> one input with one sig for each [0].=20 >> >> In my understanding the new limit of 2500 signatures operation would mak= e=20 >> a hard-limit >> for the number of participants entering in such construction, without=20 >> other tricks that >> are consuming more block space. One can note the downside on funding tx= =20 >> of high-order >> off-chain construction, if a max tx size consensus limit is introduced i= n=20 >> the future. >> >> Of course, I do not deny the DoS rational of introducing the 2500 sig=20 >> limit and it's >> very needed. At the same time, we should be careful of not closing too= =20 >> much doors for >> future off-chain constructions and long-term tx throughput scalability. >> >> I do believe, it's always technically possible in the future to introduc= e=20 >> new opcode >> or segwit versions scripts (e.g grafroot or entroot-based pool=20 >> construction), which >> wouldn't be subject to the new limit, and as such more scalable. If I'm= =20 >> correct, I >> think it's all about how the limit is implemented to parse current=20 >> scripts to be >> spent. >> >> But it's hard to say without code available to review and reason. May I= =20 >> kindly note >> there is no reference implementation attached in the current BIP54=20 >> document [1]. Even, >> if it's often updated, it's always fruitful to have code under the eyes= =20 >> for review. >> >> This might be the kind of concern (very) far down the line...but=20 >> preserving the >> evolvability of the consensus rules is a good property to care about, in= =20 >> my humble >> opinion. >> >> Best, >> Riard >> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2 >> >> [0]=20 >> https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail.gmail= .com/=20 >> >> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md >> >> Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3= =A9crit : >> >>> Hi everyone,=20 >>> >>> To mitigate high block validation time, BIP54 proposes to make=20 >>> transactions which require more than=20 >>> 2500 legacy signature operations invalid by consensus. The 2500 figure= =20 >>> was chosen as the tightest=20 >>> value that did not make any non-pathological currently standard=20 >>> transaction invalid.=20 >>> >>> No transaction in Bitcoin's history would have both hit the BIP54 sigop= =20 >>> limit and been standard=20 >>> according to today's Bitcoin Core policy[^0]. But what happened in the= =20 >>> past doesn't matter as much=20 >>> as the fact that it is possible today to create a pathological standard= =20 >>> transaction that is=20 >>> BIP54-invalid.=20 >>> >>> This opens up a major DoS vector against unupgraded miners if BIP54 eve= r=20 >>> gets activated in these=20 >>> conditions. Therefore i propose to make such transactions non-standard= =20 >>> and hold off activation of=20 >>> BIP54 until we have good reasons to believe that the vast majority of= =20 >>> the hashrate won't create a=20 >>> block containing such a transaction.=20 >>> >>> Doing so gives better guarantees in case BIP54 is ever considered for= =20 >>> activation, and comes at=20 >>> virtually no cost since these pathological transactions have never been= =20 >>> used and serve no purpose=20 >>> beyond increasing the cost of validation. Bitcoin Core PR #32521=20 >>> implements this change, which i=20 >>> hope to get into the upcoming 30.0 release as well as backported to=20 >>> previous versions.=20 >>> >>> Best,=20 >>> Antoine Poinsot=20 >>> >>> [^0]: Here the full list of historical transactions that would have hit= =20 >>> the BIP54 sigops limit:=20 >>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2=20 >>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683=20 >>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179=20 >>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0=20 >>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6=20 >>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09=20 >>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e=20 >>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f=20 >>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327=20 >>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f=20 >>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc=20 >>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3=20 >>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3=20 >>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08=20 >>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363=20 >>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841=20 >>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf=20 >>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34=20 >>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e=20 >>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b=20 >>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007=20 >>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d=20 >>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e=20 >>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3=20 >>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a=20 >>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235=20 >>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629=20 >>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530=20 >>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5=20 >>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60=20 >>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57=20 >>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7=20 >>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311=20 >>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2=20 >>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f=20 >>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a=20 >>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7=20 >>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9=20 >>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f=20 >>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921=20 >>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597=20 >>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d=20 >>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8=20 >>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711=20 >>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6=20 >>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec=20 >>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda=20 >>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652=20 >>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e=20 >>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508=20 >>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261=20 >>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2=20 >>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663=20 >>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436=20 >>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7=20 >>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d=20 >>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649=20 >>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4=20 >>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1=20 >>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4=20 >>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640=20 >>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9=20 >>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404=20 >>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b=20 >>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b=20 >>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5=20 >>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd=20 >>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517=20 >>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4=20 >>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd=20 >>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04=20 >>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3=20 >>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f=20 >>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef=20 >>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e=20 >>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545=20 >>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b=20 >>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0=20 >>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276=20 >>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d=20 >>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c=20 >>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8=20 >>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641=20 >>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf=20 >>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278=20 >>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a=20 >>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521=20 >>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c=20 >>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b=20 >>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15=20 >>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797=20 >>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9=20 >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/eb191c75-e245-4c40-8288-1d1= 02477ccfdn%40googlegroups.com >> . >> >> >> --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-8482= 2ca84c23n%40googlegroups.com > . > > > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n%40googlegroups.com. ------=_Part_90821_386474536.1753293387988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot,

> Could you please clearly describe the "attack" = with a clear threat model? I don't think what you describe is an issue unde= r any
> realistic threat model, much less how it would only materia= lize with BIP54's sigop limit but not with the existing sigop limit.
<= br />Yes, for sure. So let's say you have a Coinjoin collaborated among 10 = pseudonymous peers (...they rely as much as they can on
the chain as t= he source of truth to preserve the overall pseudonymity so hardness to eval= uate "trustworthiness" of a specific peer),
where there is a single pe= er randomly designated as the coordinator. Each peer contributes an input t= owards the common transaction.

Let says the 1st participant is t= he coordinator, the 2nd to 9th participant are participants only contributi= ng 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_MU= LTISIG while being space-wise efficient.

This legacy input is of= minimal satoshi value (<=3D to inputs 1th to 9th while still > to Co= injoin protocol-defined limit),
so the cost for the malicious 10th par= ticipant is minimized. All the inputs are assembled together in the multi-p= arty transaction,
however this transaction is now policy invalid in re= ason of MAX_TX_LEGACY_SIGOPS due to the single redeem script contributed by=
the 10th input.

In the lack of awareness of the policy rul= e by the coordinator, or by any participant if the Coinkoin protocol is ful= ly distributed
among participants, identifying the source of error can= be a hard task. Unless the latest flavour of the policy rules are run, it<= br />might be just a generic policy error caught by the coordinator, or eve= n worst if the transaction is just flow with a raw TX message,
in the = lack of REJCT msgs to discover the source of non-propagation.
=C2=A0Of course there is always the option to bypass the policy rules by reac= hing out to a miner private API, though if you''re doing
a coinjoin it= is less than optimal to maximize confidentiality of the flow.

N= ote this threat model has been already considered in the past here:
th= at://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lig= htning-dev/2021-May/003033.txt

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

Currently, the problem would exis= t though only if the built Coinjoin transaction would have more than 80k si= gops. 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 i= t's
cheaper fee-wise to contribute an input to reach the ~2500 limit, = than the upper 80k limit itself.

In my view, it's not really the= responsibility of a full-node to care about that kind of issues for downst= ream softwares. However,
mentioning in release notes that the limit mi= ght affect tx collaborative construction for downstream softwares devs and = that action
might have to be taken at their appreciation (as they're t= he ones with the best know-how about their protocols) can be a courteousnote. IMHO, assuming those kinds of threat models are realistic, it woul= d be welcome to be more verbose everytime there is a
_tightening_ of t= he 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 implementer and clearly states "coun= t the number of [sigops] in
> the input scriptSig and previous outp= ut's scriptPubKey". Signature operations in these fields preceded Segwit (w= hich requires the
> scriptSig to be empty and the prevout's scriptP= ubKey to be pushonly).

Yes, I read again BIP141 around writing m= y previous email. BIP141 clearly says that "a push of a version byte, plus = a push of a
witness program. The scriptSig must be exactly empty or va= lidation 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 v= ersion byte + a push of the witness program), I don't
see how the limi= t could be understood to be applied to segwit spends, and more concerning i= mplemented 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 makin= g an explicit referral to BIP141 to define "legacy" inputs
by oppositi= on to "segwit" inputs, which have a precise technical definition. Less a BI= P 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 scrip= tsig junking transaction leveraring OP_CHECKMULTISIG:
https://github.c= om/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e#diff-a304= e75247f1546b60976116a600cacfd9d020fa4d38110b07610bb74b756547R42
It sou= nds you can generate transaction which are perfectly standard (i.e under MA= X_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 C= LI iirc.

Best,
Riard
OTS hash: 91fad050b8b9ffdc0a25f99= 7cc6f77e701e039ba4415a9a7cfe7809f1aafac71

Le mardi 15 juillet 2025 =C3=A0= 12:37:50 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
Hi Antoine,

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

Anyway, the current B= IP54 says the following nothing about legacy inputs:

=20
=20
=20
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 for= some use-cases designers,
e.g for massive Coinjoin

Any remotely sane transact= ion would run into the standardness size limit before running into t= his limit. Only a pathological transaction which tries to increase its vali= dation cost may run into this limit while being standard according to today= 's Core policy. See https://github.com/bitcoin/bips/blob/master/bip-0054.md#us= er-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 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 use Seg= wit inputs, as they would be trivially broken by txid malleability otherwis= e.
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&= #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.

--
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/8c5b5327-cdcf-4ddf-8e05-be169dbdb7a3n%40googlegroups.com.
------=_Part_90821_386474536.1753293387988-- ------=_Part_90820_1343623919.1753293387988--