From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 23:40:23 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEMKa-0005er-0K for bitcoindev@gnusha.org; Wed, 29 Oct 2025 23:40:23 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3c9b7ffe2c4sf310947fac.0 for ; Wed, 29 Oct 2025 23:40:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761806411; cv=pass; d=google.com; s=arc-20240605; b=SNuZITIXsvGmiRLM6TSG5NYAtsP8yOqwMW83KaHkRgiAnAjaa4HpHhcQ3NT+sQZp06 BLrpjBAOeQcaALX3sQJtP57wdSF0f+Z7f4nXZpBPxKJRmqHjdDuzdJX+tIrs2vmXd7BC E4H90rWssKz+1/9qVrGjllM45MuIIT+S0UDC+chqaBZCgk8BKiyD4CkkQ/J077odXUo8 d9u7QlOLoa21qog4CJATy07QJkrrfhuUuMEho9OduczlcgXAZ11FwyvighAGG6q8lEFN +BtUVTLmLsL/KM81u6BmsRcm5nOxucE3rwoBLEKxBceJDtiQWDWeWfsojBnBYXt52bKB y9Iw== 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=Bpyjhc4vcQLH/imO0ZGDZsBTIH7tvrrz/3cTt5nw4lQ=; fh=pJS3PUyA22tTutUq3VLpQ6J+ISghsZGHl7wia7kKPXQ=; b=JBsUJK2gGr1YBnMvtw3B4cyNeUn8cVDbFOkUBC7SPOX4lzdtFkgOMO31FJknEnw+Ly qT/8+B3YSJ/AN1EX4VSQwnZvnwmziYwGmteJ5kGsspYRGDroqnCb+yvqvH6+NhKMp9n3 ZkIStR3JISis5J0qIn4EI/zobt68es3MAfovepltMHj4xjKESDW5x0zCHi5FVI94PBzx MzUaI4L0tapy0Hu2VC+1NXCvMD524gLXafeFqCLq+D1tGuzn0PcxBcI2momyZlqPOxLu eSSXzu66wlDrgkQrhHC2xJCBy7fIDc/78H/qBFs6sgE6EmlrLNx33M+HnxvfuOsQNJL+ kl/A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=dK0Hc2YG; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c 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=1761806411; x=1762411211; 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=Bpyjhc4vcQLH/imO0ZGDZsBTIH7tvrrz/3cTt5nw4lQ=; b=Ao/jePt4OM6bbY8D8abgRP8lkLtgIvMZMSrOlGPCigECw2KwMrRaVbLha5EHJXPaU1 GXrewsYXb+LsBkMyVLTfQcBGrWqWcJjmhohQ4NaEVo9Ox7DzpPNe+Vn8JYBEz+edp4pe eIrOEJah8CQPNQ5nm1dI9xxaMquqZwFYFtLSVDNL468yQwYdsN4aomUX0ALSBiR0lQgH bRKxLt+ZJo7DsWYBjbsBK4AOc1glHMVnK4k3Ua6ORciOXl2w0VLNqrHHkzsfaALXgcSh wzB2X/5m87YENFXxl5HAHD8DodFUIiWPFHj0B7RqF7uCr8LsmLL5TJFdg6RvcGbnL56G jlnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761806411; x=1762411211; 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=Bpyjhc4vcQLH/imO0ZGDZsBTIH7tvrrz/3cTt5nw4lQ=; b=G4ck9v9Lgy31IAcN9wubE8xgNTs8OGuhTl4vUmn9sm0IPgWjZ0uUdHpCV/sSA1LmZA OU1wkDwgH/WHXC80KeTT8xKapS+Ke4ef4yrSsBlRrxau/krQ37s/DsqzcCHUyJ515FCs U4whwKlwTaK8nq9Jffp8bNn/PsZDHXbU/DXcSUN/niFkHBX6pWisrTPHqTvF2PcIIdMd z/zx2e/LlnERhNygyOVdMO11wek5IGL1xknBjpuP3uxFQ/0MoeQFomqMp0NOQb+t7Euk 1h1/nclBJC4z/7vG3ZpqhkV3UEC8jKD9z5bvpuZFmdo0I4N5E9xNXjo0ehx/mHGJWlte Ghjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761806411; x=1762411211; 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=Bpyjhc4vcQLH/imO0ZGDZsBTIH7tvrrz/3cTt5nw4lQ=; b=SDGTVw9ftyZ1HLMUiHhoyBWGWfV9B1DGkoFr+hg0WvCO0+hFxOiN5tm1maoEwSUNG0 +eqQ4sjM1qI8bK58l+FcDX7qNJy85rg0HC0JUBpnieHFAi7ckAAeOhK5vYDpuKc5Zwzw dloEgaQIln+0vEkC/kzSA3ro4bTTZsthxQjG5N8/gMXhjQi5AZzy7WW07wtji4+Thj4w rG4qpXhoylbNlfnil1DyJYF+duape1dPmGtGz0IdnupaqnlrRSeu4tipGssoRF4sLDVo XzH9UBVuk8mNESs7zK+RbYH18ISOzbZG+uiZHAEeLL2vkFm5KCApRnQ40fP6EpmIbt15 5yew== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWWF99K+DBl6Y9TfqV2VLDbz5Fc1urp1mekVM09ho72cgNjtTzeB3P7AXwJy2o0NO/93jZKKzLWCg5i@gnusha.org X-Gm-Message-State: AOJu0YxdftYMivIZZrAl95i7qrj4WkG60Z2vBKL3wrlNbdZ6uOkun1EZ jS4/kY2LuM5AriMZ7ECZQoZo408a/FGpe4W+VVMIVYdDoFclFRCmpJaL X-Google-Smtp-Source: AGHT+IFAlLEP2e7pG4kZTuEyYmpb5X4pLLQx/6z2odfAyPLXsmC4q8W0N2oDeyTNJBXLeVQRtITbIQ== X-Received: by 2002:a05:6870:2892:b0:396:697a:bebf with SMTP id 586e51a60fabf-3d747d497ffmr3083019fac.40.1761806410678; Wed, 29 Oct 2025 23:40:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bgKC+KMV++g1ThCNP5H0aiX925JG4EI2gG1sbBmICpjA==" Received: by 2002:a05:6870:e194:b0:383:97ca:d48c with SMTP id 586e51a60fabf-3d8b5bb1f81ls250174fac.0.-pod-prod-04-us; Wed, 29 Oct 2025 23:40:06 -0700 (PDT) X-Received: by 2002:a05:6808:250b:b0:44d:aa05:ce74 with SMTP id 5614622812f47-44f7a78aa4bmr2504031b6e.19.1761806406830; Wed, 29 Oct 2025 23:40:06 -0700 (PDT) Received: by 2002:a05:6808:6557:10b0:44f:6c18:6870 with SMTP id 5614622812f47-44f7b05f2d7msb6e; Wed, 29 Oct 2025 23:16:10 -0700 (PDT) X-Received: by 2002:a05:6a00:3c95:b0:7a2:705c:5037 with SMTP id d2e1a72fcca58-7a4e33c655emr7267950b3a.11.1761804969505; Wed, 29 Oct 2025 23:16:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761804969; cv=none; d=google.com; s=arc-20240605; b=HIRHted/4redu45FRaKLOverRtAuK6ccE3sw6k8pj3eV7uIfyoteiLOEcDuEJL9VLe S0RB76GpEH6+pNfqgchm5xJ7kONcncOflpe0paCXF5J7nzQfPZbSX4oixYBVGhPr5Ede pX7BznwdawayjLKHxtkiub7bsGLwX+Ju+mfIsuo1uLwkt0sSQ+BzpL8GwN+XINIqeXL0 dsPyA5akj32GOHfxByPhIfjRWO8VSEFn6nOAaN9w9u/9mtYlgMtz4e/PmBrdH7wE2qlE LHOokP35W3yL10XkyQwi665/0mt1476lUiCd2h2mx6DZdhKP3U7ypSQfV6JmvHLX6HgY 8cTw== 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=apA2F0kW15iM2T6QiTT4Qb9xh+ZHO3rEFdLgXP/LOPc=; fh=XRCt6tXyE13OJL9bdi5QDV4LIbaN0BGGFFP1sVis3HI=; b=W9UaRm+a9Efc3Brw1ytBtki4CgSg96cqPJqVnOTtppVgXwyS+Xmai1zjkeoAqvgOOF tFM41mQ0dWHpgGP7tOXw2GDZTxDjklWfIA2122GZw+GKmZlCPnYz8P7Bnt0MI1tNzTol hjTUCCSYgAto1Nz3jk4ImxwapOjb+bZ0D9kC17xacaEylApPeF4GC2aX/TpLE6CkcEwE i0u9UEqpZu0N9XWF5JNNwPlRSx4IqdiHOfS+oiCbhZbHRUYBOkZxq5Ag393KZ2Bf8VQa Gw4XJS9xKuKyViS24YpE2Y3gXRYN+dvk3Z5sh9zzXE+2ysHEuZ7HqBPkRSJJ2tlMYnR6 RPFQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=dK0Hc2YG; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c 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-x52c.google.com (mail-pg1-x52c.google.com. [2607:f8b0:4864:20::52c]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7a415676cecsi674379b3a.6.2025.10.29.23.16.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 23:16:09 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c as permitted sender) client-ip=2607:f8b0:4864:20::52c; Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-b6cdba2663dso456232a12.2 for ; Wed, 29 Oct 2025 23:16:09 -0700 (PDT) X-Gm-Gg: ASbGncu+rOBogRM+dEIj5UNNBahpqxKfUiUCqlDqctLUoTBjZx8ZnxO9/ZfD7ozhjIf kfS0j/YAZs9X1c073fjzlf5hGRzjrEAPrvLwHhmgE1rTm0dicJht1LBu91kQAmMXXSomvVq751T Of6CgCI36QsKc0TRo1+ma3n+rZF3B3/2mpYFCUHO3tyvVzAb67v/aqiICyyTl97d+64xmhrzITS uiDU6CQowOwKpTP1B9OlEvyA5EHOlLpeP5tIwKEaPRhNxpmLdlAzVQWzJgEuzlYnCsIDJa5AQP7 ewiQwj6SHovBdYoRD4II2qZDqwyKLs3g7o/5b6IM X-Received: by 2002:a17:902:ce0b:b0:267:9aa5:f6a6 with SMTP id d9443c01a7336-294dee128cfmr64104345ad.19.1761804968772; Wed, 29 Oct 2025 23:16:08 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> <5135a031-a94e-49b9-ab31-a1eb48875ff2n@googlegroups.com> <78475572-3e52-44e4-8116-8f1a917995a4n@googlegroups.com> In-Reply-To: From: Greg Maxwell Date: Thu, 30 Oct 2025 06:15:56 +0000 X-Gm-Features: AWmQ_blnhwRCEO2AXXR9o5d-QbxPDw8CY_hn6r-AqRcuJI6ErTtoSELRQ3WIjS4 Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Michael Tidwell Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000053c7c806425a2f4a" 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=dK0Hc2YG; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c 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 (/) --00000000000053c7c806425a2f4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Prior softforks have stuck to using the more explicit "forward compatibility" mechanisms, so -- e.g. if you use OP_NOP3 or a higher transaction version number or whatever that had no purpose (and would literally do nothing), saw ~no use, and was non-standard, or scripts that just anyone could have immediately taken at any time (e.g. funds free for the collecting rather than something secure)... then in that case I think people have felt that the long discussion leading up to a softfork was enough to acceptably mitigate the risk. Tapscript was specifically designed to make upgrades even safer and easier by making it so that the mere presence of any forward compat opcode (OP_SUCCESSn) makes the whole script insecure until that opcode is in use. The proposal to limit scriptpubkey size is worse because longer scripts had purposes and use (e.g. larger multisigs) and unlike some NOP3 or txversions where you could be argued to deserve issues if you did something so weird and abused a forward compat mechanism, people running into a 520 limit could have been pretty boring (and I see my own watching wallets have some scriptpubkeys beyond that size (big multisigs), in fact-- though I don't *think* any are still in use, but even I'm not absolutely sure that such a restriction wouldn't confiscate some of my own funds--- and it's a pain in the rear to check, having to bring offline stuff online, etc). Confiscation isn't just limited to timelocks, since the victims of it may just not know about the consensus change and while they could move their coins they don't. One of the big advantages many people see in Bitcoin is that you can put your keys in a time capsule in the foundation of your home and trust that they're still going to be there and you'll be able to use your coins a decade later. ... that you don't have to watch out for banks drilling your safe deposit boxes or people putting public notices in classified ads laying claim to your property. I don't even think bitcoin has ever policy restricted something that was in active use, much less softforked out something like that. I wouldn't say it was impossible but I think on the balance it would favor a notice period so that any reasonable person could have taken notice, taken action, or at least spoke up. But since there is no requirement to monitor and that's part of bitcoin's value prop the amount of time to consider reasonable ought to be quite long. Which also is at odds with the emergency measures position being taken by proponents of such changes. (which also, I think are just entirely unjustified, even if you accept the worst version of their narrative with the historical chain being made _illegal_, one could simply produce node software that starts from a well known embedded utxo snapshot and doesn't process historical blocks. Such a thing would be in principle a reduction in the security model, but balances against the practical and realistic impact of potentially confiscating coins I think it looks pretty fine by comparison. It would also be fully consensus compatible, assuming no reorg below that point, and can be done right now by anyone who cares in a totally permissionless and coercion free manner) On Thu, Oct 30, 2025 at 5:13=E2=80=AFAM Michael Tidwell wrote: > Greg, > > > Also some risk of creating a new scarce asset class. > > Well, Casey Rodarmor is in the thread, so lol maybe. > > Anyway, point taken. I want to be 100% sure I understand the > hypotheticals: there could be an off-chain, presigned, transactions that > needs more than 520 bytes for the scriptPubKey and, as Poelstra said, cou= ld > even form a chain of presigned transactions under some complex, previousl= y > unknown, scheme that only becomes public after this change is made. Can y= ou > confirm? > > Would it also be a worry that a chain of transactions using said utxo > could commit to some bizarre scheme, for instance a taproot transaction > utxo that later is presigned committed back to P2MS larger than 520 bytes= ? > If so, I think I get it, you're saying to essentially guarantee no > confiscation we'd never be able to upgrade old UTXOs and we'd need to tra= ck > them forever to prevent unlikely edge cases? > Does the presigned chain at least stop needing to be tracked once the > given UTXO co-mingles with a post-update coinbase utxo? > > If so, this is indeed complex! This seems pretty insane both for the > complexity of implementing and the unlikely edge cases. Has Core ever mad= e > a decision of (acceptable risk) to upgrade with protection of onchain utx= os > but not hypothetical unpublished ones? > Aren't we going to run into the same situation if we do an op code clean > up in the future if we had people presign/commit to op codes that are no > longer consensus valid? > > Tidwell > > On Wednesday, October 29, 2025 at 10:32:10=E2=80=AFPM UTC-4 Greg Maxwell = wrote: > >> "A few bytes" might be on the order of forever 10% increase in the UTXO >> set size, plus a full from-network resync of all pruned nodes and a full >> (e.g. most of day outage) reindex of all unpruned nodes. Not >> insignificant but also not nothing. Such a portion of the existing utxo >> size is not from outputs over 520 bytes in size, so as a scheme for utxo >> set size reduction the addition of MHT tracking would probably make it a >> failure. >> >> Also some risk of creating some new scarce asset class, txouts consistin= g >> of primordial coins that aren't subject to the new rules... sounds like = the >> sort of thing that NFT degens would absolutely love. That might not be = an >> issue *generally* for some change with confiscation risk, but for a chan= ge >> that is specifically intended to lobotomize bitcoin to make it less usef= ul >> to NFT degens, maybe not such a great idea. :P >> >> I mentioned it at all because I thought it could potentially be of some >> use, I'm just more skeptical of it for the current context. Also luke-j= r >> and crew has moved on to actually propose even more invasive changes tha= n >> just limiting the script size, which I anticipated, and has much more >> significant issues. Just size limiting outputs likely doesn't harm any >> interests or usages-- and so probably could be viable if the confiscatio= n >> issue was addressed, but it also doesn't stick it to people transacting = in >> ways the priests of ocean mining dislike. >> >> > I believe you're pointing out the idea of non economically-rational >> spammers? >> >> I think it's a mistake to conclude the spammers are economically >> irrational-- they're often just responding to different economics which = may >> be less legible to your analysis. In particular, NFT degens prefer the >> high cost of transactions as a thing that makes their tokens scarce and >> gives them value. -- otherwise they wouldn't be swapping for one less >> efficient encoding for another, they're just be using another blockchain >> (perhaps their own) entirely. >> >> >> >> >> On Thu, Oct 30, 2025 at 1:16=E2=80=AFAM Michael Tidwell >> wrote: >> >>> > MRH tracking might make that acceptable, but comes at a high cost >>> which I think would clearly not be justified. >>> >>> Greg, I want to ask/challenge how bad this is, this seems like a >>> generally reusable primitive that could make other upgrades more feasib= le >>> that also have the same strict confiscation risk profile. >>> IIUC, the major pain is, 1 big reindex cost + a few bytes per utxo? >>> >>> Poelstra, >>> >>> > I don't think this is a great idea -- it would be technically hard to >>> implement and slow deployment indefinitely. >>> >>> I would like to know how much of a deal breaker this is in your opinion= . >>> Is MRH tracking off the table? In terms of the hypothetical presigned >>> transactions that may exist using P2MS, is this a hard enough reason to >>> require a MRH idea? >>> >>> Greg, >>> >>> > So, paradoxically this limit might increase the amount of non-prunabl= e >>> data >>> >>> I believe you're pointing out the idea of non economically-rational >>> spammers? We already see actors ignoring cheaper witness inscription >>> methods. If spam shifts to many sub-520 fake pubkey outputs (which I >>> believe is less harmful than stamps), that imo is a separate UTXO cost >>> discussion. (like a SF to add weight to outputs). Anywho, this point al= one >>> doesn't seem sufficient to add as a clear negative reason for someone >>> opposed to the proposal. >>> >>> Thanks, >>> Tidwell >>> On Wednesday, October 22, 2025 at 5:55:58=E2=80=AFAM UTC-4 moonsettler = wrote: >>> >>>> > Confiscation is a problem because of presigned transactions >>>> >>>> Allow 10000 bytes of total scriptPubKey size in each block counting >>>> only those outputs that are larger than x (520 as proposed). >>>> The code change is pretty minimal from the most obvious implementation >>>> of the original rule. >>>> >>>> That makes it technically non-confiscatory. Still non-standard, but if >>>> anyone out there so obnoxiously foot-gunned themselves, they can't cla= im >>>> they were rugged by the devs. >>>> >>>> BR, >>>> moonsettler >>>> >>>> On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL < >>>> ad...@qrsnap.io> wrote: >>>> >>>> > Hey, >>>> > >>>> > First, thank you to everyone who responded, and please continue to d= o >>>> so. There were many thought provoking responses and this did shift my >>>> perspective quite a bit from the original post, which in of itself was= the >>>> goal to a degree. >>>> > >>>> > I am currently only going to respond to all of the current concerns. >>>> Acks; though I like them will be ignored unless new discoveries are >>>> included. >>>> > >>>> > Tl;dr (Portlands Perspective) >>>> > - Confiscation is a problem because of presigned transactions >>>> > - DoS mitigation could also occur through marking UTXOs as >>>> unspendable if > 520 bytes, this would preserve the proof of publicati= on. >>>> > - Timeout / Sunset logic is compelling >>>> > - The (n) value of acceptable needed bytes is contentious with the >>>> lower suggested limit being 67 >>>> > - Congestion control is worth a look? >>>> > >>>> > Next Step: >>>> > - Deeper discussion at the individual level: Antoine Poinsot and GCC >>>> overlap? >>>> > - Write an implementation. >>>> > - Decide to pursue BIP >>>> > >>>> > Responses >>>> > >>>> > Andrew Poelstra: >>>> > > There is a risk of confiscation of coins which have pre-signed but >>>> > > unpublished transactions spending them to new outputs with large >>>> > > scriptPubKeys. Due to long-standing standardness rules, and the >>>> presence >>>> > > of P2SH (and now P2WSH) for well over a decade, I'm skeptical that >>>> any >>>> > > such transactions exist. >>>> > >>>> > PortlandHODL: This is a risk that can be incurred and likely not >>>> possible to mitigate as there could be possible chains of transactions= so >>>> even when recursively iterating over a chain there is a chance that a >>>> presigned breaks this rule. Every idea I have had from block redemptio= n >>>> limits on prevouts seems to just be a coverage issue where you can mak= e the >>>> confiscation less likely but not completely mitigated. >>>> > >>>> > Second, there are already TXs that effectively have been confiscated >>>> at the policy level (P2SH Cleanstack violation) where the user can not= find >>>> any miner with a policy to accept these into their mempool. (3 years) >>>> > >>>> > /dev /fd0 >>>> > > so it would be great if this was restricted to OP_RETURN >>>> > >>>> > PortlandHODL: I reject this completely as this would remove the >>>> UTXOset omission for the scriptPubkey and encourage miners to subvert = the >>>> OP_RETURN restriction and instead just use another op_code, this also = do >>>> not hit on some of the most important factors such as DoS mitigation a= nd >>>> legacy script attack surface reduction. >>>> > >>>> > Peter Todd >>>> > > NACK ... >>>> > >>>> > PortlandHODL: You NACK'd for the same reasons that I stated in my OP= , >>>> without including any additional context or reasoning. >>>> > >>>> > jeremy >>>> > > I think that this type of rule is OK if we do it as a "sunsetting" >>>> restriction -- e.g. a soft fork active for the next N blocks (N =3D e.= g. 2 >>>> years, 5 years, 10 years). >>>> > >>>> > If action is taken, this is the most reasonable approach. Alleviatin= g >>>> confiscatory concerns through deferral. >>>> > >>>> > > You can argue against this example probably, but it is worth >>>> considering that absence of evidence of use is not evidence of absence= of >>>> use and I myself feel that overall our understanding of Bitcoin transa= ction >>>> programming possibilities is still early. If you don't like this examp= le, I >>>> can give you others (probably). >>>> > >>>> > Agreed and this also falls into the reasoning for deciding to utiliz= e >>>> point 1 in your response. My thoughts on this would be along the lines= of >>>> proof of publication as this change only has the effect of stripping a= way >>>> the executable portion of a script between 521 and 10_000 bytes or the >>>> published data portion if > 10_000 bytes which the same data could lik= ely >>>> be published in chunked segments using outpoints. >>>> > >>>> > Andrew Poelstra: >>>> > > Aside from proof-of-publication (i.e. data storage directly in the >>>> UTXO >>>> > > set) there is no usage of script which can't be equally (or better= ) >>>> > > accomplished by using a Segwit v0 or Taproot script. >>>> > >>>> > This sums up the majority of future usecase concern >>>> > >>>> > Anthony Towns: >>>> > > (If you restricted the change to only applying to scripts that use= d >>>> > non-push operators, that would probably still provide upgrade >>>> flexibility >>>> > while also preventing potential script abuses. But it wouldn't do >>>> anything >>>> > to prevent publishing data) >>>> > >>>> > Could this not be done as segments in multiple outpoints using a >>>> coordination outpoint? I fail to see why publication proof must be in = a >>>> single chunk. This does though however bring another alternative to mi= nd, >>>> just making these outpoints unspendable but not invalidate the block >>>> through inclusion... >>>> > >>>> > > As far as the "but contiguous data will be regulated more strictly= " >>>> > argument goes; I don't think "your honour, my offensive content has >>>> > strings of 4d0802 every 520 bytes >>>> > >>>> > Correct, this was never meant to resolve this issue. >>>> > >>>> > Luke Dashjr: >>>> > > If we're going this route, we should just close all the gaps for >>>> the immediate future: >>>> > >>>> > To put it nicely, this is completely beyond the scope of what is >>>> being proposed. >>>> > >>>> > Guus Ellenkamp: >>>> > > If there are really so few OP_RETURN outputs more than 144 bytes, >>>> then >>>> > why increase the limit if that change is so controversial? It seems >>>> > people who want to use a larger OP_RETURN size do it anyway, even >>>> with >>>> > the current default limits. >>>> > >>>> > Completely off topic and irrelevant >>>> > >>>> > Greg Tonoski: >>>> > > Limiting the maximum size of the scriptPubKey of a transaction to >>>> 67 bytes. >>>> > >>>> > This leave no room to deal with broken hashing algorithms and very >>>> little future upgradability for hooks. The rest of these points should= be >>>> merged with Lukes response and either hijack my thread or start a new = one >>>> with the increased scope, any approach I take will only be related to = the >>>> ScriptPubkey >>>> > >>>> > Keagan McClelland: >>>> > > Hard NACK on capping the witness size as that would effectively ba= n >>>> large scripts even in the P2SH wrapper which undermines Bitcoin's abil= ity >>>> to be an effectively programmable money. >>>> > >>>> > This has nothing to do with the witness size or even the P2SH wrappe= r >>>> > >>>> > Casey Rodarmor: >>>> > > I think that "Bitcoin could need it in the future?" might be a goo= d >>>> enough >>>> > reason not to do this. >>>> > >>>> > > Script pubkeys are the only variable-length transaction fields >>>> which can be >>>> > covered by input signatures, which might make them useful for future >>>> soft >>>> > forks. I can imagine confidential asset schemes or post-quantum coin >>>> recovery >>>> > schemes requiring large proofs in the outputs, where the validity of >>>> the proof >>>> > determined whether or not the transaction is valid, and thus require >>>> the >>>> > proofs to be in the outputs, and not just a hash commitment. >>>> > >>>> > Would the ability to publish the data alone be enough? Example make >>>> the output unspendable but allow for the existence of the bytes to be >>>> covered through the signature? >>>> > >>>> > >>>> > Antoine Poinsot: >>>> > > Limiting the size of created scriptPubKeys is not a sufficient >>>> mitigation on its own >>>> > I fail to see how this would not be sufficient? To DoS you need 2 >>>> things inputs with ScriptPubkey redemptions + heavy op_codes that requ= ire >>>> unique checks. Example DUPing stack element again and again doesn't wo= rk. >>>> This then leads to the next part is you could get up to unique complex >>>> operations with the current (n) limit included per input. >>>> > >>>> > > One of the goal of BIP54 is to address objections to Matt's earlie= r >>>> 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. >>>> > >>>> > Some notes is I would actually go as far as to say the confiscation >>>> risk is higher with the TX limit proposed in BIP54 as we actually have >>>> proof of redemption of TXs that break that rule and the input set to d= o >>>> this already exists on-chain no need to even wonder about the whole >>>> presigned. bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4= e3e08 >>>> > >>>> > Please let me know if I am incorrect on any of this. >>>> > >>>> > > Furthermore, it's always possible to get the biggest bang for our >>>> buck in a first step >>>> > >>>> > Agreed on bang for the buck regarding DoS. >>>> > >>>> > My final point here would be that I would like to discuss more, and >>>> this is response is from the initial view of your response and could b= e >>>> incomplete or incorrect, This is just my in the moment response. >>>> > >>>> > Antoine Riard: >>>> > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more i= n >>>> favor of prioritizing >>>> > a timewarp fix and limiting dosy spends by old redeem scripts >>>> > >>>> > The idea of congestion control is interesting, but this solution >>>> should significantly reduce the total DoS severity of known vectors. >>>> > >>>> > On Saturday, October 18, 2025 at 2:25:18=E2=80=AFAM UTC-7 Greg Maxwe= ll wrote: >>>> > >>>> > > Limits on block construction that cross transactions make it harde= r >>>> to accurately estimate fees and greatly complicate optimal block >>>> construction-- the latter being important because smarter and more com= puter >>>> powered mining code generating higher profits is a pro centralization >>>> factor. >>>> > > >>>> > > In terms of effectiveness the "spam" will just make itself >>>> indistinguishable from the most common transaction traffic from the >>>> perspective of such metrics-- and might well drive up "spam" levels be= cause >>>> the higher embedding cost may make some of them use more transactions.= The >>>> competition for these buckets by other traffic could make it effective= ly a >>>> block size reduction even against very boring ordinary transactions. .= .. >>>> which is probably not what most people want. >>>> > > >>>> > > I think it's important to keep in mind that bitcoin fee levels eve= n >>>> at 0.1s/vb are far beyond what other hosting services and other blockc= hains >>>> cost-- so anyone still embedding data in bitcoin *really* want to be t= here >>>> for some reason and aren't too fee sensitive or else they'd already be >>>> using something else... some are even in favor of higher costs since t= he >>>> high fees are what create the scarcity needed for their seigniorage. >>>> > > >>>> > > But yeah I think your comments on priorities are correct. >>>> > > >>>> > > >>>> > > >>>> > > On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM Antoine Riard >>>> wrote: >>>> > > >>>> > > > Hi list, >>>> > > > >>>> > > > Thanks to the annex covered by the signature, I don't see how th= e >>>> concern about limiting >>>> > > > the extensibility of bitcoin script with future (post-quantum) >>>> cryptographic schemes. >>>> > > > Previous proposal of the annex were deliberately designed with >>>> variable-length fields >>>> > > > to flexibly accomodate a wide range of things. >>>> > > > >>>> > > > I believe there is one thing that has not been proposed to limit >>>> unpredictable utterance >>>> > > > of spams on the blockchain, namely congestion control of >>>> categories of outputs (e.g "fat" >>>> > > > scriptpubkeys). Let's say P a block period, T a type of >>>> scriptpubkey and L a limiting >>>> > > > threshold for the number of T occurences during the period P. >>>> Beyond the L threshold, any >>>> > > > additional T scriptpubkey is making the block invalid. Or >>>> alternatively, any additional >>>> > > > T generating / spending transaction must pay some weight >>>> penalty... >>>> > > > >>>> > > > Congestion control, which of course comes with its lot of >>>> shenanigans, is not very a novel >>>> > > > idea as I believe it has been floated few times in the context o= f >>>> lightning to solve mass >>>> > > > closure, where channels out-priced at current feerate would have >>>> their safety timelocks scale >>>> > > > ups. >>>> > > > >>>> > > > No need anymore to come to social consensus on what is >>>> quantitative "spam" or not. The blockchain >>>> > > > would automatically throttle out the block space spamming >>>> transaction. Qualitative spam it's another >>>> > > > question, for anyone who has ever read shannon's theory of >>>> communication only effective thing can >>>> > > > be to limit the size of data payload. But probably we're kickly >>>> back to a non-mathematically solvable >>>> > > > linguistical question again [0]. >>>> > > > >>>> > > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more >>>> in favor of prioritizing >>>> > > > a timewarp fix and limiting dosy spends by old redeem scripts, >>>> rather than engaging in shooting >>>> > > > ourselves in the foot with ill-designed "spam" consensus >>>> mitigations. >>>> > > > >>>> > > > [0] If you have a soul of logician, it would be an interesting >>>> demonstration to come with >>>> > > > to establish that we cannot come up with mathematically or >>>> cryptographically consensus means >>>> > > > to solve qualitative "spam", which in a very pure sense is a >>>> linguistical issue. >>>> > > > >>>> > > > Best, >>>> > > > Antoine >>>> > > > OTS hash: >>>> 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999 >>>> > > > Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poins= ot a >>>> =C3=A9crit : >>>> > > > >>>> > > > > 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 o= f >>>> 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 fro= m >>>> *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 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 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= /1732/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 < >>>> fre...@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 an= d >>>> no reason to >>>> > > > > > > expect any I'm not sure the proposal is worth time relativ= e >>>> 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 i= n >>>> 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 fro= m >>>> it, send an email to bitcoindev+...@googlegroups.com. >>>> > > > > > To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/aPJ3w6bEoaye3WJ6%40consol= e. >>>> >>>> > > > >>>> > > > -- >>>> > > > 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+...@googlegroups.com. >>>> > > >>>> > > > To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/5135a031-a94e-49b9-ab31-a= 1eb48875ff2n%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+...@googlegroups.com. >>>> > To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/78475572-3e52-44e4-8116-8= f1a917995a4n%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+...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/f4755fb6-b031-4c60-b304-f1= 23ba2ff473n%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/bitcoindev/c208e054-b85a-4a5c-9193-c28e= f0d225c5n%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/= CAAS2fgSNtO6kpfm0XaBCufyExjJnxg87ttLGUgpUU9pkemZTig%40mail.gmail.com. --00000000000053c7c806425a2f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Prior softforks have stuck to using the more explicit= "forward compatibility" mechanisms, so -- e.g. if you use OP_NOP= 3 or a higher transaction version number or whatever that had no purpose (a= nd would literally=C2=A0do nothing), saw ~no use, and was non-standard, or = scripts that just anyone could have immediately taken at any time (e.g. fun= ds free for the collecting rather than something secure)... then in that ca= se I think people have felt that the long discussion leading up to a softfo= rk=C2=A0was enough to acceptably mitigate the risk.=C2=A0 Tapscript was spe= cifically designed to make upgrades even safer and easier by making it so t= hat the mere presence of any forward compat opcode (OP_SUCCESSn) makes the = whole script insecure until that opcode is in use.=C2=A0

The proposal to limit scriptpubkey size is worse because longer scri= pts had purposes and use (e.g. larger multisigs) and unlike some NOP3 or tx= versions where you could be argued to deserve issues if you did something s= o weird and abused a forward compat mechanism, people running into a 520 li= mit could have been pretty boring (and I see my own watching wallets have s= ome scriptpubkeys beyond that size (big multisigs), in fact-- though I don&= #39;t *think* any are still in use, but even I'm not absolutely sure th= at such a restriction wouldn't confiscate some of my own funds--- and i= t's a pain in the rear to check, having to bring offline stuff online, = etc).

Confiscation isn't just limited to timel= ocks, since the victims of it may just not know about the consensus change = and while they could move their coins they don't.=C2=A0 One of the big = advantages many people see in Bitcoin is that you can put your keys in a ti= me capsule in the foundation of your home and trust that they're still = going to be there and you'll be able to use your coins a decade later. = ... that you don't have to watch out for banks drilling your safe depos= it boxes or people putting public notices in classified ads laying claim to= your property.

I don't even think bitcoin has= ever policy restricted something that was in active use, much less softfor= ked=C2=A0out something like that.=C2=A0 I wouldn't say it was impossibl= e but I think on the balance it would favor a notice period so that any rea= sonable person could have taken notice, taken action, or at least spoke up.= =C2=A0 But since there is no requirement to monitor and that's part of = bitcoin's value prop the amount of time to consider reasonable ought to= be quite long.=C2=A0 Which also is at odds with the emergency measures pos= ition being taken by proponents of such changes.

(= which also, I think are just entirely unjustified, even if you accept the w= orst version of their narrative with the historical chain being made _illeg= al_, one could simply produce node software that starts from a well known e= mbedded utxo snapshot and doesn't process historical blocks.=C2=A0 =C2= =A0Such a thing would be in principle a reduction in the security model, bu= t balances against the practical and realistic impact of potentially confis= cating coins I think it looks pretty fine by comparison.=C2=A0 It would als= o be fully consensus compatible, assuming no reorg below that point, and ca= n be done right now by anyone who cares in a totally permissionless and coe= rcion free manner)



On Thu, Oct 30, 2025 at 5:13=E2=80=AFAM Michael Tidwell <mtidwell021@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Greg,

> Also = some risk of creating a new scarce asset class.

Well, Casey Rodarmor is in the thread, so lol maybe.

Anyway, point taken. I want to be 100% sure I understand the hypothetica= ls: there could be an off-chain, presigned, transactions that needs more th= an 520 bytes for the scriptPubKey and, as Poelstra said, could even form a = chain of presigned transactions under some complex, previously unknown, sch= eme that only becomes public after this change is made. Can you confirm?

Would it also be a=C2=A0worry that a chain of transactions using said ut= xo could commit to some bizarre scheme, for instance a taproot transaction = utxo that later is presigned committed back to P2MS larger than 520 bytes? = If so, I think I get it, you're saying to essentially guarantee no conf= iscation we'd never be able to upgrade old UTXOs and we'd need to t= rack them forever to prevent unlikely edge cases?
Does the presigned ch= ain at least stop needing to be tracked once the given UTXO co-mingles with= a post-update coinbase utxo?

If so, this is indeed complex! This seems pretty insane both for the com= plexity of implementing and the unlikely edge cases. Has Core ever made a d= ecision of (acceptable risk) to upgrade with protection of onchain utxos bu= t not hypothetical unpublished ones?
Aren't we going to run into th= e same situation if we do an op code clean up in the future if we had peopl= e presign/commit to op codes that are no longer consensus valid?

Tidwell


On Wednesday, October 29, 2025 at 10:32:10=E2=80=AFPM UTC-4 Greg M= axwell wrote:
"A few bytes" might be on the order of foreve= r 10% increase in the UTXO set size, plus a full from-network resync of all= pruned nodes and a full (e.g. most of day outage) reindex of all unpruned = nodes.=C2=A0 Not insignificant=C2=A0but also not nothing.=C2=A0 Such a port= ion of the=C2=A0existing utxo size is not from outputs over 520 bytes in si= ze, so as a scheme for utxo set size reduction the addition of MHT tracking= would probably make it a failure.

Also some risk = of creating some new scarce asset class, txouts consisting of primordial=C2= =A0coins that aren't subject to the new rules... sounds like the sort o= f thing that NFT degens would absolutely love.=C2=A0 That might not be an i= ssue *generally* for some change with confiscation=C2=A0risk, but for a cha= nge that is specifically intended to lobotomize bitcoin to make it less use= ful to NFT degens, maybe not such a great idea. :P

I mentioned it at all because I thought it could potentially be of some us= e, I'm just more skeptical of it for the current context.=C2=A0 Also lu= ke-jr and crew has moved on to actually propose even more invasive changes = than just limiting the script size, which I anticipated, and has much more = significant=C2=A0issues.=C2=A0 Just size limiting outputs likely doesn'= t harm any interests or usages-- and so probably could be viable if the con= fiscation issue was addressed, but it also doesn't stick it to people t= ransacting in ways the priests of ocean mining dislike.=C2=A0

>=C2=A0I believe you're pointing = out the idea of non economically-rational spammers?

I think it's a mistake to conclude the spammer= s are economically irrational-- they're often just responding to differ= ent economics which may be less legible to your analysis.=C2=A0 In particul= ar, NFT degens prefer the high cost of transactions as a thing that makes t= heir tokens scarce and gives them value.=C2=A0 -- otherwise they wouldn'= ;t be swapping for one less efficient encoding for another, they're jus= t be using another blockchain (perhaps their own) entirely.

<= /div>



On Thu,= Oct 30, 2025 at 1:16=E2=80=AFAM Michael Tidwell <mt= idw...@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">> MRH tracking might ma= ke that acceptable, but comes at a high cost which I think would clearly no= t be justified.

Greg, I want to ask/challenge how bad this is, this = seems like a generally reusable primitive that could make other upgrades mo= re feasible that also have the same strict confiscation risk profile.
II= UC, the major pain is, 1 big reindex cost + a few bytes per utxo?

Po= elstra,

> I don't think this is a great idea -- it would be t= echnically hard to
implement and slow deployment indefinitely.

I = would like to know how much of a deal breaker this is in your opinion. Is M= RH tracking off the table? In terms of the hypothetical presigned transacti= ons that may exist using P2MS, is this a hard enough reason to require a MR= H idea?

Greg,

> So, paradoxically this limit might increas= e the amount of non-prunable data

I believe you're pointing out = the idea of non economically-rational spammers? We already see actors ignor= ing cheaper witness inscription methods. If spam shifts to many sub-520 fak= e pubkey outputs (which I believe is less harmful than stamps), that imo is= a separate UTXO cost discussion. (like a SF to add weight to outputs). Any= who, this point alone doesn't seem sufficient to add as a clear negativ= e reason for someone opposed to the proposal.

Thanks,
Tidwell
On Wednesday,= October 22, 2025 at 5:55:58=E2=80=AFAM UTC-4 moonsettler wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">> Confiscation is a pro= blem because of presigned transactions

Allow 10000 bytes of total scriptPubKey size in each block counting onl= y those outputs that are larger than x (520 as proposed).
The code change is pretty minimal from the most obvious implementation = of the original rule.

That makes it technically non-confiscatory. Still non-standard, but if = anyone out there so obnoxiously foot-gunned themselves, they can't clai= m they were rugged by the devs.

BR,
moonsettler

On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL <ad...@qrsnap.io> wrote:

> Hey,
>=20
> First, thank you to everyone who responded, and please continue to= do so. There were many thought provoking responses and this did shift my p= erspective quite a bit from the original post, which in of itself was the g= oal to a degree.
>=20
> I am currently only going to respond to all of the current concern= s. Acks; though I like them will be ignored unless new discoveries are incl= uded.
>=20
> Tl;dr (Portlands Perspective)
> - Confiscation is a problem because of presigned transactions
> - DoS mitigation could also occur through marking UTXOs as unspend= able if > 520 bytes, this would preserve the proof of publication.
> - Timeout / Sunset logic is compelling
> - The (n) value of acceptable needed bytes is contentious with the= lower suggested limit being 67
> - Congestion control is worth a look?
>=20
> Next Step:
> - Deeper discussion at the individual level: Antoine Poinsot and G= CC overlap?
> - Write an implementation.
> - Decide to pursue BIP
>=20
> Responses
>=20
> Andrew Poelstra:
> > There is a risk of confiscation of coins which have pre-signe= d but
> > unpublished transactions spending them to new outputs with la= rge
> > scriptPubKeys. Due to long-standing standardness rules, and t= he presence
> > of P2SH (and now P2WSH) for well over a decade, I'm skept= ical that any
> > such transactions exist.
>=20
> PortlandHODL: This is a risk that can be incurred and likely not p= ossible to mitigate as there could be possible chains of transactions so ev= en when recursively iterating over a chain there is a chance that a presign= ed breaks this rule. Every idea I have had from block redemption limits on = prevouts seems to just be a coverage issue where you can make the confiscat= ion less likely but not completely mitigated.
>=20
> Second, there are already TXs that effectively have been confiscat= ed at the policy level (P2SH Cleanstack violation) where the user can not f= ind any miner with a policy to accept these into their mempool. (3 years)
>=20
> /dev /fd0
> > so it would be great if this was restricted to OP_RETURN
>=20
> PortlandHODL: I reject this completely as this would remove the UT= XOset omission for the scriptPubkey and encourage miners to subvert the OP_= RETURN restriction and instead just use another op_code, this also do not h= it on some of the most important factors such as DoS mitigation and legacy = script attack surface reduction.
>=20
> Peter Todd
> > NACK ...
>=20
> PortlandHODL: You NACK'd for the same reasons that I stated in= my OP, without including any additional context or reasoning.
>=20
> jeremy
> > I think that this type of rule is OK if we do it as a "s= unsetting" restriction -- e.g. a soft fork active for the next N block= s (N =3D e.g. 2 years, 5 years, 10 years).
>=20
> If action is taken, this is the most reasonable approach. Alleviat= ing confiscatory concerns through deferral.
>=20
> > You can argue against this example probably, but it is worth = considering that absence of evidence of use is not evidence of absence of u= se and I myself feel that overall our understanding of Bitcoin transaction = programming possibilities is still early. If you don't like this exampl= e, I can give you others (probably).
>=20
> Agreed and this also falls into the reasoning for deciding to util= ize point 1 in your response. My thoughts on this would be along the lines = of proof of publication as this change only has the effect of stripping awa= y the executable portion of a script between 521 and 10_000 bytes or the pu= blished data portion if > 10_000 bytes which the same data could likely = be published in chunked segments using outpoints.
>=20
> Andrew Poelstra:
> > Aside from proof-of-publication (i.e. data storage directly i= n the UTXO
> > set) there is no usage of script which can't be equally (= or better)
> > accomplished by using a Segwit v0 or Taproot script.
>=20
> This sums up the majority of future usecase concern
>=20
> Anthony Towns:
> > (If you restricted the change to only applying to scripts tha= t used
> non-push operators, that would probably still provide upgrade flex= ibility
> while also preventing potential script abuses. But it wouldn't= do anything
> to prevent publishing data)
>=20
> Could this not be done as segments in multiple outpoints using a c= oordination outpoint? I fail to see why publication proof must be in a sing= le chunk. This does though however bring another alternative to mind, just = making these outpoints unspendable but not invalidate the block through inc= lusion...
>=20
> > As far as the "but contiguous data will be regulated mor= e strictly"
> argument goes; I don't think "your honour, my offensive c= ontent has
> strings of 4d0802 every 520 bytes
>=20
> Correct, this was never meant to resolve this issue.
>=20
> Luke Dashjr:
> > If we're going this route, we should just close all the g= aps for the immediate future:
>=20
> To put it nicely, this is completely beyond the scope of what is b= eing proposed.
>=20
> Guus Ellenkamp:
> > If there are really so few OP_RETURN outputs more than 144 by= tes, then
> why increase the limit if that change is so controversial? It seem= s
> people who want to use a larger OP_RETURN size do it anyway, even = with
> the current default limits.
>=20
> Completely off topic and irrelevant
>=20
> Greg Tonoski:
> > Limiting the maximum size of the scriptPubKey of a transactio= n to 67 bytes.
>=20
> This leave no room to deal with broken hashing algorithms and very= little future upgradability for hooks. The rest of these points should be = merged with Lukes response and either hijack my thread or start a new one w= ith the increased scope, any approach I take will only be related to the Sc= riptPubkey
>=20
> Keagan McClelland:
> > Hard NACK on capping the witness size as that would effective= ly ban large scripts even in the P2SH wrapper which undermines Bitcoin'= s ability to be an effectively programmable money.
>=20
> This has nothing to do with the witness size or even the P2SH wrap= per
>=20
> Casey Rodarmor:
> > I think that "Bitcoin could need it in the future?"= might be a good enough
> reason not to do this.
>=20
> > Script pubkeys are the only variable-length transaction field= s which can be
> covered by input signatures, which might make them useful for futu= re soft
> forks. I can imagine confidential asset schemes or post-quantum co= in recovery
> schemes requiring large proofs in the outputs, where the validity = of the proof
> determined whether or not the transaction is valid, and thus requi= re the
> proofs to be in the outputs, and not just a hash commitment.
>=20
> Would the ability to publish the data alone be enough? Example mak= e the output unspendable but allow for the existence of the bytes to be cov= ered through the signature?
>=20
>=20
> Antoine Poinsot:
> > Limiting the size of created scriptPubKeys is not a sufficien= t mitigation on its own
> I fail to see how this would not be sufficient? To DoS you need 2 = things inputs with ScriptPubkey redemptions + heavy op_codes that require u= nique checks. Example DUPing stack element again and again doesn't work= . This then leads to the next part is you could get up to unique complex op= erations with the current (n) limit included per input.
>=20
> > 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 direc= tion.
>=20
> Some notes is I would actually go as far as to say the confiscatio= n risk is higher with the TX limit proposed in BIP54 as we actually have pr= oof of redemption of TXs that break that rule and the input set to do this = already exists on-chain no need to even wonder about the whole presigned. b= b41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
>=20
> Please let me know if I am incorrect on any of this.
>=20
> > Furthermore, it's always possible to get the biggest bang= for our buck in a first step
>=20
> Agreed on bang for the buck regarding DoS.
>=20
> My final point here would be that I would like to discuss more, an= d this is response is from the initial view of your response and could be i= ncomplete or incorrect, This is just my in the moment response.
>=20
> Antoine Riard:
> > Anyway, in the sleeping pond of consensus fixes fishes, I'= ;m more in favor of prioritizing
> a timewarp fix and limiting dosy spends by old redeem scripts
>=20
> The idea of congestion control is interesting, but this solution s= hould significantly reduce the total DoS severity of known vectors.
>=20
> On Saturday, October 18, 2025 at 2:25:18=E2=80=AFAM UTC-7 Greg Max= well wrote:
>=20
> > Limits on block construction that cross transactions make it = harder to accurately estimate fees and greatly complicate optimal block con= struction-- the latter being important because smarter and more computer po= wered mining code generating higher profits is a pro centralization factor.
> >=20
> > In terms of effectiveness the "spam" will just make= itself indistinguishable from the most common transaction traffic from the= perspective of such metrics-- and might well drive up "spam" lev= els because the higher embedding cost may make some of them use more transa= ctions. The competition for these buckets by other traffic could make it ef= fectively a block size reduction even against very boring ordinary transact= ions. ... which is probably not what most people want.
> >=20
> > I think it's important to keep in mind that bitcoin fee l= evels even at 0.1s/vb are far beyond what other hosting services and other = blockchains cost-- so anyone still embedding data in bitcoin *really* want = to be there for some reason and aren't too fee sensitive or else they&#= 39;d already be using something else... some are even in favor of higher co= sts since the high fees are what create the scarcity needed for their seign= iorage.
> >=20
> > But yeah I think your comments on priorities are correct.
> >=20
> >=20
> >=20
> > On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM Antoine Riard <antoin...@gmail.com> wrote:
> >=20
> > > Hi list,
> > >=20
> > > Thanks to the annex covered by the signature, I don'= t see how the concern about limiting
> > > the extensibility of bitcoin script with future (post-qu= antum) cryptographic schemes.
> > > Previous proposal of the annex were deliberately designe= d with variable-length fields
> > > to flexibly accomodate a wide range of things.
> > >=20
> > > I believe there is one thing that has not been proposed = to limit unpredictable utterance
> > > of spams on the blockchain, namely congestion control of= categories of outputs (e.g "fat"
> > > scriptpubkeys). Let's say P a block period, T a type= of scriptpubkey and L a limiting
> > > threshold for the number of T occurences during the peri= od P. Beyond the L threshold, any
> > > additional T scriptpubkey is making the block invalid. O= r alternatively, any additional
> > > T generating / spending transaction must pay some weight= penalty...
> > >=20
> > > Congestion control, which of course comes with its lot o= f shenanigans, is not very a novel
> > > idea as I believe it has been floated few times in the c= ontext of lightning to solve mass
> > > closure, where channels out-priced at current feerate wo= uld have their safety timelocks scale
> > > ups.
> > >=20
> > > No need anymore to come to social consensus on what is q= uantitative "spam" or not. The blockchain
> > > would automatically throttle out the block space spammin= g transaction. Qualitative spam it's another
> > > question, for anyone who has ever read shannon's the= ory of communication only effective thing can
> > > be to limit the size of data payload. But probably we= 9;re kickly back to a non-mathematically solvable
> > > linguistical question again [0].
> > >=20
> > > Anyway, in the sleeping pond of consensus fixes fishes, = I'm more in favor of prioritizing
> > > a timewarp fix and limiting dosy spends by old redeem sc= ripts, rather than engaging in shooting
> > > ourselves in the foot with ill-designed "spam"= consensus mitigations.
> > >=20
> > > [0] If you have a soul of logician, it would be an inter= esting demonstration to come with
> > > to establish that we cannot come up with mathematically = or cryptographically consensus means
> > > to solve qualitative "spam", which in a very p= ure sense is a linguistical issue.
> > >=20
> > > Best,
> > > Antoine
> > > OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a6= 40dd4a31d72f0e4999
> > > Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoi= ne Poinsot a =C3=A9crit :
> > >=20
> > > > Hi,
> > > >=20
> > > > This approach was discussed last year when evaluati= ng 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-tri= vial confiscatory surface.
> > > >=20
> > > > One of the goal of BIP54 is to address objections t= o 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.
> > > >=20
> > > > Various approaches of limiting the size of spent sc= riptPubKeys were discussed, in forms that would
> > > > mitigate the confiscatory surface, to adopt in addi= tion to (what eventually became) the BIP54 sigops
> > > > limit. However i decided against including this add= itional measure in BIP54 because:
> > > > - of the inherent complexity of the discussed schem= es, which would make it hard to reason about
> > > > constructing transactions spending legacy inputs, a= nd equally hard to evaluate the reduction of
> > > > the confiscatory surface;
> > > > - more importantly, there is steep diminishing retu= rns to piling on more mitigations. The BIP54
> > > > limit on its own prevents an externally-motivated a= ttacker from *unevenly* stalling the network
> > > > for dozens of minutes, and a revenue-maximizing min= er from regularly stalling its competitions
> > > > for dozens of seconds, at a minimized cost in confi= scatory 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 redu= ce those numbers, but it's less clear what the tangible
> > > > gains would be.
> > > >=20
> > > > Furthermore, it's always possible to get the bi= ggest bang for our buck in a first step and going the
> > > > extra mile in a later, more controversial, soft for= k. I previously floated the idea of a "cleanup
> > > > v2" in private discussions, and i think beside= s a reduction of the maximum scriptPubKey size it
> > > > should feature a consensus-enforced maximum transac= tion size for the reasons stated here:
> > > > h= ttps://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 documented somewhere.
> > > >=20
> > > > I'm trying to not go into much details regardin= g which mitigations were considered in designing
> > > > BIP54, because they are tightly related to the desi= gn of various DoS blocks. But i'm always happy to
> > > > rehash the decisions made there and (re-)consider a= lternative approaches on the semi-private Delving
> > > > thread [0] dedicated to this purpose. Feel free to = ping me to get access if i know you.
> > > >=20
> > > > Best,
> > > > Antoine Poinsot
> > > >=20
> > > > [0]: https= ://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > On Friday, October 17th, 2025 at 1:12 PM, Brandon B= lack <fre...@reardencode.com> wrote:
> > > >=20
> > > > >
> > > > >
> > > > > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Ma= xwell 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 issu= es.
> > > > >
> > > > >
> > > > > I believe this limit would also stop most (all= ?) of PortlandHODL's
> > > > > DoSblocks without having to make some of the o= ther changes in GCC. I
> > > > > think it's worthwhile to compare this appr= oach to those proposed by
> > > > > Antoine in solving these DoS vectors.
> > > > >
> > > > > Best,
> > > > >
> > > > > --Brandon
> > > > >
> > > > > --
> > > > > You received this message because you are subs= cribed to the Google Groups "Bitcoin Development Mailing List" gr= oup.
> > > > > To unsubscribe from this group and stop receiv= ing emails from it, send an email to bitcoindev+...@goo= glegroups.com.
> > > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aP= J3w6bEoaye3WJ6%40console.
> > >=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 email to bitcoindev+...@googlegroups.= com.
> >=20
> > > To view this discussion visit https://groups.google.com/d= /msgid/bitcoindev/5135a031-a94e-49b9-ab31-a1eb48875ff2n%40googlegroups.com<= /a>.
>=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 email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/78475572-3e52-44e4-8116-8f1a917995a4n%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 bitcoindev+...@googlegroups.com.
To view this discussion visit htt= ps://groups.google.com/d/msgid/bitcoindev/f4755fb6-b031-4c60-b304-f123ba2ff= 473n%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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/c208e054-b85a-4a5c-9193-c28ef0d225c5n%40googlegrou= ps.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/CAAS2fgSNtO6kpfm0XaBCufyExjJnxg87ttLGUgpUU9pkemZTig%40mail.g= mail.com.
--00000000000053c7c806425a2f4a--