From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 21 Oct 2025 12:10:36 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vBHkg-0000hb-Jk for bitcoindev@gnusha.org; Tue, 21 Oct 2025 12:10:35 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-651e9210239sf446193eaf.2 for ; Tue, 21 Oct 2025 12:10:34 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761073828; cv=pass; d=google.com; s=arc-20240605; b=jERmbsnRSiTMsJrcA7YQFxb2BK2ADN4wUTCktEp23Oyc0KwtOsUbiP9+8oI4y52vLu k/yeqj4cPsS3NXY2OTqUp48H/W84tjLWUexC5vZ4aZfjbebId2vDFBblC59aE+/B99/q h1HWiDWN1/WXV5sCdQ/QsV2FGhaCv3PYI0MudZoJ6MOokbNF/KgK8QZIroFdCaVa7f1w eILoY7VM4sk2wb67eJa6ep1K6nD1Bu3ZoBDu0alusFJCexsEMl9L9zM0MKz0O0rmzoTo 9PW4pUorlbj4UQXrESgjzqNKgtQSSNHWgJbU7RnN3vwsjlc2G7VGsz+dFvu8oaN/UEUo IVbg== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=MVfxsPhDlAoEAEO91dg24LkPYZZb169Rchfdo493vAo=; fh=ywvaHQi5a8y7N8+jOBvm4pq1vbqF+lM5IX+4cRwCjFo=; b=L5lXxL6dK1aqH3smGMWvPCJNXkmpq1lfSfsaxAh7gEbYSgdD9H++yGWUYmyHJP/ez2 gsipkIxa2kIgY4UcFjtFpT6WNmhl859UyRal0R5vRLMmrXC3vrVdMTuKBbD97CO7NUMX hJNvOcCtSKOirtUTNYYEZadmWXIi0g3xslEbgvaDFvo408bakXA3oReCPVUvh9EzOtIk HzkB/8LV+yE3OTuPMjHgbVC8FmPyRWAIKc/LQH5ZofQzA2eSqw0M3tIEOuw1cL4ECTQe wbVjtgAr4lteLMSTRimJSJEiG7YZcT5EVbcpv3eHy/9zYcvM+TJr2oMn5kd0GRJLN4aL ebaA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Bz8ZJn5Y; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761073828; x=1761678628; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=MVfxsPhDlAoEAEO91dg24LkPYZZb169Rchfdo493vAo=; b=UKIydhvKqlbTPZBv8spwPMwkfqVNLsXkfR04g0xtzh/1IQrzfcmulk+7MD6LptCWyf Z404AzExlwAFkEzTMiqw6luqiRQrrex/tieliG8BTjCwQwtaBarhF2Cz/DANltbn2140 6vSgpBVQ2VyZ5MdWJXlDEX5e0vBqt/i226wSATNecr3K9pYw2go2fLMcDMz03KhH8m6z cUQKWNTRXf2yNafZgqe8cSfSj0t1NFo3eWEC/V+mcwQ8La/MMULNYXc/S8W7avDQYfpz u5DRmefdT1PRPwQK6IqMRxgdp0P75K6imhlx+G3K6rJQkW+TzEc8b6VBW97pnM//O3YU AP4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761073828; x=1761678628; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MVfxsPhDlAoEAEO91dg24LkPYZZb169Rchfdo493vAo=; b=ZUorpR8g9digZo4kp2muhuujllOWddvtb32eT7mTwgxTFr4zeQK5H0aSlWeYz9KIDX EDwWF+HgZsb1JJKFUqSrl8GphidltM3wgQ/Sn9Rjc1HRX8BOO5gXao4JfBAvU90iBrFz ZFtsYyH5swXF+U7eHM6H8clhFXWB4m6MfWWz48jPxGcItpKSlP3G6H3jGt/ZnWNK0xeN NjaEXOackse6d7xyFXHU7DKcdPdElxUOfolZt9aRViUGjNzNcrZhKfGm182NyzIsG0ii TdSeaEjEubGClqIUOxG+zZhMYK9ek9/hbLdP3vi2hPFAbyPXekXF9atJDB0QQCuJ+Q9/ xVeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761073828; x=1761678628; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=MVfxsPhDlAoEAEO91dg24LkPYZZb169Rchfdo493vAo=; b=QrZXom0p4nr36BMvXj6BQX4+u4jd9IkA//4ZS426CqULvTOMNfdJ1mRrz1Da9OZ8Z8 RoQWqUpGNpCUCdBOPcB/WqX3t28rBTz0FTqDO3tI/KypDZOVG8Y+SLlZcyk3iVZIc65W +7mtqQ4WYCizrUs0x9GuMrv7JqV/Il+ranIDRAN2rsyiHHte8zRrJW+TPxs7FspBAPXH EuKl2HKUAcAphvI8qJMWrR0lNaMUkdgjSYniWDzFVy32BqoGY/Db/kDqhXSHn/5wv+/a VHHnc1BzRsJYdGYGXRyxi+1SGRsx0QNNkPAlNH/b9Ce/Nq4D4YnUsQE9QFFMZkAIZFtK +T/g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXZv0IgvPZroFlU65Cc1OXdweLs/ttHOhzFCnX3O/T+EkeAb+ekEwgJxSL8r629Kd/Oud9Nr3QxGK2R@gnusha.org X-Gm-Message-State: AOJu0YxMYZ93KGhErPuwe1FFRVAmIqKyWNosqg+42IsBoDyhgGfxa7Vf yAR/jEOSEB4I29mMPdvwFlzN4Mnk02R5kAR4CZtEPyfxmJarHFPv3GwI X-Google-Smtp-Source: AGHT+IEoeZ2AEu5icVnUYyAfQhOjFaL6jL2s3LrLibqBc2ol5LmbTuxCLhx7vEgJhHRA5cRR2JWI7Q== X-Received: by 2002:a05:6820:4cca:b0:650:104d:6742 with SMTP id 006d021491bc7-651c7e042a2mr7268390eaf.2.1761073828270; Tue, 21 Oct 2025 12:10:28 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4L/rjPES8NLA7M3Rppfbr3zBWliovpuLWyUIFEAFxybA==" Received: by 2002:a05:6820:c011:b0:630:38ce:5ef2 with SMTP id 006d021491bc7-651be96f62els974949eaf.1.-pod-prod-06-us; Tue, 21 Oct 2025 12:10:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXMoV+ZB0djNfeyTuKYD9t/LOepeFiOmidGY9jL4Jy78j4866XS1o2Wddkcq4mvOkYQcHpkXOImEYp+@googlegroups.com X-Received: by 2002:a05:6808:4fe7:b0:43d:23b9:9ef5 with SMTP id 5614622812f47-443a2f2dddfmr8483632b6e.26.1761073823780; Tue, 21 Oct 2025 12:10:23 -0700 (PDT) Received: by 2002:a50:d695:0:b0:63c:4f44:7f1a with SMTP id 4fb4d7f45d1cf-63e17f2ce7dmsa12; Tue, 21 Oct 2025 12:06:10 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXz5YJk+jbYwbzbZWU6jClu08wF6vMgoBeowy66Z5aCpZvqJeijegRiTrdIfd4izsygl512EU0pLFpK@googlegroups.com X-Received: by 2002:a17:907:3ea3:b0:b3c:f48:ed57 with SMTP id a640c23a62f3a-b647443b9f8mr2055789366b.35.1761073568003; Tue, 21 Oct 2025 12:06:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761073567; cv=none; d=google.com; s=arc-20240605; b=kOOJn4BRA19LV1iiJPB+jBvBHxc42khEmx0UjE+UhMFQPGTcJ3AN83nfmA1l62g21I 8yL02zFM5w1avLtPyFHKZHpTvlQwXCfiG0ao+/yDnJBTPYn1RczyRcQngMIL5vm64Bf+ bnvBnQhEftPTw1mYGbTKEhnG/D5fM684vYhWTlniV5dZCaw7v+1r6n5nEcqiahtLJPvj +RaHnMKOoZUfABf9yEISum0ekMa2tX350g48gMgv+uDgtaU1cQUEh5wjxf1oCQDRczmH N5nbK8yPaVBc9Doo1QwtYYf/1iv48z9YqD56lhVTzmxxhWExSqDqQ/hVb/vPmmOaSiZT Mr5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=iTkXO+vjLNWPutiTdtKzZRXlw5MtuEu9MRU2HU5Zz/I=; fh=M9AzYdkKJ6Sirudg7wTyWp559fwwW/UAHi7/8fpceho=; b=DH1bS+MASS8sglTImMu0WV9X6MsG6BxvbKhYu9j3cECoRUXCpL9L0n91twEGSIvHzk q/cpou3MaRe2qc0SEUYN3jxYObqlJzFopGFkl7V7AzBuFRZbHsxVKK2gsUpPmAlETE1c h6xKsgIhiD+4tc4KY6oc4KMyucJkCxOY54Qgmsy0+HYv2pMQw89q9TMAKhCL/4PKFDzQ Dv2wxHMPCvytoEufI+y+72j+B8c8V0k52NHPpAHNjLsBzY2F+pPgq6H7KHR++irfVCvU uOMhEii3p8HZvIw94xKbv5YQsJmlarpm9ywr+yTSNm0OGBxzvRAON80CkuB0MyKiINK+ KF1w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Bz8ZJn5Y; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com. [2a00:1450:4864:20::52d]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b65e9e7d2b0si42998866b.3.2025.10.21.12.06.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Oct 2025 12:06:07 -0700 (PDT) Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) client-ip=2a00:1450:4864:20::52d; Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-63e0cec110eso1199371a12.2 for ; Tue, 21 Oct 2025 12:06:07 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCW+B56KZ+y6SqudV9OexIuiJ2j/Bqhq/kO9NsZqxQdSTZh1ru5oONxOj3BuKZbSXluOQ5nWmhBV8du/@googlegroups.com X-Gm-Gg: ASbGncuX9QBCm8qwGPrYTTMWD3CkahsXZTRZ4oe2Ild8raBTPAwpShoEblOFkDZSAoa CTz3lkZIuEqvHKBoqsmGrf0C7B9hU+22WxBNImUmjT7LnKvy2XUStb5kXAMizLWYQxBrcvFgmUs XPKkarX+Y0gWwQOZ3ebY3WrogEj0cfpLcM9sxZ3lc7PcN67LEUsn/3pb1bak7vxIXFb8lRbKXXL /f0vjr0pql2bu89YbJc5bcLEZnr53fg1pMNUi7kriSMtjzFWFFeFci093Kp1ngZlS15jhY= X-Received: by 2002:a05:6402:42c8:b0:63c:b2:c63b with SMTP id 4fb4d7f45d1cf-63c1f631c0dmr19486850a12.6.1761073567203; Tue, 21 Oct 2025 12:06:07 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> In-Reply-To: From: Garlo Nicon Date: Tue, 21 Oct 2025 21:05:55 +0200 X-Gm-Features: AS18NWD6j5Ip88xseyb1PAvp92i-PKdyk6GEU0wy01Xuu8oUAdwNn1hJ330472E Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Greg Maxwell Cc: Antoine Poinsot , Brandon Black , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000065849e0641afe4ef" X-Original-Sender: garlonicon@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Bz8ZJn5Y; spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000065849e0641afe4ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > bare multisigs can easily violate the proposed limit Good point. I can imagine a Script, which could allow something like 1-of-460 multisig: if all public keys would be hashed, then it would take 21 bytes to push any given hash. And then, pushing 460 hashes would take 460*21=3D9660 bytes. Then, to clean it up, OP_2DROP would consume two elements, so that means 230 bytes, to clean it up with OP_2DROPs, and a single OP_DROP. I think it could be something like that: OP_TOALTSTACK <9660 bytes> OP_FROMALTSTACK OP_PICK OP_TOALTSTACK OP_DROP OP_DUP OP_HASH160 OP_FROMALTSTACK OP_EQUALVERIFY OP_CHECKSIG And then, this is how it could be executed: //input stack //toaltstack //pushing hashes //pushing number //picking hash //toaltstack //dropping the rest //dup //hash160 //fromaltstack //equalverify OP_TRUE //checksig Which means, that it would take 9660 bytes, plus 230 bytes of dropping, so it sums up to 9890 bytes. Then, 9 bytes are consumed by the rest of the envelope, and that leaves 101 bytes for signature and public key. Seems doable. But I didn't check it in regtest yet. pon., 20 pa=C5=BA 2025 o 18:48 Greg Maxwell napisa=C5= =82(a): > Perhaps it's also worth explicitly pointing out for people following at > home how this proposal has a very real confiscation risk: bare > multisigs can easily violate the proposed limit-- if uncompressed points > are used an "of 8" policy is sufficient, otherwise I think 16 is needed b= ut > both are within the limit of 20 in checkmultisig. This is much worse tha= n > other confiscation concerns that have gummed up most (all?) other cleanup > proposals, because rather than requiring some very contrived thing that > probably no one would have ever done except as lols bare multisigs is a > thing that has actually seen real use and could have been created by > someone doing something completely boring... doubly so because the > inadvertent P2SH script size limit may have explicitly pushed people into > using bare CMS for a large policy when otherwise bare CMS is at least a > little weird. > > Aside, some of the confiscatory concerns could be greatly mitigated in > proposals along these lines could be greatly mitigated if the rule was on= ly > applied to transactions which either have no post-activation active > nLocktime or have at least one input with a post activation height. Such= a > move could also be done incrementally, limiting it for new coins and then > after giving a longer period to unearth any confiscation risk applying it > more generally if none arises. It still wouldn't completely eliminate a > confiscation risk as there could be an unconfirmed *chain* of transaction= s, > but perhaps a more limited rule would be easier to argue had an > insignificant risk. Similarly, other such carveouts could be made for mo= re > likely script forms. > > One even more conservative possibility would be to trace the "maximum > reorg height" (MRH) of every output, which would be the height of the > highest coinbase transaction in its casual history. If a transaction has > any input with a MRH which is post-activation then it couldn't be part of > an unconfirmed chain that predated the rule activation. The biggest > downside is that implementations don't currently track this metric in the= ir > utxo set and doing so would add a few bytes to each utxo entry and a > complete resync/reindex in order to enforce the rule. I believe this wou= ld > essentially eliminate the confiscation risk. > > I'd generally say I still think the proposal has little value relative to > the inherent costs of any consensus rule change and potentially has an > unacceptable confiscation risk-- MRH tracking might make that acceptable, > but comes at a high cost which I think would clearly not be justified. > OTOH, MRH tracking might also be attractive for other cleanup proposals > having the similar confiscation risk issues and if so then its cost may b= e > worthwhile. > > I say it has little value because while keeping crap out of the UTXO set > has extremely high value, anyone who wants to stuff crap in will just use > multiple crappy outputs instead which is even worse than using a single b= ig > one especially given that >10k is already unspendable, prunable, and > already pruned by implementations. Worse because each distinct output ha= s > overheads and because even non-op-return becomes prunable if its over 10k > now, while a dozen 520 byte outputs wouldn't be prunable under this > proposal. So, paradoxically this limit might increase the amount of > non-prunable data. A variant that just made >520 unspendable would be > better in this respect, but I doubt it would at all satisfy the proponent= s' > motivations. Likewise, one that expanded the threshold to more like 1350 > would at least avoid the bare CMS concerns but also would probably not > satisfy the proposals proponents. > > > > On Fri, Oct 17, 2025 at 6:45=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev= elopment > Mailing List wrote: > >> Hi, >> >> This approach was discussed last year when evaluating the best way to >> mitigate DoS blocks in terms >> of gains compared to confiscatory surface. Limiting the size of created >> scriptPubKeys is not a >> sufficient mitigation on its own, and has a non-trivial confiscatory >> surface. >> >> One of the goal of BIP54 is to address objections to Matt's earlier >> proposal, notably the (in my >> opinion reasonable) confiscation concerns voiced by Russell O'Connor. >> Limiting the size of >> scriptPubKeys would in this regard be moving in the opposite direction. >> >> Various approaches of limiting the size of spent scriptPubKeys were >> discussed, in forms that would >> mitigate the confiscatory surface, to adopt in addition to (what >> eventually became) the BIP54 sigops >> limit. However i decided against including this additional measure in >> BIP54 because: >> - of the inherent complexity of the discussed schemes, which would make >> it hard to reason about >> constructing transactions spending legacy inputs, and equally hard to >> evaluate the reduction of >> the confiscatory surface; >> - more importantly, there is steep diminishing returns to piling on more >> mitigations. The BIP54 >> limit on its own prevents an externally-motivated attacker from >> *unevenly* stalling the network >> for dozens of minutes, and a revenue-maximizing miner from regularly >> stalling its competitions >> for dozens of seconds, at a minimized cost in confiscatory surface. >> Additional mitigations reduce >> the worst case validation time by a smaller factor at a higher cost in >> terms of confiscatory >> surface. It "feels right" to further reduce those numbers, but it's >> less clear what the tangible >> gains would be. >> >> Furthermore, it's always possible to get the biggest bang for our buck i= n >> a first step and going the >> extra mile in a later, more controversial, soft fork. I previously >> floated the idea of a "cleanup >> v2" in private discussions, and i think besides a reduction of the >> maximum scriptPubKey size it >> should feature a consensus-enforced maximum transaction size for the >> reasons stated here: >> >> https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1= 732/8. >> I wouldn't hold my >> breath on such a "cleanup v2", but it may be useful to have it documente= d >> somewhere. >> >> I'm trying to not go into much details regarding which mitigations were >> considered in designing >> BIP54, because they are tightly related to the design of various DoS >> blocks. But i'm always happy to >> rehash the decisions made there and (re-)consider alternative approaches >> on the semi-private Delving >> thread [0] dedicated to this purpose. Feel free to ping me to get access >> if i know you. >> >> Best, >> Antoine Poinsot >> >> [0]: https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/71= 1 >> >> >> >> >> On Friday, October 17th, 2025 at 1:12 PM, Brandon Black < >> freedom@reardencode.com> wrote: >> >> > >> > >> > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote: >> > >> > > But also given that there are essentially no violations and no reaso= n >> to >> > > expect any I'm not sure the proposal is worth time relative to fixes >> of >> > > actual moderately serious DOS attack issues. >> > >> > >> > I believe this limit would also stop most (all?) of PortlandHODL's >> > DoSblocks without having to make some of the other changes in GCC. I >> > think it's worthwhile to compare this approach to those proposed by >> > Antoine in solving these DoS vectors. >> > >> > Best, >> > >> > --Brandon >> > >> > -- >> > 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/bitcoindev/aPJ3w6bEoaye3WJ6%40console. >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/OAoV-Uev9IosyhtUCyeIhclsVq-= xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwr= KjChc%3D%40protonmail.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/bitcoindev/CAAS2fgQEdVVcb%3DDfP7XoRxfXf= q1unKBD0joffddOuTsn2Zmcng%40mail.gmail.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/= CAN7kyNi2xxEY1LZTb_WMXKtFiDf8Epi3VN7HLhsNimOAEMH1xg%40mail.gmail.com. --00000000000065849e0641afe4ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> bare multisigs can easily violate the proposed limit<= br>
Good point. I can imagine a Script, which could allow something like= 1-of-460 multisig: if all public keys would be hashed, then it would take = 21 bytes to push any given hash. And then, pushing 460 hashes would take 46= 0*21=3D9660 bytes. Then, to clean it up, OP_2DROP would consume two element= s, so that means 230 bytes, to clean it up with OP_2DROPs, and a single OP_= DROP.

I think it could be something like that:

OP_TOALTSTACK <9660 bytes> OP_FROMALTSTACK OP= _PICK OP_TOALTSTACK
<OP_2DROP*229> OP_DROP
OP_DUP OP_HASH160 OP= _FROMALTSTACK OP_EQUALVERIFY OP_CHECKSIG

And then, this is ho= w it could be executed:

<si= g> <pubkey> <number> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//input stack
<sig> <pubkey> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 //toaltstack
<sig> <pubkey> <lot= s_of_hashes> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//pushing hashes<sig> <pubkey> <lots_of_hashes> <number> =C2=A0 /= /pushing number
<sig> <pubkey> <lots_of_hashes> <ha= sh> =C2=A0 =C2=A0 //picking hash
<sig> <pubkey> <lots_= of_hashes> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//toaltstack
<= sig> <pubkey> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //dropping the rest
<si= g> <pubkey> <pubkey> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//dup
<sig> <pubkey> <hash= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0//hash160
<sig> <pubkey> <hash> <hash> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //fromaltstack
<sig>= <pubkey> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //equalverify
OP_TRUE =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//checksig

Which mea= ns, that it would take 9660 bytes, plus 230 bytes of dropping, so it sums u= p to 9890 bytes. Then, 9 bytes are consumed by the rest of the envelope, an= d that leaves 101 bytes for signature and public key. Seems doable. But I d= idn't check it in regtest yet.

pon., 20 pa=C5=BA 2= 025 o 18:48=C2=A0Greg Maxwell <gma= xwell@gmail.com> napisa=C5=82(a):
Perhaps it's also worth = explicitly=C2=A0pointing out for people following at home how this proposal= =C2=A0has a very real confiscation risk:=C2=A0 bare multisigs=C2=A0can easi= ly=C2=A0violate the proposed limit-- if uncompressed points are used an &qu= ot;of 8" policy is sufficient, otherwise I think 16 is needed but both= are within the limit of 20 in checkmultisig.=C2=A0 This is much worse than= other confiscation=C2=A0concerns that have gummed up most (all?) other cle= anup proposals, because rather than requiring some very contrived thing tha= t probably no one would have ever done except as lols bare multisigs is a t= hing that has actually seen real use and could have been created by someone= doing something completely boring... doubly so because the inadvertent=C2= =A0P2SH script size limit may have explicitly pushed people into using bare= CMS for a large policy when otherwise bare CMS is at least a little weird.=

Aside, some of the confiscatory concerns could be= greatly mitigated in proposals along these lines could be greatly mitigate= d if the rule was only applied to transactions which either have no post-ac= tivation active nLocktime or have at least one input with a post activation= height.=C2=A0 Such a move could also be done incrementally, limiting it fo= r new coins and then after giving a longer period to unearth any confiscati= on=C2=A0risk applying it more generally if none arises.=C2=A0 It still woul= dn't completely eliminate a confiscation risk as there could be an unco= nfirmed *chain* of transactions, but perhaps a more limited rule would be e= asier to argue had an insignificant risk.=C2=A0 Similarly, other such carve= outs could be made for more likely script forms.=C2=A0=C2=A0

=
One even more conservative possibility would be to trace the &qu= ot;maximum reorg height" (MRH) of every output,=C2=A0 which would be t= he height of the highest coinbase transaction in its casual history.=C2=A0 = If a transaction has any input with a MRH which is post-activation then it = couldn't be part of an unconfirmed chain that predated the rule activat= ion.=C2=A0 The biggest downside is that implementations don't currently= track this metric in their utxo set and doing so would add a few bytes to = each utxo entry and a complete resync/reindex in order to enforce the rule.= =C2=A0 I believe this would essentially eliminate the confiscation risk.

I'd generally say I still think the proposal has= little value relative to the inherent costs of any consensus rule change a= nd potentially has an unacceptable confiscation risk-- MRH tracking might m= ake that acceptable, but comes at a high cost which I think would clearly n= ot be justified.=C2=A0 OTOH, MRH tracking might also be attractive for othe= r cleanup proposals having the similar confiscation risk issues and if so t= hen its cost may be worthwhile.

I say it has littl= e value because while keeping crap out of the UTXO set has extremely high v= alue, anyone who wants to stuff crap in will just use multiple crappy outpu= ts instead which is even worse than using a single big one especially given= that >10k is already unspendable, prunable, and already pruned by imple= mentations.=C2=A0 Worse because each distinct output has overheads and beca= use even non-op-return becomes prunable if its over 10k now, while a dozen = 520 byte outputs wouldn't be prunable under this proposal. So, paradoxi= cally this limit might increase the amount of non-prunable data.=C2=A0 A va= riant that just made >520 unspendable would be better in this respect, b= ut I doubt it would at all satisfy the proponents' motivations. Likewis= e, one that expanded the threshold to more like 1350 would at least avoid t= he bare CMS concerns but also would probably not satisfy the proposals prop= onents.



On Fri, Oct 17, 2025 at 6:45=E2= =80=AFPM 'Antoine Poinsot' via Bitcoin Development Mailing List <= ;bitcoinde= v@googlegroups.com> wrote:
Hi,

This approach was discussed last year when evaluating the best way to mitig= ate DoS blocks in terms
of gains compared to confiscatory surface. Limiting the size of created scr= iptPubKeys is not a
sufficient mitigation on its own, and has a non-trivial confiscatory surfac= e.

One of the goal of BIP54 is to address objections to Matt's earlier pro= posal, notably the (in my
opinion reasonable) confiscation concerns voiced by Russell O'Connor. L= imiting the size of
scriptPubKeys would in this regard be moving in the opposite direction.

Various approaches of limiting the size of spent scriptPubKeys were discuss= ed, in forms that would
mitigate the confiscatory surface, to adopt in addition to (what eventually= became) the BIP54 sigops
limit. However i decided against including this additional measure in BIP54= because:
- of the inherent complexity of the discussed schemes, which would make it = hard to reason about
=C2=A0 constructing transactions spending legacy inputs, and equally hard t= o evaluate the reduction of
=C2=A0 the confiscatory surface;
- more importantly, there is steep diminishing returns to piling on more mi= tigations. The BIP54
=C2=A0 limit on its own prevents an externally-motivated attacker from *une= venly* stalling the network
=C2=A0 for dozens of minutes, and a revenue-maximizing miner from regularly= stalling its competitions
=C2=A0 for dozens of seconds, at a minimized cost in confiscatory surface. = Additional mitigations reduce
=C2=A0 the worst case validation time by a smaller factor at a higher cost = in terms of confiscatory
=C2=A0 surface. It "feels right" to further reduce those numbers,= but it's less clear what the tangible
=C2=A0 gains would be.

Furthermore, it's always possible to get the biggest bang for our buck = in a first step and going the
extra mile in a later, more controversial, soft fork. I previously floated = the idea of a "cleanup
v2" in private discussions, and i think besides a reduction of the max= imum scriptPubKey size it
should feature a consensus-enforced maximum transaction size for the reason= s stated here:
https://delvingbitcoin.= org/t/non-confiscatory-transaction-weight-limit/1732/8. I wouldn't = hold my
breath on such a "cleanup v2", but it may be useful to have it do= cumented somewhere.

I'm trying to not go into much details regarding which mitigations were= considered in designing
BIP54, because they are tightly related to the design of various DoS blocks= . But i'm always happy to
rehash the decisions made there and (re-)consider alternative approaches on= the semi-private Delving
thread [0] dedicated to this purpose. Feel free to ping me to get access if= i know you.

Best,
Antoine Poinsot

[0]: https://delvingbitcoin.org/= t/worst-block-validation-time-inquiry/711




On Friday, October 17th, 2025 at 1:12 PM, Brandon Black <freedom@reardencode.com&g= t; wrote:

>
>
> On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
>
> > But also given that there are essentially no violations and no re= ason to
> > expect any I'm not sure the proposal is worth time relative t= o fixes of
> > actual moderately serious DOS attack issues.
>
>
> I believe this limit would also stop most (all?) of PortlandHODL's=
> DoSblocks without having to make some of the other changes in GCC. I > think it's worthwhile to compare this approach to those proposed b= y
> Antoine in solving these DoS vectors.
>
> Best,
>
> --Brandon
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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/bitcoindev/aPJ3w6bEoaye3WJ6%40conso= le.

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/OAo= V-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4W= pGHLI_iMdvPr5B0gM0nDvlwrKjChc%3D%40protonmail.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CAAS2fgQEdVVcb%3DDfP7XoRxfXfq1unKBD0= joffddOuTsn2Zmcng%40mail.gmail.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/ms= gid/bitcoindev/CAN7kyNi2xxEY1LZTb_WMXKtFiDf8Epi3VN7HLhsNimOAEMH1xg%40mail.g= mail.com.
--00000000000065849e0641afe4ef--