From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Oct 2025 09:48:26 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vAt3Z-0000KH-GN for bitcoindev@gnusha.org; Mon, 20 Oct 2025 09:48:26 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3c9bfdade9csf3300067fac.0 for ; Mon, 20 Oct 2025 09:48:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1760978898; cv=pass; d=google.com; s=arc-20240605; b=ehlL2a4FHKZn9ARkDgONo4k7sXuoYfFFuVR/8hOJH/K8jCNoPt7fJNsrJxF73U1ivx 2ga/6YraH9RqsFK2x6c5XreVAFghflj4C9DPynogf1Qhdqq4Tq1myt2GfhTiVL8XncXx WuOfVx5IZvBiArBMQUeqOjMS2VQYgJG6vf/B8M1CTc43J/fwYNZE6wuusAWKNkUAFEGd y1/EQ/61CS6HZ8SfCOzC+XiLFKRy2jGVQkcoW7m05AKGs8y0MkajCuBs3S718PzBm4BS qRkqQTb4qtCYF3uLqKg1Lp1QhRgtAcXgho6D85oZdpgfOj9VsbgguJ7hI3nZPh688c8n tqXw== 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=JeegyygrxC8tENjuE4KS7iqSeFnCEpFtHcQZ8Lg3OMs=; fh=pqaDYwIjzQPMXK2Y09P1Tkssu0OQeCyqxtRvPf4bItg=; b=Ar1gQFrIj37kZhl6NMOczLrHtSzmFMOj9OO7reJHgfAgSvWnh1rfLyP7M6IOozNlHa oxAKScF3To7Py11q4Qx5nKUWAWh0ewK6kq1QU7EiJHZq6fGrNmY51Na3Zm93/n0FMqYz V3Le7McgutoIH8V9aeedo2MLfGtqiVBniZxyeQvznhbmgc7ukvLcv70vOv6LaNT0I5+A JXt3oHFrZ5H8ia1fnHQyhk9TiFYe1AT/WgnyYDrcAQ31SNV/wS59EUi25mbwTMWsq8Xq M4N1BMKKoKiJl9IFokQXMZnKX1fnSOgr6ogz4uM0XDSt0EVum5TbcGv4swjp+IutHwIB aGPw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MaFq6cbi; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=gmaxwell@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=1760978898; x=1761583698; 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=JeegyygrxC8tENjuE4KS7iqSeFnCEpFtHcQZ8Lg3OMs=; b=Ky9sCSVNTfDRuuKxMO+1UGnyidY568YRff8A7zmplIJAhIXFyIQxHFaC7gsUt5k0bA iq7mrftL1JatXd4FEB3hmo8YGUNEBX1Oa6C9IUnAWLL+Mt2PlUwR8GKpA2DBLZK8iV/L MKprsiV4Rb3ZIJXxy0jjF8N+gVem/01pe25hmvLd2dzJPk6dyWZTnXtyp+N3fw+O9Wpf ZuMBVcIlg6cYKtfusataM0yNOMQEO7qC29U1KExTYbAWyUMNNc0Mz6YE0CsXvVKAl1vl L5lgSFYciSREW4flsWRHTThvUYhV0MeyQh38uEZ1p67cuDrh2qxbjMUIJ6FSL7xJlqzw cxUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760978898; x=1761583698; 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=JeegyygrxC8tENjuE4KS7iqSeFnCEpFtHcQZ8Lg3OMs=; b=QUq96Q5XcAVrxhmIoAGGK2Oe+BxalSxZ+zDq+QQ4+rzJgyj4zHSIts+n7iBYTWpZ8C fV8ioWnPl5OY6iuNBs0dyc4f2TTit1SwDSio91E12OjLxeeJMyaVwb1wImjNGr/KDij5 7opjtxWKUflUyoOURHO7NX7Zi3clpsDDxsqNgj2+hyxF4kzFkrOa8UJplPacF1YM8Nv5 F+K7islmh7tUI+hhvf+hb6scgSxmPRv7shtSXYMHI+OWc2skYPPgovEhCiX1c3tlxye9 mGeVWXzNC64gnmhKqwtDu6CZNf4Vm0HqAT3BXGTzghlV/xH/OdgAVtxvTEhpE9vw9MCR CuyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760978898; x=1761583698; 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=JeegyygrxC8tENjuE4KS7iqSeFnCEpFtHcQZ8Lg3OMs=; b=fEiu1Ex3xg5r7xdxG4W30g8fp/j/Y5oyShsRatC7XzB3oi2cWirgcq24YzTNT3wNZ1 j+xOBYYHRGyuEdFsphfEW/OKWOMbx31LFKS5GiwIlII7qTU8+kj2lRkP+dj8/CvTt+yI tIGCbguwthi6ODMuQRHtLJ3ZjIawhzT7RLzwg7PlOWL/ke+azxM23vR3SpGUWufqmWY1 i9EBX5vVenmrlpymA133o6d1c+zGDWo2WU8xovl+CHap5LiHmKwLmlOZ6PS5VFhKs+ht EKTxaP41m0sVt0f4YkZCCibh5pqsdyUDoNSNOppfJrUaifasBlLloQaOhkd/HGqrv9re Uv7Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVlh5BVyQUkxr3etu/whkmUuDHMxCEYyd2yk+ctZ0ruP7dRyyLO57nWQcWrbUJ6pp3s2av5GaL6W3fU@gnusha.org X-Gm-Message-State: AOJu0YyJmU2ni4RKXel0g9x4MKhsZWKYAWAMckQ7I82AUjpVpBC4u2ZX 2Wb2qaklHsDvhZuYZFNihgxUlceCDOuJPdPcNziq0G57SzgtrAyMtkeo X-Google-Smtp-Source: AGHT+IF7COndBDL90yM0wnK2gpbYyYu/hA2IL/e+8EAJqnCOdGm+P1gOUhOv0lw6a29drKGLIe7iiA== X-Received: by 2002:a05:6871:2ea3:b0:33d:c5bc:1a05 with SMTP id 586e51a60fabf-3c96886210cmr7471308fac.10.1760978897973; Mon, 20 Oct 2025 09:48:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7IAA3z7aLNYFt1bj2cMvu7+sBfKx99D7jfEinRTtiDRg==" Received: by 2002:a05:6871:a511:b0:35d:3a1c:4779 with SMTP id 586e51a60fabf-3c97528a0d7ls1151138fac.2.-pod-prod-00-us; Mon, 20 Oct 2025 09:48:12 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCW0YsJUzUXUoIyDLdzr7XfT0sUgArFBE2wwWc9T4/y/DDtagKl94cr5tTXYydt92nqtUPEJqN3cMF6l@googlegroups.com X-Received: by 2002:a05:6808:6f8c:b0:443:abbd:c18a with SMTP id 5614622812f47-443abbe0b21mr4698804b6e.9.1760978892358; Mon, 20 Oct 2025 09:48:12 -0700 (PDT) Received: by 2002:a0d:c203:0:b0:74f:1486:e2a9 with SMTP id 00721157ae682-78372c930fams7b3; Mon, 20 Oct 2025 08:22:46 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXXXNHQ0MzPYUuLC9E/qG86cvLW0KFticfQ1YpSEQDyOGa16HKho5mlFReEUtZSE3+texHzK4byzjwe@googlegroups.com X-Received: by 2002:a05:690c:9a82:b0:783:7768:55e6 with SMTP id 00721157ae682-7837768866amr107087187b3.13.1760973765773; Mon, 20 Oct 2025 08:22:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1760973765; cv=none; d=google.com; s=arc-20240605; b=g2Njt7B7BE7dVrjlVprCIxlqVbCArMH59u+FuJRjpVWbKg+fyl589PxwxXZayelUGf g7RaIjU3cdkC4cPP1sgBGW/dXSyR4sSBq4hU8tYU4jPEuwblzmC49AC3IFH2nD77OMlt ONabZjaQeChdCpgd2/ygbY32bPo89kxroPfdaDGnVm/0VAJ1avA2UWhAmdfApRGTEeLg wTMcLJq9syCfT9LOTXVjxEQTTKzA0DRgvLQwBue2G/pk+3wOxXgQQCgeZwiwqYgyOrQv 5tR5pYjuBi1aFd9kX6PPp4R3PNz9i5hxZJu94F259jgTmxDv+mg60ZOofzUxp6vG8Cja qGew== 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=mpk3iRDz6VoL68GwwpUI4m4gnIPISbYcYVQPnNY9B4Y=; fh=Tpbbl4MJA8RfDG3jVgasjFlsaN4bdUpJUCKtUUwd5k8=; b=Kh8pIz7grVR3mWUKnj5rCjqpDsiEnfNzTJN+M7JWc9lmVfOXvjhfpGi4/BuTcBHAti YcWeTWsn2d7XfcuUqW0fWiaSCPP3xHL34eUHTjpbVTHat6WzBNSxFh6SYfyi1OgRnVU0 VK/jI/MdMHosf3wQTzQ0sL9giQKxHj/KuFpNkDQ3Rfiqkf/Z8v7gnTuYrqP+CeCOy8BO Zg68vUaHTxLziS8NrskrqUQKidbQKCtfseS84U7wMKZKG8oYRQMAo/wVgXiKJkKC3E/i vo/KqhTk5S87u6VB2hS/oOcV8tHlgJA/J/SyrVH2pmZo5ALm6h4PnV/mKGrrZ6Fu1JYN cQ0Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MaFq6cbi; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com. [2607:f8b0:4864:20::533]) by gmr-mx.google.com with ESMTPS id 00721157ae682-784af288a16si240307b3.4.2025.10.20.08.22.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Oct 2025 08:22:45 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) client-ip=2607:f8b0:4864:20::533; Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-b63148d25c3so2757372a12.1 for ; Mon, 20 Oct 2025 08:22:45 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVs/ySIky4H3GCfQNgCjuPg4Q6hc4NcsIJRHklCrXJDuLWVgVVBRhexdjBCEI5SJelsajy4PtxxKJ40@googlegroups.com X-Gm-Gg: ASbGncsclNDxdCyDVAXl/+e5EPoHNq5Qge85/BP1U8idU5OWaGrfaDIXw7l954iexDr 1l4ClrJpz/FIuizJHye6wf6T/7OUlJLEJ3z/NMlKNjfDGcLyDgqVaPhWOzkaS0n9YYXc0ZchLtf Ckrxw20RSiLO1hGDaKhfryc0DIpHGmhDQF35pEh5qz1b6VHgpH9Cu7GoI1OWByKhywT32EMXVF6 b5DZI4ugSmFbgoIaycrDx6CjCkn906LAR46kP624+R/yX+UeMWnTo56uCasXVfFHies8A8= X-Received: by 2002:a17:903:22d2:b0:288:5ce8:ea74 with SMTP id d9443c01a7336-290c66da7e2mr195450535ad.3.1760973764735; Mon, 20 Oct 2025 08:22:44 -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: Greg Maxwell Date: Mon, 20 Oct 2025 15:22:32 +0000 X-Gm-Features: AS18NWB5FR6OcSMjkfWkChw897gvTKPVGNQmZlTd4TY-HKGjVCstsnONQNTERjg Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Antoine Poinsot Cc: Brandon Black , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b4b8c8064198a7ab" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MaFq6cbi; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000b4b8c8064198a7ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 but both are within the limit of 20 in checkmultisig. This is much worse than 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 only 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 transactions, but perhaps a more limited rule would be easier to argue had an insignificant risk. Similarly, other such carveouts could be made for more 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 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. 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 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 be 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 big one especially given that >10k is already unspendable, prunable, and already pruned by implementations. Worse because each distinct output has 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 proponents' 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 Devel= opment 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 i= t > 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 les= s > clear what the tangible > 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 floate= d > the idea of a "cleanup > v2" in private discussions, and i think besides a reduction of the maximu= m > 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/17= 32/8. > I wouldn't hold my > breath on such a "cleanup v2", but it may be useful to have it documented > 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> 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 reason > 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 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/OAoV-Uev9IosyhtUCyeIhclsVq-x= UBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrK= jChc%3D%40protonmail.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/= CAAS2fgQEdVVcb%3DDfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng%40mail.gmail.com. --000000000000b4b8c8064198a7ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps it's also worth explicitly=C2=A0pointing = out for people following at home how this proposal=C2=A0has a very real con= fiscation risk:=C2=A0 bare multisigs=C2=A0can easily=C2=A0violate the propo= sed limit-- if uncompressed points are used an "of 8" policy is s= ufficient, 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=A0= concerns that have gummed up most (all?) other cleanup proposals, because r= ather than requiring some very contrived thing that probably no one would h= ave ever done except as lols bare multisigs is a thing that has actually se= en real use and could have been created by someone doing something complete= ly boring... doubly so because the inadvertent=C2=A0P2SH script size limit = may have explicitly pushed people into using bare CMS for a large policy wh= en otherwise bare CMS is at least a little weird.

= Aside, some of the confiscatory concerns could be greatly mitigated in prop= osals along these lines could be greatly mitigated if the rule was only app= lied to transactions which either have no post-activation 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 for new coins and then after= giving a longer period to unearth any confiscation=C2=A0risk applying it m= ore generally if none arises.=C2=A0 It still wouldn't completely elimin= ate a confiscation risk as there could be an unconfirmed *chain* of transac= tions, but perhaps a more limited rule would be easier to argue had an insi= gnificant risk.=C2=A0 Similarly, other such carveouts could be made for mor= e likely script forms.=C2=A0=C2=A0

One even more c= onservative possibility would be to trace the "maximum reorg height&qu= ot; (MRH) of every output,=C2=A0 which would be the height of the highest c= oinbase transaction in its casual history.=C2=A0 If a transaction has any i= nput with a MRH which is post-activation then it couldn't be part of an= unconfirmed chain that predated the rule activation.=C2=A0 The biggest dow= nside is that implementations don't currently track this metric in thei= r utxo set and doing so would add a few bytes to each utxo entry and a comp= lete resync/reindex in order to enforce the rule.=C2=A0 I believe this woul= d essentially eliminate the confiscation risk.

I&#= 39;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 unac= ceptable confiscation risk-- MRH tracking might make that acceptable, but c= omes at a high cost which I think would clearly not be justified.=C2=A0 OTO= H, MRH tracking might also be attractive for other cleanup proposals having= the similar confiscation risk issues and if so then its cost may be worthw= hile.

I say it has little value because while keep= ing 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 w= orse than using a single big one especially given that >10k is already u= nspendable, prunable, and already pruned by implementations.=C2=A0 Worse be= cause each distinct output has overheads and because even non-op-return bec= omes prunable if its over 10k now, while a dozen 520 byte outputs wouldn= 9;t be prunable under this proposal. So, paradoxically this limit might inc= rease the amount of non-prunable data.=C2=A0 A variant that just made >5= 20 unspendable would be better in this respect, but I doubt it would at all= satisfy the proponents' motivations. Likewise, one that expanded the t= hreshold to more like 1350 would at least avoid the bare CMS concerns but a= lso would probably not satisfy the proposals proponents.



On Fri, Oct 17, 2025 at 6:45=E2=80= =AFPM 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAAS2fgQEdVVcb%3DDfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng%40ma= il.gmail.com.
--000000000000b4b8c8064198a7ab--