From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 11:14:34 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEXAM-00011T-Qb for bitcoindev@gnusha.org; Thu, 30 Oct 2025 11:14:33 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-65681fd25b0sf1732751eaf.3 for ; Thu, 30 Oct 2025 11:14:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761848063; cv=pass; d=google.com; s=arc-20240605; b=MtR9RD+5EUQ4lnqVKxwDQeVk+11XkptG6Ga9N8cozgilHY3hsvLtCk4bHe+y21EI4l D9oEGaiOYTbEiJY7+0HHCMyf431YZh8+0YczzLUL9x3Rq/vjbThwcgEMdXZjDeAUSWn1 kgIQBc5Z8dhL7qhl+Fp1hN+NDEyrM+25jcR0Fd57zctW1olorRTuB9HCDsHPYQxVqU/s V64790cVK0FnFEGw4grQmp7ueoMP4yLszUWyR9bODTt1sBIjnDtbqzvkAqR05Ta6+16S YKpRj/wGUUd81KBvTBi8Jr20JBWGr9hiGFCXH2MUt2aCkiPaAFYPCqzGXE0vY+Ua1EKp AawA== 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=JK4MQA4Q9jE9jRX1xVWtfWzEMLDy/qOfhLnP2SYAYgk=; fh=G+2IOvdwt7cao6Rttu16YJYrvH5deqm6MKIXJyJJktg=; b=hWPtvq7uc/pxg5N/iO7ijXUqlDhgU77wUkER5njlD+LWbs2zRgzZtVZZZ0p3zXpsSE AxIkShhhi9S+77dNNYQ/lF1PsKG17k8xb72wjnupsGARuJd03VNzClEMVhfHYs9RrEp4 PI3jCB07iSeOqB10YMGtVhoq0TI18zJU0LD654xmRp32erE7DwilPNW+ywrYfrgOriZt ZAnvyT8VYcZ81wmiTzt917pXwvm3woNHt6AqvN4DHoF8LpS3od67ILNFGkfyIbHjOs9C D51lhvWj2f9OTm94Z8jUQNkc/nN2qqRPlpDeTybSkRVcyGDoQbCv0wka9MYF3E0yK536 +cKw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CbixE5nc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62f 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=1761848063; x=1762452863; 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=JK4MQA4Q9jE9jRX1xVWtfWzEMLDy/qOfhLnP2SYAYgk=; b=wF4b51ugGZiPf1+y7v0gwsUYDKXUMrd2n3P2v7vKBXOSJq8Eg5t/kvzWmk5+lWZ1bP 3KObJHTHU2rE4oMUlQbinX/h/oBOvZYUta7RdWTlU5DEVP/cdueaRanuqycQMCqQUtG+ 0uAonrRFoUzYmvwvclwHNfB+gND+NhF6r05/1+mFtGgcqE2PIZH51MTdRsbOZD+cXmhC ZZVuQkRtz6bvmYExgGgs5eAZtIOKyw+2sKjjZFS3baRi+Beshx6dlb3GfmGIEU1VMAuQ xEhqs4VQwgzbnsiBh7Mmc0ao2QscMIQ0VgdbRaesStQs5uqmlsgNcOPYXs2UcI640n52 M5RA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761848063; x=1762452863; 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=JK4MQA4Q9jE9jRX1xVWtfWzEMLDy/qOfhLnP2SYAYgk=; b=F8d2OdPXL+ZnRCuFU5Q2QluDOgvJBeTCHt9Nl1SxL1oQAFXfYHIKUOwiglaD2Ifdte O/3XwtiECJxk0foxB/1kKr7X46PCj+bJklhTXnaGAIwWrxBKVbhXYbkknh/KFOm535Nc Bj9nl69Qa47JYMZf0swL3XUinSVC7WKknGVnlIeSPUDsNjjPs67bDIABh9/HNI8d9PJu bhxMfuKGW1zPOjQUFASw+CzV19dc0WLJAmmGSTIJS6LDTh1/PosKcqRw4s3e06ZhW8xh yTDRUy4Q+OBj55dPJzUriYSSlMd9OCSo2v7S79M4uYuxcjOH/E6+LYYdAwAafcFk2qW5 Whyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761848063; x=1762452863; 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=JK4MQA4Q9jE9jRX1xVWtfWzEMLDy/qOfhLnP2SYAYgk=; b=MLTy+e+VNGTgwV5SVMZC2NX6om+PyxvPU82buZocCblFhuZ8seQH9pz506mvYP6Rbw yZMwADtfyQrzGONvO/hidYgQdyU2aBxFKwIqN+tH6iUztw3rt0e9f8e2gEVizH5yQO3X 49PuD/kkSeE0byXxMoPqTYwBAg6W9GjFkhhU69en4VYIcmtsAdEd/OiPJGvc2rCXiPlo EX7Wu1n3zfRSMne91Mxyd7lD7exfjICqTd6wnhkI0c1nEh9Hq3Wh3ukdJvkiZQhZPb91 F0fDrUWueURkZahw0c9+CAd/dwghVLoijzw8/InKa6I46Co49QLXIBTA8Br1BsEY69sK kTog== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWCJae5gMPfArAH3L5J84y6vd7yCvT0RPnSW4XHLcCTnL2vwNBAqji8Fd7d6HSD49QnsQwkqpr0WZ57@gnusha.org X-Gm-Message-State: AOJu0YwXjXiq3eZ8fCvVXdnwS8Ewn/eeLSov0ZBfT4X8ITPqJmz2MhSS rvlvuUBjPskcwMbULzNBP1KDTCZDFVUuU16nDZfrlm8yWUsiWQPJK+sD X-Google-Smtp-Source: AGHT+IFfox7ClDBDwAbleTcWs19ymfGdvfUQfWMvhtcyyMgf2RgoGNoZxZYltLN3m03LJ0ZJZnALIQ== X-Received: by 2002:a05:6820:81d2:b0:656:8295:69b9 with SMTP id 006d021491bc7-6568a6943eamr319912eaf.7.1761848063265; Thu, 30 Oct 2025 11:14:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZXssE22wUfIj4ua8xhjXBxPNC1o8Zkrn/aH7jJSIiq2Q==" Received: by 2002:a05:6820:4585:b0:654:fada:e361 with SMTP id 006d021491bc7-656823c1c10ls402175eaf.0.-pod-prod-03-us; Thu, 30 Oct 2025 11:14:19 -0700 (PDT) X-Received: by 2002:a05:6808:680a:b0:44d:bbac:a001 with SMTP id 5614622812f47-44f95fac458mr302251b6e.56.1761848059161; Thu, 30 Oct 2025 11:14:19 -0700 (PDT) Received: by 2002:a05:690c:6d91:b0:780:f7eb:fdf with SMTP id 00721157ae682-786295b01cdms7b3; Thu, 30 Oct 2025 10:40:24 -0700 (PDT) X-Received: by 2002:a05:690c:6d8a:b0:784:8e68:b507 with SMTP id 00721157ae682-78648407552mr3384797b3.12.1761846023725; Thu, 30 Oct 2025 10:40:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761846023; cv=none; d=google.com; s=arc-20240605; b=QifOP7P+UjIKxDH0ku8Cc4ahYz6GDlCda4R3Ia1UyEai4sopor1sE1JCv3DKzzmm3e Qz2VBRcp6tJp089f3TmAmOYkj8n1UDgtrjVbkJ0Z8uIRp1Zb6FzgP8pgvu0PyCxxLESD rKayBvfbxHnxdV7/WWZ9D8/c1qcKQYqV0LYmAbYMHPClp1MMVIhfzbEogne268cyebAu tVhERK5TvfGHzuFZh1NdlKSGtz9vcetn/hfD32T+WNqkuiOEXzY8o5H+Vrxnb+eL+GuC YX2YnsbLzjLotH1yTQlAtJZFX0yX7wsLblOjhnGKHPk9hbjkHy7hcyjOOtpW56z39P9N Ly3w== 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=tj339OvZcoaXPh4UeHplSOZNdvo9R8gx9oICm4I47uY=; fh=roize3/Nsv4Auw8Ccya15pk+/cIq2QN3L3Gj0Di505I=; b=ZVN36I4BKLooiNGtU2V7gDcyyLYkBt0mgTibB6Ih+p1ztSBc9X0Pw0UW+C7G+OP2G5 z24iEF1bqIYus1z2LpX1uj/G+bnMPzZ886D4ZEy3Z+EJBoDYiG6c0w+A11K1ZeZPAxE5 FASJXfyLvGH4w4PeG7wmafbxBzctJWm1uQBBTOwAbcxVedQmdmITOAh7ZNpb9ZfTbYRb S7BQcxeEMrRgCQ7hT5gxZcZvEaMNxEd5uOqD1JrgHDs2z6FVxXN/yyx1w5kH2NHTdf1B zFTm6X7bPoa2nLhqtsGHpbH/jkiquTPWwUeWT2fT7HBre5oYh/i5aANirLiyeCZLSZ1y 3suw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CbixE5nc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62f 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-pl1-x62f.google.com (mail-pl1-x62f.google.com. [2607:f8b0:4864:20::62f]) by gmr-mx.google.com with ESMTPS id 00721157ae682-785ee297751si8535037b3.1.2025.10.30.10.40.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Oct 2025 10:40:23 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62f as permitted sender) client-ip=2607:f8b0:4864:20::62f; Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-28e7cd6dbc0so17098125ad.0 for ; Thu, 30 Oct 2025 10:40:23 -0700 (PDT) X-Gm-Gg: ASbGncsU79l5kfTcmUvRzu08imAVmsDkBW+XA41Qw0WJNC5S840RFiflhWp2NrKNEvX zpu+Y6lPgI9hz6+eqLiJAT07KEUtzeT7RFD4/32iNEC8VCcJ6knKc4sFv/WkMQi6oIonaaibxhc J3R4geU7KQJX6srMzOHIi3t+ic94bp3GEiaGm8kKcuScHNx6OetYcrUmJdHje5sn/3QptMt6aQs iZCuNGIV/uHJCXX+Flg+WvwsLNMbHWoydghJOup9VGLQwZk5Yb7PuhgXcnP+4MI72w/N9V+Q4QC EwWRzXTXKoGnOLHdZhUpiNIDMvziu4mLjQhe2IqYdz6t8WOL4QU= X-Received: by 2002:a17:902:d2cd:b0:290:c0b1:edb8 with SMTP id d9443c01a7336-2951a4d218fmr7866255ad.40.1761846022303; Thu, 30 Oct 2025 10:40:22 -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> <09d0aa74-1305-45bd-8da9-03d1506f5784n@googlegroups.com> In-Reply-To: <09d0aa74-1305-45bd-8da9-03d1506f5784n@googlegroups.com> From: Greg Maxwell Date: Thu, 30 Oct 2025 17:40:09 +0000 X-Gm-Features: AWmQ_bmxq2KGV8eGNZImf1B8TAV4EAXCEnvbZqg7jK0ZuhIfAxuhtyHWMTGCxzU Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Bitcoin Error Log Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000004efaa8064263bedb" 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=CbixE5nc; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62f 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 (/) --0000000000004efaa8064263bedb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fullrbf change in core only occurred *after* substantive miners had already made the change, and core updated largely with regret to reflect reality and not contribute to compound harm. This was clear enough from even a few minutes read on the history, so I'm unclear as to why you're suggesting otherwise here. On Thu, Oct 30, 2025 at 11:39=E2=80=AFAM Bitcoin Error Log < bitcoinerrorlog@gmail.com> wrote: > Greg, > > One correction. Bitcoin has significantly restricted a proven use case > with policy in the past. Maybe you won't think this qualifies, but it > happened while you were away so I am curious about your assessment. > > During the change to mempoolfullrbf policy, I, with support from the > original author of the change, and with support of multiple Core devs, an= d > with the support of multiple businesses providing data on how they provid= ed > zero-conf as a service to users via risk management, tried to stop Bitcoi= n > from killing first-seen policy, which had been stable for all of the > history of Bitcoin. The change was at least clearly demonstrated as > controversial, and lacking real consensus. > > I'm happy to admit that no policy is enforceable, and that zero-conf was > "never safe", but we had a system that worked and made Bitcoin more usefu= l > to people that used it that way. The businesses simply monitored for > doublespends, imposed exposure limits per block, and gated actual deliver= y > separately from checkout UX. It worked and now it does not and the only > reason was a policy change. > > The problem with claiming that policy is not a means of change, is that > you must also admit the lack of need for any RBF flags at all, or for > arguing about data spam relay, or for any wide policy to be a concern of > Bitcoin Core at all. (particularly when speculatively / subjectively > applied) . > > Thank you, and sorry for the side topic. > > ~John > > > On Thursday, October 30, 2025 at 6:40:10=E2=80=AFAM UTC Greg Maxwell wrot= e: > > 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 somethi= ng > 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 ha= ve > 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 i= s > that you can put your keys in a time capsule in the foundation of your ho= me > 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 actio= n, > 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 th= e > 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. Suc= h > 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, a= nd > 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 consisting > of primordial coins that aren't subject to the new rules... sounds like t= he > sort of thing that NFT degens would absolutely love. That might not be a= n > issue *generally* for some change with confiscation risk, but for a chang= e > that is specifically intended to lobotomize bitcoin to make it less usefu= l > 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-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 issues. Just size limiting outputs likely doesn't harm any > interests or usages-- and so probably could be viable if the confiscation > issue was addressed, but it also doesn't stick it to people transacting i= n > 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 m= ay > 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 generall= y > reusable primitive that could make other upgrades more feasible 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-prunable > 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 alon= e > 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 wr= ote: > > > 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 claim > they were rugged by the devs. > > BR, > moonsettler > > On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL > wrote: > > > Hey, > > > > First, thank you to everyone who responded, and please continue to do > 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 th= e > 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 publication. > > - Timeout / Sunset logic is compelling > > - The (n) value of acceptable needed bytes is contentious with the lowe= r > 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 an= y > > > 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 redemption > limits on prevouts seems to just be a coverage issue where you can make t= he > 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_RETU= RN > restriction and instead just use another op_code, this also do not hit on > some of the most important factors such as DoS mitigation and legacy scri= pt > 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. Alleviating > 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 transacti= on > programming possibilities is still early. If you don't like this example,= I > can give you others (probably). > > > > Agreed and this also falls into the reasoning for deciding to utilize > 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 away > 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 likely > 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 used > > 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 mind, > 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, the= n > > 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 ban > large scripts even in the P2SH wrapper which undermines Bitcoin's ability > to be an effectively programmable money. > > > > This has nothing to do with the witness size or even the P2SH wrapper > > > > Casey Rodarmor: > > > I think that "Bitcoin could need it in the future?" might be a good > 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 th= e > proof > > determined whether or not the transaction is valid, and thus require th= e > > 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 thing= s > inputs with ScriptPubkey redemptions + heavy op_codes that require unique > 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 > operations with the current (n) limit included per input. > > > > > 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. > > > > Some notes is I would actually go as far as to say the confiscation ris= k > is higher with the TX limit proposed in BIP54 as we actually have proof o= f > redemption of TXs that break that rule and the input set to do this alrea= dy > exists on-chain no need to even wonder about the whole presigned. > bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 > > > > Please let me know if I am incorrect on any of this. > > > > > Furthermore, it's always possible to get the biggest bang for our buc= k > 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 thi= s > is response is from the initial view of your response and could be > 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 in > 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 Maxwell = wrote: > > > > > Limits on block construction that cross transactions make it harder t= o > accurately estimate fees and greatly complicate optimal block > construction-- the latter being important because smarter and more comput= er > 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 becau= se > the higher embedding cost may make some of them use more transactions. Th= e > competition for these buckets by other traffic could make it effectively = 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 even a= t > 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 ther= e > 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 the > 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 the > 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 scriptpubke= y > and L a limiting > > > > threshold for the number of T occurences during the period P. Beyon= d > 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 of > 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 bac= k > 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 Poinsot = a > =C3=A9crit : > > > > > > > > > Hi, > > > > > > > > > > This approach was discussed last year when evaluating the best wa= y > 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 measur= e > in BIP54 because: > > > > > - of the inherent complexity of the discussed schemes, which woul= d > make it hard to reason about > > > > > constructing transactions spending legacy inputs, and equally har= d > to evaluate the reduction of > > > > > the confiscatory surface; > > > > > - more importantly, there is steep diminishing returns to piling > on more mitigations. The BIP54 > > > > > limit on its own prevents an externally-motivated attacker from > *unevenly* stalling the network > > > > > for dozens of minutes, and a revenue-maximizing miner from > regularly stalling its competitions > > > > > for dozens of seconds, at a minimized cost in confiscatory > surface. Additional mitigations reduce > > > > > the worst case validation time by a smaller factor at a higher > cost in terms of confiscatory > > > > > surface. It "feels right" to further reduce those numbers, but > it's less clear what the tangible > > > > > gains would be. > > > > > > > > > > Furthermore, it's always possible to get the biggest bang for our > buck in a first step and going the > > > > > extra mile in a later, more controversial, soft fork. I previousl= y > floated the idea of a "cleanup > > > > > v2" in private discussions, and i think besides a reduction of th= e > 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/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 mitigation= s > 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 and n= o > reason 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 propose= d > 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+...@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+...@googlegroups.com. > > > > > > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/5135a031-a94e-49b9-ab31-a1eb= 48875ff2n%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-8f1a= 917995a4n%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-f123= ba2ff473n%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/c208e054-b85a-4a5c-9193-c28e= f0d225c5n%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/09d0aa74-1305-45bd-8da9-03d1= 506f5784n%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/= CAAS2fgTKf4wyfnhep7LsmAEad7HRsg5S5VguX9rDrdMUrkkrXQ%40mail.gmail.com. --0000000000004efaa8064263bedb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fullrbf change in core only occurred *after* substant= ive miners had already made the change, and core updated largely with regre= t to reflect reality and not contribute to compound harm.=C2=A0 This was cl= ear enough from even a few minutes read on the history, so I'm unclear = as to why you're suggesting otherwise here.



On Thu, Oct 30, 2025 at 11:39=E2=80=AFAM Bitcoin Error L= og <bitcoinerrorlog@gmail.c= om> wrote:
On Thursday, October 30, 2025 at 6:40:10=E2=80=AFAM UTC Greg Maxw= ell wrote:
Prior= softforks have stuck to using the more explicit "forward compatibilit= y" mechanisms, so -- e.g. if you use OP_NOP3 or a higher transaction v= ersion number or whatever that had no purpose (and would literally=C2=A0do = nothing), saw ~no use, and was non-standard, or scripts that just anyone co= uld 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=C2=A0was enough to accep= tably mitigate the risk.=C2=A0 Tapscript was specifically designed to make = upgrades even safer and easier by making it so that the mere presence of an= y forward compat opcode (OP_SUCCESSn) makes the whole script insecure until= that opcode is in use.=C2=A0

The proposal to limi= t 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 forwar= d compat mechanism, people running into a 520 limit could have been pretty = boring (and I see my own watching wallets have some scriptpubkeys beyond th= at 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 would= n't confiscate some of my own funds--- and it's a pain in the rear = to check, having to bring offline stuff online, etc).

<= div>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 t= heir 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 time capsule in the foundatio= n of your home and trust that they're still going to be there and you&#= 39;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.
<= br>
I don't even think bitcoin has ever policy restricted som= ething that was in active use, much less softforked=C2=A0out something like= that.=C2=A0 I wouldn't say it was impossible but I think on the balanc= e it would favor a notice period so that any reasonable person could have t= aken notice, taken action, or at least spoke up.=C2=A0 But since there is n= o requirement to monitor and that's part of bitcoin's value prop th= e amount of time to consider reasonable ought to be quite long.=C2=A0 Which= also is at odds with the emergency measures position being taken by propon= ents of such changes.

(which also, I think are jus= t entirely unjustified, even if you accept the worst version of their narra= tive with the historical chain being made _illegal_, one could simply produ= ce node software that starts from a well known embedded utxo snapshot and d= oesn't process historical blocks.=C2=A0 =C2=A0Such a thing would be in = principle a reduction in the security model, but balances against the pract= ical and realistic impact of potentially confiscating coins I think it look= s pretty fine by comparison.=C2=A0 It would also be fully consensus compati= ble, assuming no reorg below that point, and can be done right now by anyon= e who cares in a totally permissionless and coercion free manner)



On Thu= , Oct 30, 2025 at 5:13=E2=80=AFAM Michael Tidwell <m= tidw...@gmail.com> wrote:

Greg,

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

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 Maxwell wrote:
"A few bytes" might be on the order= of forever 10% increase in the UTXO set size, plus a full from-network res= ync 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 S= uch a portion of the=C2=A0existing utxo size is not from outputs over 520 b= ytes in size, so as a scheme for utxo set size reduction the addition of MH= T tracking would probably make it a failure.

Also = some risk of creating some new scarce asset class, txouts consisting of pri= mordial=C2=A0coins that aren't subject to the new rules... sounds like = the sort of thing that NFT degens would absolutely love.=C2=A0 That might n= ot be an issue *generally* for some change with confiscation=C2=A0risk, but= for a change that is specifically intended to lobotomize bitcoin to make i= t less useful 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.=C2= =A0 Also luke-jr and crew has moved on to actually propose even more invasi= ve 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 confiscation issue was addressed, but it also doesn't stick it = to people transacting in ways the priests of ocean mining dislike.=C2=A0

>=C2=A0I believe you'r= e 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 respondin= g to different economics which may be less legible to your analysis.=C2=A0 = In particular, NFT degens prefer the high cost of transactions as a thing t= hat makes their tokens scarce and gives them value.=C2=A0 -- 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 <<= a rel=3D"nofollow">mtidw...@gmail.com> 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 feasible that also h= ave the same strict confiscation risk profile.
IIUC, the major pain is, = 1 big reindex cost + a few bytes per utxo?

Poelstra,

> I d= on't think this is a great idea -- it would be technically hard to
i= mplement 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 tab= le? In terms of the hypothetical presigned transactions that may exist usin= g P2MS, is this a hard enough reason to require a MRH idea?

Greg,
> So, paradoxically this limit might increase the amount of non-pru= nable data

I believe you're pointing out the idea of non economi= cally-rational spammers? We already see actors ignoring cheaper witness ins= cription 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 d= iscussion. (like a SF to add weight to outputs). Anywho, this point alone d= oesn't seem sufficient to add as a clear negative reason for someone op= posed to the proposal.

Thanks,
Tidwell
On W= ednesday, 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 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.

--
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.

--
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/09d0aa74-1305-45bd-8da9-03d1506f5784n%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/CAAS2fgTKf4wyfnhep7LsmAEad7HRsg5S5VguX9rDrdMUrkkrXQ%40mail.g= mail.com.
--0000000000004efaa8064263bedb--