From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 15 Jul 2025 04:37:58 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ubdyu-0002qi-BY for bitcoindev@gnusha.org; Tue, 15 Jul 2025 04:37:58 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e85e148288bsf6039698276.0 for ; Tue, 15 Jul 2025 04:37:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1752579470; cv=pass; d=google.com; s=arc-20240605; b=NfSEkrkm2JmRZDyANxZo17m3+CusmveN1Nt36e2M04ogAWmsrE2PFQki6lRHzZ8G91 9ajyWEsK04j3nfraWNvQZvPIDHfLb/gb2lwCw9eZ0ukzC7JBZjXzvbp0uybAoerWxuVS v6NQJCA74G2k7t/9jF6FJyGZXVJ03pMG6U2naitdvpHBgd5nu2F/n46Dbq4HCv3eU3E+ /1leGizoT1thJrfi+ItkUnJX3ovyDZ1vZFjne8IcEauVFBKsE0k2q0KVndqVz3PvC9bZ hOc8zTGvvQSdHo9QNl7zc4yrm8h3zZm8f6d2YR1LsV+zztolC5m8+dwWsSvyHvuTing9 iK7g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=; fh=6B/Wx2cBGqmbqy4P0CkkRa/hLl0uSHxUaLwVKj8nuUM=; b=cB0sX8vIETWtjtj5H4YNDslQLvEMg0WalOs8hExI3wmjMBUhlkZ/Ugmw2EEqLh6Rl7 SMGD0ovfErKerq1NtDg8WTLo8CjiVESQpkXCjTYEmU0LBHJrDVlzlHF7eLcNpFHFJweS WcK+mnkYyrYnO5iIPh14NSH8otwOIh6Js3iDDl5QBDCLV0NG7/bZjiWh/oCcfT6DCJrV I2H50ZL3wXDWPeuJUktPPYaNNGTzykcTz1+VynLfwPjII+OzMwRpEUxzFjstAkMZmSHG F8RBQKkyIfBJvX1cXKODQKLRgYlzSVDgLR/COKaf+TnoaMdPMhsnzALTtTK+gO5KyA5O kbBw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752579470; x=1753184270; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=; b=HkEHedv9ksKRO2FB9dBPo//GlyFwcmzK6XSSNnd4rAmjzYUtbjdzSe4MVfY1zl7uer b5bKFYhwlJnsUD8UEapIeI+xd4Pq3txlaSebA1c9EPyniqRv1MUNkA5qjhsfw44KWhzM P9o4bTPZdOEwbwPHcX5EWwV24OM4Vxzn7lha8TeddFs1RyzCfkBEmelhk9aLYkEuB2AV EYizUCgqHKvuvRBMz6u+n1Rq1NSxTlWJanV6K6fdRu7B+uLpEc7c87OYBBdgRC+xeC5Q Sm4M7zo5/Tt0uNrHA9kM+GyGhypttcAbIMbVdKl6WMuMcANgLunO6jOtR5DjTgQ10Eq+ 9S6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752579470; x=1753184270; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Or7MYetZgDtfnCOW6dCu7w4wUvIz8Qxl0/O72lX/rsY=; b=gBYy6Ll/hS/dgbXOFMwu2IyXuFm1zIjhpCeINEPlOpKP5UUowO3O3n93qC1t/UBu2q 4H36BLhlJoYMV4AAwXANFTjV6FwwdgyhgGG5k8mRvDv+sfkt+CW/hGe8CdELkOtm5Xn2 NzNjyzr5xuVfGc3yNd6vl27m59D36tZRms8JyL9z1YCu+HdfLacYilTV+c7pHmtZ9UCH U0XnLqpekbsaq+RaUhdzbRD5PIJAPGd72OrqgrzaRKqBNYSxpc7Vfn/vgetZ2BAnCMM7 iboAMT/3oiEz+uERpAneDYej8Djoy5XhnWi1w2FuM9HzpETepkfTMCradpCWb4iQMQbk rdtA== X-Forwarded-Encrypted: i=2; AJvYcCUU/qZtoeqph/t9GWZSKgidj+njVTpYtB/7U2ViiXc0X/oHmrzFkcCA/u5Be1V7OUqKO5pEIAJrl6Xu@gnusha.org X-Gm-Message-State: AOJu0YxNC6hSro3nsxkG6g5eNmcp97plVa607ODa3nkRXtNdVw9l0DlG Gj+T7atBR74f2JZPXc5axUCY1f26mrFkTX5TPgtzfNEhjg2e3BVWaQCn X-Google-Smtp-Source: AGHT+IFNGC0/pqfByk85TQiuVQRn6V95uT5AGNcvF9qxW2Yk6Uk2JqCj5OrlEG+z/U8OA3x3VdZNSw== X-Received: by 2002:a05:6902:2208:b0:e82:13f4:6156 with SMTP id 3f1490d57ef6-e8bb6d10a9emr3162361276.13.1752579470120; Tue, 15 Jul 2025 04:37:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZe1sJL7ZILYhX9uIRpA+TYfgZ+Ux3iCuzjXXwo138mzOQ== Received: by 2002:a25:e052:0:b0:e8b:861f:5117 with SMTP id 3f1490d57ef6-e8b861f51c4ls3672665276.0.-pod-prod-02-us; Tue, 15 Jul 2025 04:37:46 -0700 (PDT) X-Received: by 2002:a05:690c:9c0b:b0:717:c649:7849 with SMTP id 00721157ae682-71824c41569mr32328397b3.31.1752579465942; Tue, 15 Jul 2025 04:37:45 -0700 (PDT) Received: by 2002:a05:600c:1c1f:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-4561334fd09ms5e9; Mon, 14 Jul 2025 07:44:39 -0700 (PDT) X-Received: by 2002:a05:6000:2406:b0:3a4:f744:e00e with SMTP id ffacd0b85a97d-3b5f187d05cmr8855855f8f.4.1752504276951; Mon, 14 Jul 2025 07:44:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1752504276; cv=none; d=google.com; s=arc-20240605; b=kJ8+VjsxtDJ3bb1tPCaFlD6nY8Q2zr2u+ndjUdy9revC+8oJMfz6MNzeJ3qMNPmVWr 67p+bq3nh/0T9Q8LaEnTmGxAIIYQozXTcn0J+SPawC4gTzysc2HPB6F7/+RkwUOMrdwn ePs/us8SYfPeqkU2K+oNYX9X0cnqnQgPO8L2PsKNYgSJO+JxYWUe5RMSHafDSankDBUw aNn1rDyqC7BNqy/UVvj6T95o03Y6+IRRFA3U1zCprmlhMSL53Dt360cLfF8Y/TPDb+Ks NZ+kCENMkSijMEv5bsIsJ4Dp+fW5f87io80oSQbQpjhVF0UPnK21FLsx4H3Mf5Z8VcGK MPeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=Pv4vObT/XoJYjvfwTXYNDegke/0Mx5gjlK5189q0hPs=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=JMSE7GRbaUS/Qukr6Gph7yf1AnPJd4t94oqw0sPEiX8Dozjc+n8DrQWRF6455Vs7mb qywwrKinV3I38lWI3IwLs5wF8PUNFmLP73I8W+0KJ3OMVvzmrXL/IXfxBdJDTrjdRF+r azxxDlR9AT6Bc6McZ+SGT6DHjbYx4xAi3C67Az7TSBaBXCpoMVJU/sLr/1QH8a75JVNP s8AjF3TN1JF9C5sbqXPMEY9M0VicQeK54jD1i30rCbDd5jGUMcUEgYh558DQZpf1uG9d lssrkwZD8Y9qpULTJXRC1i3Rm3Nhta2erbstCeD1WcNZ4f17JpXp9zjVp7OJvShA+fk0 lJkA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-454dd26d5b4si1644195e9.0.2025.07.14.07.44.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jul 2025 07:44:36 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Mon, 14 Jul 2025 14:44:32 +0000 To: Antoine Riard 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: 01f4e102f6ffd4548f33cde3d4f6ef04d3451a22 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_5m6BPY2mbFkeLO89WuAhY5z9fogv3SBKrsyYBZFYyo" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=hsTA0efz; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot 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=_5m6BPY2mbFkeLO89WuAhY5z9fogv3SBKrsyYBZFYyo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Could you please clearly describe the "attack" with a clear threat model? I= don't think what you describe is an issue under any realistic threat model= , much less how it would only materialize with BIP54's sigop limit but not = with the existing sigop limit. > Anyway, the current BIP54 says the following nothing about legacy inputs: The BIP54 specifications are written from the perspective of an implementer= and clearly states "count the number of [sigops] in the input scriptSig an= d previous output's scriptPubKey". Signature operations in these fields pre= ceded Segwit (which requires the scriptSig to be empty and the prevout's sc= riptPubKey to be pushonly). > I think there are some implications about all of this for some use-cases = designers, > e.g for massive Coinjoin Any remotely sane transaction would run into the standardness size limit be= fore running into this limit. Only a pathological transaction which tries t= o increase its validation cost may run into this limit while being standard= according to today's Core policy. See https://github.com/bitcoin/bips/blob= /master/bip-0054.md#user-content-fn-7-21829941cd04259d86862ad3baa11d05. Best, Antoine On Saturday, July 12th, 2025 at 8:46 PM, Antoine Riard wrote: > Hi Poinsot, > > Not necessarily, if you go to multi-sign the first input of your second-s= tage txn with > SIGHASH_SINGLE | ANYONECANPAY, the hashPrevouts and the hashSequence are = not commited. > The second input can be a legacy input, even if it's altered in-flight (e= .g flipping > the S component of the ECDSA sig), it's breaking your sig hash for the se= cond input, > but not the sighash for the "contract" multi-signed input. Very practical= for doing > unilateral fee-bumping. > > It's a problem if you do multi-stage for an off-chain construction, as th= e third order > tx, even with SIGHASH_SINGLE would commit to `outpoint` field, and implic= itly the > parent txid of the malleable second input. > > ... > > Anyway, the current BIP54 says the following nothing about legacy inputs: > > "A limit is set on the number of potentially executed signature operation= s in validating > a transaction. It applies to all transactions in the block except the coi= nbase transaction. > For each input in the transaction, count the number of CHECKSIG and CHECK= MULTISIG in the > input scriptSig and previous output's scriptPubKey, including the P2SH re= deemScript". > > I do think it would be clearer to say that Segwit spends are logically ex= cluded due > to a) a Segwit spend's scriptSig must be always empty (`scriptSig.size() = !=3D 0 in > `VerifyScript()`) and b) a witness program must be a data push and as suc= h it's > never a scriptCode that can contain a CHECKSIG ops. Accounting is implici= tly always > 0 for Segwit spends. > > There is no definition of what make a spend a "legacy" input, other than = it's not > a Segwit spend. Technically, the CHECKSIG operations are committed in the= witness > program, which is itself part of the scriptPubkey... While indeed, curren= tly the code > is properly dissociating the verifcation of the legacy spends from the wi= tness program, > it's hard to say the limit is correctly implemented in the complete lack = of available code. > > The limit could be implemented in EvalScript(), but I'm not sure it's exa= ctly what > you have in mind. Thanks by advance if there is code and specification de= fining > more precisly what is understood as a legacy input under this BIP proposa= l. > > ... > > I think there are some implications about all of this for some use-cases = designers, > e.g for massive Coinjoin, if in the collaborative transaction constructio= n any party > proposes a scriptpubkey with a huge number of sigs to reach the limit, no= w if you > don't verify the script sanity against this new rule, you might have cont= ributed > an input in a transaction that is never going to be valid. Some kind of d= enial-of-service, > and the reason initially opt-in rbf was proposed to be remove. > > While this is not a concern for lightning (bc the dual funding spec expli= ctly > requests segwit input at `tx_add_input` reception), I'm not sure for any = coinjoin > or multi-party tx construction stuff that might be affected by a new DoS = vector > as soon as this starts to be a policy rule spread substantially on the ne= twork. > > It's not to say that this limit shouldn't be deployed, but in my opinion = it's > wise to advertise more towards multi-party use-cases maintainers and devs= the > potential implications of the deployment of this rule, as soon as it's po= licy. > > Best, > Riard > OTS hash: c236ba440e27f6bf89db9d21f1650d945c92fc941bb9177dbf06bbbac2afc90= 2 > > Le lundi 7 juillet 2025 =C3=A0 23:25:02 UTC+1, Antoine Poinsot a =C3=A9cr= it : > >> This limit only concerns legacy signature operations. Off-chain construc= tions use Segwit inputs, as they would be trivially broken by txid malleabi= lity otherwise. >> >> On Friday, July 4th, 2025 at 10:38 AM, Antoine Riard wrote: >> >>> Hi Poinsot, >>> >>> Thanks for the collection of historical txn hitting the proposed new li= mit. >>> >>> The only long-term downside coming immediately out of mind, if the rule= becomes consensus >>> in the future, it's the implicit limitation it would make on the multi-= party dimensions >>> of off-chain constructions. In the past, I made really rough math for 1= 000-sized participants >>> payments pools, where for the funding_tx, you have the 1000 participant= s contributing >>> one input with one sig for each [0]. >>> >>> In my understanding the new limit of 2500 signatures operation would ma= ke a hard-limit >>> for the number of participants entering in such construction, without o= ther tricks that >>> are consuming more block space. One can note the downside on funding tx= of high-order >>> off-chain construction, if a max tx size consensus limit is introduced = in the future. >>> >>> Of course, I do not deny the DoS rational of introducing the 2500 sig l= imit and it's >>> very needed. At the same time, we should be careful of not closing too = much doors for >>> future off-chain constructions and long-term tx throughput scalability. >>> >>> I do believe, it's always technically possible in the future to introdu= ce new opcode >>> or segwit versions scripts (e.g grafroot or entroot-based pool construc= tion), which >>> wouldn't be subject to the new limit, and as such more scalable. If I'm= correct, I >>> think it's all about how the limit is implemented to parse current scri= pts to be >>> spent. >>> >>> But it's hard to say without code available to review and reason. May I= kindly note >>> there is no reference implementation attached in the current BIP54 docu= ment [1]. Even, >>> if it's often updated, it's always fruitful to have code under the eyes= for review. >>> >>> This might be the kind of concern (very) far down the line...but preser= ving the >>> evolvability of the consensus rules is a good property to care about, i= n my humble >>> opinion. >>> >>> Best, >>> Riard >>> OTS hash: a2bb9a1faf79309b039d8ae7e0b951644ca0adb2 >>> >>> [0] [https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-...@mail= .gmail.com/](https://gnusha.org/pi/bitcoindev/CALZpt+E+eKKtOXd-8A6oThw-1i5c= J4h12TuG8tnWswqbfAnRdA@mail.gmail.com/) >>> [1] https://github.com/bitcoin/bips/blob/master/bip-0054.md >>> >>> Le mercredi 2 juillet 2025 =C3=A0 09:54:33 UTC+1, Antoine Poinsot a =C3= =A9crit : >>> >>>> Hi everyone, >>>> >>>> To mitigate high block validation time, BIP54 proposes to make transac= tions which require more than >>>> 2500 legacy signature operations invalid by consensus. The 2500 figure= was chosen as the tightest >>>> value that did not make any non-pathological currently standard transa= ction invalid. >>>> >>>> No transaction in Bitcoin's history would have both hit the BIP54 sigo= p limit and been standard >>>> according to today's Bitcoin Core policy[^0]. But what happened in the= past doesn't matter as much >>>> as the fact that it is possible today to create a pathological standar= d transaction that is >>>> BIP54-invalid. >>>> >>>> This opens up a major DoS vector against unupgraded miners if BIP54 ev= er gets activated in these >>>> conditions. Therefore i propose to make such transactions non-standard= and hold off activation of >>>> BIP54 until we have good reasons to believe that the vast majority of = the hashrate won't create a >>>> block containing such a transaction. >>>> >>>> Doing so gives better guarantees in case BIP54 is ever considered for = activation, and comes at >>>> virtually no cost since these pathological transactions have never bee= n used and serve no purpose >>>> beyond increasing the cost of validation. Bitcoin Core PR #32521 imple= ments this change, which i >>>> hope to get into the upcoming 30.0 release as well as backported to pr= evious versions. >>>> >>>> Best, >>>> Antoine Poinsot >>>> >>>> [^0]: Here the full list of historical transactions that would have hi= t the BIP54 sigops limit: >>>> - 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2 >>>> - bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683 >>>> - 24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179 >>>> - 53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0 >>>> - ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6 >>>> - 2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09 >>>> - 62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e >>>> - d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f >>>> - 8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327 >>>> - 02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f >>>> - b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc >>>> - c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3 >>>> - 33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3 >>>> - bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 >>>> - ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363 >>>> - ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841 >>>> - dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf >>>> - 3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34 >>>> - 8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e >>>> - ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b >>>> - 9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007 >>>> - dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d >>>> - 66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e >>>> - e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3 >>>> - 901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a >>>> - 49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235 >>>> - c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629 >>>> - 6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530 >>>> - 5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5 >>>> - f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60 >>>> - 92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57 >>>> - 1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7 >>>> - 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311 >>>> - 14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2 >>>> - bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f >>>> - a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a >>>> - fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7 >>>> - 5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9 >>>> - 7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f >>>> - d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921 >>>> - 905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597 >>>> - 5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d >>>> - cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8 >>>> - 66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711 >>>> - 9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6 >>>> - 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec >>>> - 2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda >>>> - 484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652 >>>> - e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e >>>> - b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508 >>>> - 92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261 >>>> - 22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2 >>>> - fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663 >>>> - 767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436 >>>> - 461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7 >>>> - 9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d >>>> - 6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649 >>>> - 9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4 >>>> - d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1 >>>> - e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4 >>>> - a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640 >>>> - f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9 >>>> - 856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404 >>>> - 763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b >>>> - c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b >>>> - e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5 >>>> - 02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd >>>> - 01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517 >>>> - d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4 >>>> - 6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd >>>> - 79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04 >>>> - 26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3 >>>> - bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f >>>> - 446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef >>>> - 1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e >>>> - 54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545 >>>> - b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b >>>> - 9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0 >>>> - 4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276 >>>> - e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d >>>> - 1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c >>>> - b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8 >>>> - 22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641 >>>> - 1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf >>>> - e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278 >>>> - c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a >>>> - 9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521 >>>> - 6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c >>>> - 0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b >>>> - 2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15 >>>> - d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797 >>>> - b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9 >> >>> -- >>> You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send = an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/eb191c75-e245-4c40-8288-1d102477ccfdn%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= baUD_4coLcyQ0vkoOaIzl8KFWTo3Mer27YYzDDCbffdbiJyOktRD_Y5u5OkfzSA3m9uJ84EZuEd= bybdKTDElD_8_70vbJimDgen252hVRIo%3D%40protonmail.com. --b1=_5m6BPY2mbFkeLO89WuAhY5z9fogv3SBKrsyYBZFYyo Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

<= /div>
Could you please clear= ly describe the "attack" with a clear threat model? I don't think what you = describe is an issue under any realistic threat model, much less how it wou= ld only materialize with BIP54's sigop limit but not with the existing sigo= p limit.

Anyway, the c= urrent BIP54 says the following nothing about legacy inputs:<= /div>

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

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

Any remotely sane transaction would run into the sta= ndardness size limit before running into this limit. Only a pathological tr= ansaction which tries to increase its validation cost may run into this lim= it while being standard according to today's Core policy. See 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 <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 conc= erns 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, Ant= oine 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 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.<= br> 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@googlegroups.com. To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/e27c5b87-3be2-4ed0-9000-84822ca84c23n%40googlegroups.com= .

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