From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 15:29:02 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.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 1vEb8d-0003Xf-Nw for bitcoindev@gnusha.org; Thu, 30 Oct 2025 15:29:02 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-651e9210231sf2457004eaf.3 for ; Thu, 30 Oct 2025 15:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761863333; x=1762468133; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=AahbKA8168n039X7DOkXujQkFfdwb6Ko2IJMzkPDOx4=; b=flJUz5CQP5RLvXQQk8Ruo9JT7HuQU9mL8PXL7R55H7jQ7a4hb9mimUwMSmXj2hDdZw cpjSj5JfLhDB/QqCO2ztcucUbHrhwT4dIkHk/64Jq4lCI1sFxIgCbiOlLw1+GCauZzTL BXFJwXEeNQr3VPX9TG2Y1lt6eOz8WgwKuVC8MhnkvQ1K2z/GOXCLt+U4k+J+59u11KEO VbDG2M60w0/01gu7yn7PpNTJB87cnWLgvZwVWbvE1jxecoxYi4s176KgjqmmsA8rkqRK pbQV/G7roc8ezQLqNQCaA5czAMGWtrZAIV2ICIQKpQNzSoPh1444IFBNoULHEFdtg7uS ypsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761863333; x=1762468133; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=AahbKA8168n039X7DOkXujQkFfdwb6Ko2IJMzkPDOx4=; b=g9WQX8mYdyNHqdQz5UZKBkVIBbszW9qYybyif55Zl945WggS7Xkylp7jzv8irTAzu5 iST8lutFjSEw3u1bE8bD9HbRAQkuqI5QogxnFY4IlHOIpQq0P9gBH1QGMR0n6iQzjBfB lCTwlFhWB6g6sKO01Yjg6dYjlcrTv5+j0Rf8x6pxXd3Iwp+uAq7vgc8NVb0thGQX3MZA cE+ECJGG5yl860yAgfKyrmmppoUEA6mn91ek5R1Yv9r9onm7+fcrlCEh61UTBxJAD9+U DB+OiEYiwWq3vMJCVLgSJ4gVMzn37caBYIRoNUJmcQEzwiafnnaAlDZbJqWYe1f4oRmA Hx2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761863333; x=1762468133; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=AahbKA8168n039X7DOkXujQkFfdwb6Ko2IJMzkPDOx4=; b=PuX7qs+LQzSMXWUbcggRiTOzdjJ/iyzfncOGsxNuWIAID9ettwbXeIij/TZ0VOsy4i 2zLRTzUP/P8AR5Bz4sJb0vthqZkFwb1+Ofl9QA8Fp7Y4/cfEmlu4v20UYUihVCo7e2mt LF/m7frfAtzA+eXMnUAXfrXzZna65kFVV47facjIu9VaVb63bEuArxrgPaxhHc8QqWIz l/Bw58hH6RdoNFiKUfqULnisL3HY/GhG8dn+iGi4hUlX6vMAPCS2tiMQ04BhQxSMJGGk IkN8gLqsoGtwfjdo4wWPUQIhqPuOSG9jWSRL6HuoC4qDrnz4xiGAHMtctO85hSMeI3Ss d4aA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWS0O5jgcQkIsYw9QI/2qSHAmo/d5wZCZ1b6soluTz61stuBT7rGyE9w8YlVDwoU9XKREJMF9qLb5Lv@gnusha.org X-Gm-Message-State: AOJu0YwbRD2pTyfaSPMAlVPKYeob4hMSeRxO+aNAqkU8uWprX/FIWPxx 8RLS70ujsIN6N7lIJNZAzX9LYq5OultUlwooysGPW1xIqipi6PQ9orOt X-Google-Smtp-Source: AGHT+IGJkiteUYbfllfGP/0Zo77PjClWObdroL72n9Pky4m0xL5XF6RxR5xwf1Vg5ga8SNyCY0h3lQ== X-Received: by 2002:a05:6820:2008:b0:656:6e2f:628c with SMTP id 006d021491bc7-6568a197d92mr668438eaf.0.1761863333308; Thu, 30 Oct 2025 15:28:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a5igshSNwlYXnKTc9mfDigh5iwsJNe6Y+uHbQdpyh5rQ==" Received: by 2002:a4a:a746:0:b0:656:77c7:8eb7 with SMTP id 006d021491bc7-656824972ebls804114eaf.1.-pod-prod-01-us; Thu, 30 Oct 2025 15:28:48 -0700 (PDT) X-Received: by 2002:a05:6808:189e:b0:43f:23d1:cbb1 with SMTP id 5614622812f47-44f95e230fcmr582321b6e.8.1761863328659; Thu, 30 Oct 2025 15:28:48 -0700 (PDT) Received: by 2002:a05:690c:a08c:20b0:780:f7eb:fdf with SMTP id 00721157ae682-78649a7d1c2ms7b3; Thu, 30 Oct 2025 15:15:07 -0700 (PDT) X-Received: by 2002:a05:690c:6a86:b0:750:bb77:4433 with SMTP id 00721157ae682-786483db207mr10080847b3.19.1761862507120; Thu, 30 Oct 2025 15:15:07 -0700 (PDT) Date: Thu, 30 Oct 2025 15:15:06 -0700 (PDT) From: Doctor Buzz To: Bitcoin Development Mailing List Message-Id: <73793fc0-29d8-4b79-b7bf-048e459c928bn@googlegroups.com> In-Reply-To: <793073a7-84b2-4b42-a531-e03e30f89ddcn@googlegroups.com> 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> <793073a7-84b2-4b42-a531-e03e30f89ddcn@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_616_1027043188.1761862506740" X-Original-Sender: BuzzHeavy@gmail.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 (/) ------=_Part_616_1027043188.1761862506740 Content-Type: multipart/alternative; boundary="----=_Part_617_1598208414.1761862506740" ------=_Part_617_1598208414.1761862506740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > We should reflect on the goal of minimizing UTXO set size. Would we as= =20 easily say we should minimize the number of people/entities who hold L1=20 coins, or the number of ways each person/entity can hold them? > The dire concern with UTXO set size was born with the optimization of the= =20 core bitcoin software for mining, rather than for holding and transfers, in= =20 2012. Some geniuses were involved with that change. Satoshi was not one= =20 of them. The goal isn=E2=80=99t to minimize UTXOs themselves or discourage people fr= om=20 self-custodying coins on L1. We should minimize *non-monetary UTXOs* (those= =20 created only for file storage, dusting-type tracking, etc.), not those used= =20 for transferring or holding value, as intended. Minimizing *unnecessary resource usage* that doesn=E2=80=99t serve the=20 =E2=80=9Cpeer-to-peer money=E2=80=9D purpose helps everyone that has that p= urpose as a goal: =E2=80=93 Everyday users who want to store their savings securely. =E2=80=93 Active users who want to spend and settle efficiently. =E2=80=93 Node runners who keep the network decentralized and verifiable. Bitcoin should take all steps to avoid unnecessary bloat (which has led to= =20 an extra ~30 GB/yr of immutable data storage since Feb 2023 and completely= =20 sidetracked any REAL improvements / security upgrades that should've been= =20 leading discussions). Then perhaps in just a few years, every new phone=20 could comfortably run its own fully-verifying node with no trusted servers= =20 or light-clients... enabling efficient, permissionless monetary use on both= =20 L1 or L2. Self-hosted LN nodes cannot compete with those who want file=20 storage that lasts longer than the user itself. Since you brought it up... I have a proposal to limit "bulk dust" (defined= =20 as a Tx with >=3D ~20 "Tiny" outputs && >=3D ~70% of the outputs are "Tiny= ",=20 which starts at 4096 sats but halves every epoch, beginning at block=20 1,260,000). It should be difficult to use Bitcoin for data storage and sending tiny Txs= =20 for that purpose, which has harmful effects on not just the UTXO set, but= =20 also the network... which is precisely what IsDust() and IsStandard() were= =20 designed to do. Changing consensus rules is less than ideal, but for=20 everyone that says "filters don't work", consensus changes would appear to= =20 be the only "default solutions" they'll accept, to actually identify=20 certain Txs or patterns as invalid. See: Limit "Bulk Dust" with a default filter or=20 consensus... https://groups.google.com/g/bitcoindev/c/mW_zR01joiY On Thursday, October 30, 2025 at 12:37:03=E2=80=AFPM UTC-5 Tom Harding wrot= e: > We should reflect on the goal of minimizing UTXO set size. Would we as= =20 > easily say we should minimize the number of people/entities who hold L1= =20 > coins, or the number of ways each person/entity can hold them? > > The dire concern with UTXO set size was born with the optimization of the= =20 > core bitcoin software for mining, rather than for holding and transfers, = in=20 > 2012. Some geniuses were involved with that change. Satoshi was not one= =20 > of them.=20 > > > On Wednesday, October 29, 2025 at 7:32:10=E2=80=AFPM UTC-7 Greg Maxwell w= rote: > > "A few bytes" might be on the order of forever 10% increase in the UTXO= =20 > set size, plus a full from-network resync of all pruned nodes and a full= =20 > (e.g. most of day outage) reindex of all unpruned nodes. Not=20 > insignificant but also not nothing. Such a portion of the existing utxo= =20 > size is not from outputs over 520 bytes in size, so as a scheme for utxo= =20 > set size reduction the addition of MHT tracking would probably make it a= =20 > failure. > > Also some risk of creating some new scarce asset class, txouts consisting= =20 > of primordial coins that aren't subject to the new rules... sounds like t= he=20 > sort of thing that NFT degens would absolutely love. That might not be a= n=20 > issue *generally* for some change with confiscation risk, but for a chang= e=20 > that is specifically intended to lobotomize bitcoin to make it less usefu= l=20 > to NFT degens, maybe not such a great idea. :P > > I mentioned it at all because I thought it could potentially be of some= =20 > use, I'm just more skeptical of it for the current context. Also luke-jr= =20 > and crew has moved on to actually propose even more invasive changes than= =20 > just limiting the script size, which I anticipated, and has much more=20 > significant issues. Just size limiting outputs likely doesn't harm any= =20 > interests or usages-- and so probably could be viable if the confiscation= =20 > issue was addressed, but it also doesn't stick it to people transacting i= n=20 > ways the priests of ocean mining dislike.=20 > > > I believe you're pointing out the idea of non economically-rational=20 > spammers? > > I think it's a mistake to conclude the spammers are economically=20 > irrational-- they're often just responding to different economics which m= ay=20 > be less legible to your analysis. In particular, NFT degens prefer the= =20 > high cost of transactions as a thing that makes their tokens scarce and= =20 > gives them value. -- otherwise they wouldn't be swapping for one less=20 > efficient encoding for another, they're just be using another blockchain= =20 > (perhaps their own) entirely. > > > > > On Thu, Oct 30, 2025 at 1:16=E2=80=AFAM Michael Tidwell =20 > wrote: > > > MRH tracking might make that acceptable, but comes at a high cost which= =20 > I think would clearly not be justified. > > Greg, I want to ask/challenge how bad this is, this seems like a generall= y=20 > reusable primitive that could make other upgrades more feasible that also= =20 > 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.= =20 > Is MRH tracking off the table? In terms of the hypothetical presigned=20 > transactions that may exist using P2MS, is this a hard enough reason to= =20 > require a MRH idea? > > Greg, > > > So, paradoxically this limit might increase the amount of non-prunable= =20 > data > > I believe you're pointing out the idea of non economically-rational=20 > spammers? We already see actors ignoring cheaper witness inscription=20 > methods. If spam shifts to many sub-520 fake pubkey outputs (which I=20 > believe is less harmful than stamps), that imo is a separate UTXO cost=20 > discussion. (like a SF to add weight to outputs). Anywho, this point alon= e=20 > doesn't seem sufficient to add as a clear negative reason for someone=20 > 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=20 > > Allow 10000 bytes of total scriptPubKey size in each block counting only= =20 > those outputs that are larger than x (520 as proposed).=20 > The code change is pretty minimal from the most obvious implementation of= =20 > the original rule.=20 > > That makes it technically non-confiscatory. Still non-standard, but if=20 > anyone out there so obnoxiously foot-gunned themselves, they can't claim= =20 > they were rugged by the devs.=20 > > BR,=20 > moonsettler=20 > > On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL =20 > wrote:=20 > > > Hey,=20 > >=20 > > First, thank you to everyone who responded, and please continue to do= =20 > so. There were many thought provoking responses and this did shift my=20 > perspective quite a bit from the original post, which in of itself was th= e=20 > goal to a degree.=20 > >=20 > > I am currently only going to respond to all of the current concerns.=20 > Acks; though I like them will be ignored unless new discoveries are=20 > included.=20 > >=20 > > Tl;dr (Portlands Perspective)=20 > > - Confiscation is a problem because of presigned transactions=20 > > - DoS mitigation could also occur through marking UTXOs as unspendable= =20 > if > 520 bytes, this would preserve the proof of publication.=20 > > - Timeout / Sunset logic is compelling=20 > > - The (n) value of acceptable needed bytes is contentious with the lowe= r=20 > suggested limit being 67=20 > > - Congestion control is worth a look?=20 > >=20 > > Next Step:=20 > > - Deeper discussion at the individual level: Antoine Poinsot and GCC=20 > overlap?=20 > > - Write an implementation.=20 > > - Decide to pursue BIP=20 > >=20 > > Responses=20 > >=20 > > Andrew Poelstra:=20 > > > There is a risk of confiscation of coins which have pre-signed but=20 > > > unpublished transactions spending them to new outputs with large=20 > > > scriptPubKeys. Due to long-standing standardness rules, and the=20 > presence=20 > > > of P2SH (and now P2WSH) for well over a decade, I'm skeptical that an= y=20 > > > such transactions exist.=20 > >=20 > > PortlandHODL: This is a risk that can be incurred and likely not=20 > possible to mitigate as there could be possible chains of transactions so= =20 > even when recursively iterating over a chain there is a chance that a=20 > presigned breaks this rule. Every idea I have had from block redemption= =20 > limits on prevouts seems to just be a coverage issue where you can make t= he=20 > confiscation less likely but not completely mitigated.=20 > >=20 > > Second, there are already TXs that effectively have been confiscated at= =20 > the policy level (P2SH Cleanstack violation) where the user can not find= =20 > any miner with a policy to accept these into their mempool. (3 years)=20 > >=20 > > /dev /fd0=20 > > > so it would be great if this was restricted to OP_RETURN=20 > >=20 > > PortlandHODL: I reject this completely as this would remove the UTXOset= =20 > omission for the scriptPubkey and encourage miners to subvert the OP_RETU= RN=20 > restriction and instead just use another op_code, this also do not hit on= =20 > some of the most important factors such as DoS mitigation and legacy scri= pt=20 > attack surface reduction.=20 > >=20 > > Peter Todd=20 > > > NACK ...=20 > >=20 > > PortlandHODL: You NACK'd for the same reasons that I stated in my OP,= =20 > without including any additional context or reasoning.=20 > >=20 > > jeremy=20 > > > I think that this type of rule is OK if we do it as a "sunsetting"=20 > restriction -- e.g. a soft fork active for the next N blocks (N =3D e.g. = 2=20 > years, 5 years, 10 years).=20 > >=20 > > If action is taken, this is the most reasonable approach. Alleviating= =20 > confiscatory concerns through deferral.=20 > >=20 > > > You can argue against this example probably, but it is worth=20 > considering that absence of evidence of use is not evidence of absence of= =20 > use and I myself feel that overall our understanding of Bitcoin transacti= on=20 > programming possibilities is still early. If you don't like this example,= I=20 > can give you others (probably).=20 > >=20 > > Agreed and this also falls into the reasoning for deciding to utilize= =20 > point 1 in your response. My thoughts on this would be along the lines of= =20 > proof of publication as this change only has the effect of stripping away= =20 > the executable portion of a script between 521 and 10_000 bytes or the=20 > published data portion if > 10_000 bytes which the same data could likely= =20 > be published in chunked segments using outpoints.=20 > >=20 > > Andrew Poelstra:=20 > > > Aside from proof-of-publication (i.e. data storage directly in the=20 > UTXO=20 > > > set) there is no usage of script which can't be equally (or better)= =20 > > > accomplished by using a Segwit v0 or Taproot script.=20 > >=20 > > This sums up the majority of future usecase concern=20 > >=20 > > Anthony Towns:=20 > > > (If you restricted the change to only applying to scripts that used= =20 > > non-push operators, that would probably still provide upgrade=20 > flexibility=20 > > while also preventing potential script abuses. But it wouldn't do=20 > anything=20 > > to prevent publishing data)=20 > >=20 > > Could this not be done as segments in multiple outpoints using a=20 > coordination outpoint? I fail to see why publication proof must be in a= =20 > single chunk. This does though however bring another alternative to mind,= =20 > just making these outpoints unspendable but not invalidate the block=20 > through inclusion...=20 > >=20 > > > As far as the "but contiguous data will be regulated more strictly"= =20 > > argument goes; I don't think "your honour, my offensive content has=20 > > strings of 4d0802 every 520 bytes=20 > >=20 > > Correct, this was never meant to resolve this issue.=20 > >=20 > > Luke Dashjr:=20 > > > If we're going this route, we should just close all the gaps for the= =20 > immediate future:=20 > >=20 > > To put it nicely, this is completely beyond the scope of what is being= =20 > proposed.=20 > >=20 > > Guus Ellenkamp:=20 > > > If there are really so few OP_RETURN outputs more than 144 bytes, the= n=20 > > why increase the limit if that change is so controversial? It seems=20 > > people who want to use a larger OP_RETURN size do it anyway, even with= =20 > > the current default limits.=20 > >=20 > > Completely off topic and irrelevant=20 > >=20 > > Greg Tonoski:=20 > > > Limiting the maximum size of the scriptPubKey of a transaction to 67= =20 > bytes.=20 > >=20 > > This leave no room to deal with broken hashing algorithms and very=20 > little future upgradability for hooks. The rest of these points should be= =20 > merged with Lukes response and either hijack my thread or start a new one= =20 > with the increased scope, any approach I take will only be related to the= =20 > ScriptPubkey=20 > >=20 > > Keagan McClelland:=20 > > > Hard NACK on capping the witness size as that would effectively ban= =20 > large scripts even in the P2SH wrapper which undermines Bitcoin's ability= =20 > to be an effectively programmable money.=20 > >=20 > > This has nothing to do with the witness size or even the P2SH wrapper= =20 > >=20 > > Casey Rodarmor:=20 > > > I think that "Bitcoin could need it in the future?" might be a good= =20 > enough=20 > > reason not to do this.=20 > >=20 > > > Script pubkeys are the only variable-length transaction fields which= =20 > can be=20 > > covered by input signatures, which might make them useful for future=20 > soft=20 > > forks. I can imagine confidential asset schemes or post-quantum coin=20 > recovery=20 > > schemes requiring large proofs in the outputs, where the validity of th= e=20 > proof=20 > > determined whether or not the transaction is valid, and thus require th= e=20 > > proofs to be in the outputs, and not just a hash commitment.=20 > >=20 > > Would the ability to publish the data alone be enough? Example make the= =20 > output unspendable but allow for the existence of the bytes to be covered= =20 > through the signature?=20 > >=20 > >=20 > > Antoine Poinsot:=20 > > > Limiting the size of created scriptPubKeys is not a sufficient=20 > mitigation on its own=20 > > I fail to see how this would not be sufficient? To DoS you need 2 thing= s=20 > inputs with ScriptPubkey redemptions + heavy op_codes that require unique= =20 > checks. Example DUPing stack element again and again doesn't work. This= =20 > then leads to the next part is you could get up to unique complex=20 > operations with the current (n) limit included per input.=20 > >=20 > > > One of the goal of BIP54 is to address objections to Matt's earlier= =20 > proposal, notably the (in my=20 > > opinion reasonable) confiscation concerns voiced by Russell O'Connor.= =20 > Limiting the size of=20 > > scriptPubKeys would in this regard be moving in the opposite direction.= =20 > >=20 > > Some notes is I would actually go as far as to say the confiscation ris= k=20 > is higher with the TX limit proposed in BIP54 as we actually have proof o= f=20 > redemption of TXs that break that rule and the input set to do this alrea= dy=20 > exists on-chain no need to even wonder about the whole presigned.=20 > bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08=20 > >=20 > > Please let me know if I am incorrect on any of this.=20 > >=20 > > > Furthermore, it's always possible to get the biggest bang for our buc= k=20 > in a first step=20 > >=20 > > Agreed on bang for the buck regarding DoS.=20 > >=20 > > My final point here would be that I would like to discuss more, and thi= s=20 > is response is from the initial view of your response and could be=20 > incomplete or incorrect, This is just my in the moment response.=20 > >=20 > > Antoine Riard:=20 > > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in= =20 > favor of prioritizing=20 > > a timewarp fix and limiting dosy spends by old redeem scripts=20 > >=20 > > The idea of congestion control is interesting, but this solution should= =20 > significantly reduce the total DoS severity of known vectors.=20 > >=20 > > On Saturday, October 18, 2025 at 2:25:18=E2=80=AFAM UTC-7 Greg Maxwell = wrote:=20 > >=20 > > > Limits on block construction that cross transactions make it harder t= o=20 > accurately estimate fees and greatly complicate optimal block=20 > construction-- the latter being important because smarter and more comput= er=20 > powered mining code generating higher profits is a pro centralization=20 > factor.=20 > > >=20 > > > In terms of effectiveness the "spam" will just make itself=20 > indistinguishable from the most common transaction traffic from the=20 > perspective of such metrics-- and might well drive up "spam" levels becau= se=20 > the higher embedding cost may make some of them use more transactions. Th= e=20 > competition for these buckets by other traffic could make it effectively = a=20 > block size reduction even against very boring ordinary transactions. ...= =20 > which is probably not what most people want.=20 > > >=20 > > > I think it's important to keep in mind that bitcoin fee levels even a= t=20 > 0.1s/vb are far beyond what other hosting services and other blockchains= =20 > cost-- so anyone still embedding data in bitcoin *really* want to be ther= e=20 > for some reason and aren't too fee sensitive or else they'd already be=20 > using something else... some are even in favor of higher costs since the= =20 > high fees are what create the scarcity needed for their seigniorage.=20 > > >=20 > > > But yeah I think your comments on priorities are correct.=20 > > >=20 > > >=20 > > >=20 > > > On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM Antoine Riard =20 > wrote:=20 > > >=20 > > > > Hi list,=20 > > > >=20 > > > > Thanks to the annex covered by the signature, I don't see how the= =20 > concern about limiting=20 > > > > the extensibility of bitcoin script with future (post-quantum)=20 > cryptographic schemes.=20 > > > > Previous proposal of the annex were deliberately designed with=20 > variable-length fields=20 > > > > to flexibly accomodate a wide range of things.=20 > > > >=20 > > > > I believe there is one thing that has not been proposed to limit=20 > unpredictable utterance=20 > > > > of spams on the blockchain, namely congestion control of categories= =20 > of outputs (e.g "fat"=20 > > > > scriptpubkeys). Let's say P a block period, T a type of scriptpubke= y=20 > and L a limiting=20 > > > > threshold for the number of T occurences during the period P. Beyon= d=20 > the L threshold, any=20 > > > > additional T scriptpubkey is making the block invalid. Or=20 > alternatively, any additional=20 > > > > T generating / spending transaction must pay some weight penalty...= =20 > > > >=20 > > > > Congestion control, which of course comes with its lot of=20 > shenanigans, is not very a novel=20 > > > > idea as I believe it has been floated few times in the context of= =20 > lightning to solve mass=20 > > > > closure, where channels out-priced at current feerate would have=20 > their safety timelocks scale=20 > > > > ups.=20 > > > >=20 > > > > No need anymore to come to social consensus on what is quantitative= =20 > "spam" or not. The blockchain=20 > > > > would automatically throttle out the block space spamming=20 > transaction. Qualitative spam it's another=20 > > > > question, for anyone who has ever read shannon's theory of=20 > communication only effective thing can=20 > > > > be to limit the size of data payload. But probably we're kickly bac= k=20 > to a non-mathematically solvable=20 > > > > linguistical question again [0].=20 > > > >=20 > > > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in= =20 > favor of prioritizing=20 > > > > a timewarp fix and limiting dosy spends by old redeem scripts,=20 > rather than engaging in shooting=20 > > > > ourselves in the foot with ill-designed "spam" consensus=20 > mitigations.=20 > > > >=20 > > > > [0] If you have a soul of logician, it would be an interesting=20 > demonstration to come with=20 > > > > to establish that we cannot come up with mathematically or=20 > cryptographically consensus means=20 > > > > to solve qualitative "spam", which in a very pure sense is a=20 > linguistical issue.=20 > > > >=20 > > > > Best,=20 > > > > Antoine=20 > > > > OTS hash:=20 > 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999=20 > > > > Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot = a=20 > =C3=A9crit :=20 > > > >=20 > > > > > Hi,=20 > > > > >=20 > > > > > This approach was discussed last year when evaluating the best wa= y=20 > to mitigate DoS blocks in terms=20 > > > > > of gains compared to confiscatory surface. Limiting the size of= =20 > created scriptPubKeys is not a=20 > > > > > sufficient mitigation on its own, and has a non-trivial=20 > confiscatory surface.=20 > > > > >=20 > > > > > One of the goal of BIP54 is to address objections to Matt's=20 > earlier proposal, notably the (in my=20 > > > > > opinion reasonable) confiscation concerns voiced by Russell=20 > O'Connor. Limiting the size of=20 > > > > > scriptPubKeys would in this regard be moving in the opposite=20 > direction.=20 > > > > >=20 > > > > > Various approaches of limiting the size of spent scriptPubKeys=20 > were discussed, in forms that would=20 > > > > > mitigate the confiscatory surface, to adopt in addition to (what= =20 > eventually became) the BIP54 sigops=20 > > > > > limit. However i decided against including this additional measur= e=20 > in BIP54 because:=20 > > > > > - of the inherent complexity of the discussed schemes, which woul= d=20 > make it hard to reason about=20 > > > > > constructing transactions spending legacy inputs, and equally har= d=20 > to evaluate the reduction of=20 > > > > > the confiscatory surface;=20 > > > > > - more importantly, there is steep diminishing returns to piling= =20 > on more mitigations. The BIP54=20 > > > > > limit on its own prevents an externally-motivated attacker from= =20 > *unevenly* stalling the network=20 > > > > > for dozens of minutes, and a revenue-maximizing miner from=20 > regularly stalling its competitions=20 > > > > > for dozens of seconds, at a minimized cost in confiscatory=20 > surface. Additional mitigations reduce=20 > > > > > the worst case validation time by a smaller factor at a higher=20 > cost in terms of confiscatory=20 > > > > > surface. It "feels right" to further reduce those numbers, but=20 > it's less clear what the tangible=20 > > > > > gains would be.=20 > > > > >=20 > > > > > Furthermore, it's always possible to get the biggest bang for our= =20 > buck in a first step and going the=20 > > > > > extra mile in a later, more controversial, soft fork. I previousl= y=20 > floated the idea of a "cleanup=20 > > > > > v2" in private discussions, and i think besides a reduction of th= e=20 > maximum scriptPubKey size it=20 > > > > > should feature a consensus-enforced maximum transaction size for= =20 > the reasons stated here:=20 > > > > >=20 > https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/17= 32/8.=20 > I wouldn't hold my=20 > > > > > breath on such a "cleanup v2", but it may be useful to have it=20 > documented somewhere.=20 > > > > >=20 > > > > > I'm trying to not go into much details regarding which mitigation= s=20 > were considered in designing=20 > > > > > BIP54, because they are tightly related to the design of various= =20 > DoS blocks. But i'm always happy to=20 > > > > > rehash the decisions made there and (re-)consider alternative=20 > approaches on the semi-private Delving=20 > > > > > thread [0] dedicated to this purpose. Feel free to ping me to get= =20 > access if i know you.=20 > > > > >=20 > > > > > Best,=20 > > > > > Antoine Poinsot=20 > > > > >=20 > > > > > [0]:=20 > https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > On Friday, October 17th, 2025 at 1:12 PM, Brandon Black < > fre...@reardencode.com> wrote:=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:=20 > > > > > >=20 > > > > > > > But also given that there are essentially no violations and n= o=20 > reason to=20 > > > > > > > expect any I'm not sure the proposal is worth time relative t= o=20 > fixes of=20 > > > > > > > actual moderately serious DOS attack issues.=20 > > > > > >=20 > > > > > >=20 > > > > > > I believe this limit would also stop most (all?) of=20 > PortlandHODL's=20 > > > > > > DoSblocks without having to make some of the other changes in= =20 > GCC. I=20 > > > > > > think it's worthwhile to compare this approach to those propose= d=20 > by=20 > > > > > > Antoine in solving these DoS vectors.=20 > > > > > >=20 > > > > > > Best,=20 > > > > > >=20 > > > > > > --Brandon=20 > > > > > >=20 > > > > > > --=20 > > > > > > You received this message because you are subscribed to the=20 > Google Groups "Bitcoin Development Mailing List" group.=20 > > > > > > To unsubscribe from this group and stop receiving emails from= =20 > it, send an email to bitcoindev+...@googlegroups.com.=20 > > > > > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/aPJ3w6bEoaye3WJ6%40console.= =20 > > > >=20 > > > > --=20 > > > > You received this message because you are subscribed to the Google= =20 > Groups "Bitcoin Development Mailing List" group.=20 > > > > To unsubscribe from this group and stop receiving emails from it,= =20 > send an email to bitcoindev+...@googlegroups.com.=20 > > >=20 > > > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/5135a031-a94e-49b9-ab31-a1eb= 48875ff2n%40googlegroups.com.=20 > > >=20 > > --=20 > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group.=20 > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com.=20 > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/78475572-3e52-44e4-8116-8f1a= 917995a4n%40googlegroups.com.=20 > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/f4755fb6-b031-4c60-b304-f123= ba2ff473n%40googlegroups.com=20 > > . > > --=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/= 73793fc0-29d8-4b79-b7bf-048e459c928bn%40googlegroups.com. ------=_Part_617_1598208414.1761862506740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> We should reflect on the goal of minimizing UTXO set size.=C2=A0 = Would we as easily say we should minimize the number of people/entities who= hold L1 coins, or the number of ways each person/entity can hold them?
> The dire concern with UTXO set size was born with the optimizat= ion of the core bitcoin software for mining, rather than for holding and tr= ansfers, in 2012.=C2=A0 Some geniuses were involved with that change.=C2=A0= Satoshi was not one of them.

The goal isn=E2=80=99t to minim= ize UTXOs themselves or discourage people from self-custodying coins on L1.= We should minimize non-monetary UTXOs=C2=A0(those created= only for file storage, dusting-type tracking, etc.), not those used for tr= ansferring or holding value, as intended.

Minimizing=C2=A0unnecessary resource usage that doesn=E2=80=99t= serve the =E2=80=9Cpeer-to-peer money=E2=80=9D purpose helps everyone that= has that purpose as a goal:
=E2=80=93 Everyday users who want to store their savings securely.
=E2=80=93 Active users who want to spend and settle efficiently.
=E2=80=93 Node runners who keep the network decentralized and verifiable.

Bitcoin should take all steps to avoid unnecessary bloat (which has led = to an extra ~30 GB/yr of immutable data storage since Feb 2023 and complete= ly sidetracked any REAL improvements / security upgrades that should've bee= n leading discussions).=C2=A0 Then perhaps in just a few years, every new p= hone could comfortably run its own fully-verifying node with no trusted ser= vers or light-clients... enabling efficient, permissionless monetary use on= both L1 or L2.=C2=A0 Self-hosted LN nodes cannot compete with those who wa= nt file storage that lasts longer than the user itself.

Since you brought it up... I have a proposal to limit "bulk dust" (defin= ed as a Tx with >=3D ~20 "Tiny" outputs &&=C2=A0 >=3D ~70% of= the outputs are "Tiny", which starts at 4096 sats but halves every epoch, = beginning at block 1,260,000).

It should be difficult to use Bit= coin for data storage and sending tiny Txs for that purpose, which has harm= ful effects on not just the UTXO set, but also the network... which is prec= isely what IsDust() and IsStandard() were designed to do.=C2=A0 Changing co= nsensus rules is less than ideal, but for everyone that says "filters don't= work", consensus changes would appear to be the only "default solutions" t= hey'll accept, to actually identify certain Txs or patterns as invalid.

= See:=C2=A0 Limit "Bulk Dust" with a default filter or consensus...=C2=A0htt= ps://groups.google.com/g/bitcoindev/c/mW_zR01joiY

On Thursday, October 30= , 2025 at 12:37:03=E2=80=AFPM UTC-5 Tom Harding wrote:
We should reflect on the goa= l of minimizing UTXO set size.=C2=A0 Would we as easily say we should minim= ize the number of people/entities who hold L1 coins, or the number of ways = each person/entity can hold them?

The dire concern= with UTXO set size was born with the optimization of the core bitcoin soft= ware for mining, rather than for holding and transfers, in 2012.=C2=A0 Some= geniuses were involved with that change.=C2=A0 Satoshi was not one of them= .=C2=A0


On Wednes= day, October 29, 2025 at 7:32:10=E2=80=AFPM UTC-7 Greg Maxwell wrote:
"A few bytes&quo= t; 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 da= y outage) reindex of all unpruned nodes.=C2=A0 Not insignificant=C2=A0but a= lso not nothing.=C2=A0 Such a portion of the=C2=A0existing utxo size is not= from outputs over 520 bytes in size, so as a scheme for utxo set size redu= ction the addition of MHT tracking would probably make it a failure.
<= div>
Also some risk of creating some new scarce asset class, = txouts consisting of primordial=C2=A0coins that aren't subject to the n= ew rules... sounds like the sort of thing that NFT degens would absolutely = love.=C2=A0 That might not be an issue *generally* for some change with con= fiscation=C2=A0risk, but for a change that is specifically intended to lobo= tomize bitcoin to make it 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 p= ropose 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 p= robably could be viable if the confiscation issue was addressed, but it als= o doesn't stick it to people transacting in ways the priests of ocean m= ining dislike.=C2=A0

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

I think it'= ;s a mistake to conclude the spammers are economically irrational-- they= 9;re often just responding 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 that makes their tokens scarce and gives them value= .=C2=A0 -- otherwise they wouldn't be swapping for one less efficient e= ncoding 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 <mtidw...@gmail.com> wr= ote:
> MRH tracking migh= t make that acceptable, but comes at a high cost which I think would clearl= y not be justified.

Greg, I want to ask/challenge how bad this is, t= his seems like a generally reusable primitive that could make other upgrade= s 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 trans= actions that may exist using P2MS, is this a hard enough reason to require = a MRH idea?

Greg,

> So, paradoxically this limit might inc= rease the amount of non-prunable data

I believe you're pointing = out the idea of non economically-rational spammers? We already see actors i= gnoring cheaper witness inscription methods. If spam shifts to many sub-520= fake pubkey outputs (which I believe is less harmful than stamps), that im= o is a separate UTXO cost discussion. (like a SF to add weight to outputs).= Anywho, this point alone doesn't seem sufficient to add as a clear neg= ative 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:
> Confisc= ation 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:
> > > > 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.
> > > >=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/= aPJ3w6bEoaye3WJ6%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-a= 1eb48875ff2n%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 email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/78475572-3e52-44e4-8116-8f1a917995a= 4n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/73793fc0-29d8-4b79-b7bf-048e459c928bn%40googlegroups.com.
------=_Part_617_1598208414.1761862506740-- ------=_Part_616_1027043188.1761862506740--