From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 19:16:28 -0700 Received: from mail-oi1-f186.google.com ([209.85.167.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEIDD-0003bW-4t for bitcoindev@gnusha.org; Wed, 29 Oct 2025 19:16:28 -0700 Received: by mail-oi1-f186.google.com with SMTP id 5614622812f47-4481c0b3dc5sf859305b6e.1 for ; Wed, 29 Oct 2025 19:16:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761790581; cv=pass; d=google.com; s=arc-20240605; b=UG/0U3ST/FM1HM6E50yXPZDSf6ofJ/0MIWCpm5rtcZygGHIvxxG80wcFCrTjOVjnI5 VM3BY3klgVjQXqUT4vkihL0fo0HabWIIHxviprAWY61bGCsyqBGbDNljp7QPqCbBgz+m ojXhAuVAfP7JPT8s3+rRqmN1UFneel50X0Hl9jGWq03FPu0XjjNsWp9GXtpEa3h+2V/L omPfO4SYVrOYsWFLv9OuCslJsrC9I7q5k3DKOFNww+4u0xZYhOOAkjATclsd2G4QRDrI mbEfWejckgXMvyRy7eJpkEf2ewQ7ZJdWtUV/Bw6tn1ECwqW/YrqKRV5kOC7XzoK97K/b GbCQ== 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=1cAF8/4fn6UwNJJei76DhJArlVLfEWspYBcD5aYEhHQ=; fh=CLkxsGFsWOwJjSIz1z0FiSbKeI1OMzLZ3QAfPYDq7PU=; b=E5Pc+CJ1OaRUcf9eT6TRaieReRupW5Rx3P2ffv9Xk0eTMgWVTrZ/A0qXA10ww93EX1 aRHthpbaQjxA7NxaKutoB3SCeRRkI32R3Z25iPfloITKF6/prAhiN5POrT6Gnl+75PRh loyeCdUXf5zL6OSlyT0iHPZ2Q5+/RtX9te23xIWfsaUSRm+xhwyhTOVZmNzB9Ww7oVn+ 4/t0XUCdtUjcx1NlxoduHIi7H1xAiDMOGPRQAFk1ukv2YK+Uy6/OrXPo55kc4uIfDYuN M/J8qA+m3tpmo4etRNCqsZ60DE8Eu7f9gSq35le+jGsX3CSq2zdAJHLB3Rw4u+lDvVHa uuVA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fEAsznlf; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 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=1761790581; x=1762395381; 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=1cAF8/4fn6UwNJJei76DhJArlVLfEWspYBcD5aYEhHQ=; b=PpdaM1NpHJQ4IIAoQcsPwAZo+G7aBxLizVtj+FVjT8WYvETT1EJwywfMkOXHChkav5 z5FAOWHdsav8dDTiN+HaTkEiMkxhlPKQeCEQ+rKM48y4ZdVU/cA8gG3Tyumntapv41mA IggFJyVUQZEckMUC4+w2gBgqTNl8RbJ9+fdKpE6hJ/hXUDs3so9bpJgGJHeHLGNZDOW/ R9QyfJRBjD+8QDm0mDzrSX3dgcTuHQMDZMWVp8nOuwZ/WDSic1OiWDmadekaG57BDjZt zZyFb1VPz4skaHxR7/szvwOcMhMfyy5sYWWIO9LqZGATa39gLN09IX7t7kZzZy5Fzfge 97TA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761790581; x=1762395381; 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=1cAF8/4fn6UwNJJei76DhJArlVLfEWspYBcD5aYEhHQ=; b=LPmNZNc9HqbgTG8KGD2xkkDrOF1A0z0VDEArh8y5uonYa7MfhhZhF26rjJ8/mwg0/Y mjoWMyexZ+trfesQqErBQqU3pwW+XbXbpwPfcCt+2/Dy7vcc9ORAIkZWO6DkzPfrdL0G 5LVK8c6SOHJQJ602ZHqJwSHO7JMR53NYlcBoFOphPEGt4GntFHDhpHTbcBV7MxpEBk9L dMdJKIp5glpkeDcbuuhs4bbpoPa3mM/s9a7PCuFPNdRq4LZkDAfDGlO+jRElX9gpju5E cMcsyQQHwHAtW2GG+Z24bYsHvAHu1YgXNegJQmUjfwT65GYdh9jXFDqDP01x/G2+Sz/L +CYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761790581; x=1762395381; 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=1cAF8/4fn6UwNJJei76DhJArlVLfEWspYBcD5aYEhHQ=; b=R4PbLkvF9BYFZKkmWu/p04eD+WUC4kZ96lf63vH8MAYROe9HZ/0uethfJDX+hgTAOI Ev3YUGohVeDulNF1r/4WXUufFvHhVUTgmedO+M+bJgeSyLyXKPyz8DK59xZxZAaenZY1 ImNmZUVU4pD7KVFSgbT3CsrJ9Wz0UOq8xfX4bLYlWcqqCzzThJN4goRwJBvL0srh3La0 PCrj/DT2owbn4aCJ9lXfi14+nQIfAOL8UYc78P5X6FhmgP3DTW8sFqkj1APNIrCqMW6z uF1wXt1H0Jbl/+K8ui0R9rIS8eHdXchXiz9CVNaPAQtDnPaScR2k5jviEEcjl3mugbTU afkA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW6ILc8HhboBkGqLvqZ1WU5UccwHqMbAdbd+X+bH2RbgqNmHSXdHapetIYmVKUlOXaSdiYjlp1s/MHK@gnusha.org X-Gm-Message-State: AOJu0YzlGb/oxdBPowCrR9xzZUpD7beKmYbPrthEoxfGLCpbAZQmzxrP jUv4fSUyqMpRpFiub9xIoaRCoFsUHMeOlzwVdHkubEGGuL6984twtdUA X-Google-Smtp-Source: AGHT+IEU9bWjvYZt8SU62bJhnOZNbWNDHtjJdmgkVibsHqKDzmGmrwXw7YxiVp2LrCCx+Hh8avO0/w== X-Received: by 2002:a05:6808:19a2:b0:44f:303f:7514 with SMTP id 5614622812f47-44f88b206e7mr873398b6e.24.1761790580160; Wed, 29 Oct 2025 19:16:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bCQCZplZ+HPaLeyHLafa5ItoLiZ/I+wogCQ4xcGmZIQA==" Received: by 2002:a05:6820:133:b0:654:d94c:3d25 with SMTP id 006d021491bc7-65677e682b8ls154199eaf.2.-pod-prod-00-us-canary; Wed, 29 Oct 2025 19:16:16 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXYpnYyqIJ+cUfk4yXBNdlUU+5nndkOy6wMEdDpc+WDp5KzexyruGc2lYe6UoP9MTEdNG2/mYZgjs9Y@googlegroups.com X-Received: by 2002:a05:6808:6b97:b0:44e:933:8c53 with SMTP id 5614622812f47-44f88b04e6cmr882562b6e.33.1761790575946; Wed, 29 Oct 2025 19:16:15 -0700 (PDT) Received: by 2002:a05:6808:218f:b0:44f:77df:d0f7 with SMTP id 5614622812f47-44f7b3a8f81msb6e; Wed, 29 Oct 2025 19:11:03 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUO5jko4ZqSGe3KX8RVMjYrSwrXhTwYY0vYbFD3sQKahZA8s2IDCvYgLkjrYz869h+lNLR9g1ygN1hF@googlegroups.com X-Received: by 2002:a17:90b:3f85:b0:330:b9e8:32e3 with SMTP id 98e67ed59e1d1-3404ac61022mr1862395a91.12.1761790262205; Wed, 29 Oct 2025 19:11:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761790262; cv=none; d=google.com; s=arc-20240605; b=Ma5HCBQv8+yvhitHZ0Ku/JMwgZtNyHaCDmGUVQlQgchudr3mtTTX9tzXWvH69FKtPr 44MrzuMQVQzNOsoS7PUFcbTRHCw0w589P1+8z9LZoaLDOyLFHFSCDy3QUM/uFLkODJbz pelw4cqVwjQ87U+HbSIKhKKwub49orqk8AmixxyMmVc0Aij6U2bVfqM7boYFWtEHTWEQ t0fp5WAX+0BD58kXKPmC4tqOL7313pRfRblkfwRgoDI5JjmXpUK573C3mGAOg5jbTk0D CpT48ShWS9FNdRh13QFXx8RP1iMKVQkhKvznxHhVe/FRPJS0Gr+TMd0VWWjFpfzpRujG k5oA== 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=VJGhNDtLefn/tql4rWxZME//soBIcu3AgzUZeiuCs7w=; fh=OwOC3AUtgkRQAH3A8k/N2pdl3vPBCnskcmmNF1lUF80=; b=EGEMgowvIB+5y3ZeVb3hHdxh5wDDXZeUQi4wof5K/5s1KdU4m8xg5vFyX9P1Eg+ZnJ ySTs4i6EHK7JojAV02yXPhVXveKMeX4+7NfqCSH3CB9C4/zDXsVbrgKF2awuI2qISGk8 1IjcyNPSYrzjCAOb/O9/As46GXZvzCF8bxoR/2QAke69cv/TZssE7dpo/038xdpDyD7+ KoMjYVEYvUE2D9ZcMhysE+mWe1r2PvI5kul52myNCW1vK8Cq4+Vugb4RB5TCtAxtwmDA aGDRTiOYpJRyH7tuUcDJ08W6DO+Cy+Xt+bqSrV45i8tSr92N6ah2jXn429foaMVxFxgI 27fw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fEAsznlf; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 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-x630.google.com (mail-pl1-x630.google.com. [2607:f8b0:4864:20::630]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3404f47bb6bsi9261a91.3.2025.10.29.19.11.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 19:11:02 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) client-ip=2607:f8b0:4864:20::630; Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-273a0aeed57so19614085ad.1 for ; Wed, 29 Oct 2025 19:11:02 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVqI3rD2KwcxdNuqeQLAhknA/5N8eFMpBUqt25pLNIwbkTb9uYxp1gy1ZdahPuznyFQPWlf5c+F/bsY@googlegroups.com X-Gm-Gg: ASbGnctoaUa79qWBn4UwYJzZrzc4JNwpehO1jzdukuZ22cUQZaZGXobBcfRP6UDXhOE vhvZ4M23wpoPBIbaPdWl8Hu6q7r+GYzzwtaB9/zckEwl+OBklObuBVRkEJekRXQhBae6HZbsVq5 k7wMUFWt85cFsD/Vm5siv/O0fPB+S897cxuDQuPNYCnB9jUVDwSw99Xr3Ij0cZXAMeVQc2H41+a h8rQJohi8yFNMuEvoXSUQIVvh6+flJIuKUoz2DdfOmupNUV2+hCxlnfMTv2AH6KK6fzUsIZnYYL +iKrhpnF7DYKuIj5Wfk5ekVGmsmTF+nbSUAJx9pQ X-Received: by 2002:a17:903:2306:b0:27e:d66e:8729 with SMTP id d9443c01a7336-294ece1dbaamr20033695ad.0.1761790261643; Wed, 29 Oct 2025 19:11:01 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: From: Greg Maxwell Date: Thu, 30 Oct 2025 02:10:49 +0000 X-Gm-Features: AWmQ_bn9dDGdNkVPXM2GgZ6JXutMDqkqBVAH5Q8XzeZngAQXfw9eb9bDLC4mxfs Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: yes_please Cc: "Russell O'Connor" , TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b6cd30064256c280" 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=fEAsznlf; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 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 (/) --000000000000b6cd30064256c280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I searched for the source of your quotation and am unable to find it, but its author appears to be confused or missing a complete understanding. The particular size isn't motivated by application but because major miners had already removed the rule completely. As such no lesser setting would achieve the goal of matching relay to what will actually get mined and completely solve the bad situation created by the mismatch. If you consider this regrettable it's worthwhile to consider that a failure to increase it previously (on several prior proposals) and even a failure to discuss and evaluate it was likely due to the unprofessional and relentless harassment of Luke-jr. Had that not occurred perhaps the limit would have been incrementally increased previously before major miners on their own found it to be in their interest to simply remove it (as removing it is much easier than twiddling it). The consequence of failing to be pragmatic is the loss of that nudge. That said, the economics and incentives of bitcoin are such that the removal was inevitable once people were willing to pay for it-- and I would have happily told you this in 2014 or whenever back when op_return was reallowed for relay. Beyond the current situation with the rule completely bypassed this inevitably favors removal once the policy has started eroding. Even if miners had only bypassed to a few kilobytes or whatnot moving to match that would only result in repeated cycles of transactions that will get mined failing to relay, each cycle favoring private submission mechanisms and promoting mining centralization. Policy is only at best a nudge and a fragile one. I think in many people's view-- certainly in mine-- cirtia or whatever was irrelevant to the discussion except as a concrete example of a fake pubkey user that would rather not do that-- and one that wasn't some random NFT thing that we'd all rather not be using Bitcoin at all. In other words, that the benefit of avoiding more utxo bloat wasn't speculative. On Thu, Oct 30, 2025 at 1:15=E2=80=AFAM yes_please wrote: > Hi all, > > Perhaps we can find a meeting point if we focus on the max size of > OP_return ? > The increase from 83 to 100'000 bytes has been motivated as "probably we > will have to increase it again in the future, it requires energy and time > for code maintenance, so we'd rather increase it now to 100'000 bytes and > be done with it". While these are valid points, the unknown consequences > that might manifest with such a drastic increase all at once may not be t= he > most prudent approach. > Considering also that "the canary in the coal mine", namely Citrea use > case, requires only 144 bytes to utilize op_return instead of more harmfu= l > ways, the increase to 100'000 bytes appears disproportionate given the > circumstances, and again non-prudent enough (which is what I suspect is > creating most of the debate at hand). > > caucasianjazz12 > > On Wed, Oct 29, 2025 at 4:38=E2=80=AFPM 'Russell O'Connor' via Bitcoin De= velopment > Mailing List wrote: > >> On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM TokyoBitcoiner >> wrote: >> >>> Questions reacting to text in reply of Russell O'Connor: >>> >>> - *" there exist some protocols that require":* >>> - Which protocols? >>> >>> Citrea=E2=80=99s Clementine bridge, which needs 144 bytes for zk-proofs= . I >> don't know anything about their protocol beyond that. >> >> >>> >>> - >>> - Why does bitcoin need to cater to their needs? >>> >>> If we don't support these in OP_RETURNs, Citrea, and other folks like >> them, will use something like bare multisigs instead, which will be a >> little more expensive for them and much more expensive for every other >> Bitcoin node operator on the planet because those (likely) unspendable U= TXO >> will have to remain in the UTXO set forever because they will be >> indistinguishable from legitimate bare multisigs. >> >>> >>> - >>> - Do we cater to any protocol that comes along? >>> - How do we choose which to enable, and which to discourage? >>> >>> Clamping down on OP_RETURNs won't discourage the use of these >> Citrea-like protocols. Instead it will encourage them to instead use >> uncensorable publication channels such as bare multisigs, which will blo= at >> the UTXO set and drive up costs for every Bitcoin node operator on the >> planet. >> >>> >>> - *"the folks using these protocols will simply have no choice"*: >>> - Did we *force* them to use bitcoin for their project? >>> - It sounds like "if you don't change the code to enable my >>> project, I will be forced to trash your project." Is this wrong? >>> >>> By "force" I mean in the sense that when a recent KDE upgrade dropped >> the ability to specify some command to be run whenever the screen is >> locked, KDE "forced" me to write a systemd service to run dbus-monitor t= o >> watch for screen locking events instead. Fortunately, in the case of KD= E, >> being "forced" to work around their changes only makes my life worse. >> However in the case of limiting OP_RETURNs, users who are "forced" to fi= nd >> workarounds for their proof of publication protocols will ultimately le= ad >> to them using the uncensorable data channel of bare-multisigs, or simila= r, >> which have consequences not only for themselves but every other Bitcoin >> node operator on the planet. >> >> It is specifically the externalities caused by the bare-multisig >> workaround that we need to address. If these externalities didn't exist, >> then I, and presumably others, wouldn't care so much. >> >>> >>> - *"any attempt to cap OP_RETURN outputs will force those users"*: >>> - Again, *force* is a form of coercion. Is the bitcoin code with >>> it's current setting *forcing* anyone to do anything? >>> - Are the external protocol designers the victims here? >>> >>> The victims will be every node operator on the planet who has to deal >> with the unprunable UTXO bloat caused by users posting their >> proof-of-publication data via the uncensorable bare-multisig avenue. Th= is >> collective cost will actually be much higher than the cost to the extern= al >> protocol designers who only have to pay a few more pennies for their >> transactions. >> >> >>> >>> - *"Bitcoin Core 30 is *fixing* an existing problem"*: >>> - What problem? >>> >>> The problem is a combination of protocols that require using >> proof-of-publication choosing to use uncensorable bare-multisigs instead= , >> and/or, so long as this proposal isn't adopted, the problem of users >> bypassing the network to get their OP_RETURN transactions mined which le= ads >> to poor quality block reconstruction and poor quality fee estimates and = the >> like. >> >>> >>> - >>> - Is the bitcoin code responsible for fulfilling the needs of an >>> external project or protocol? >>> - If yes, why? >>> >>> Again the victims here wouldn't be the external protocol designers. >> They will just pay the extra pennies to publish using bare-multisig. Th= e >> victims would be every Bitcoin node operator on the planet. And while t= he >> core developers have no warranties or responsibilities attached to their >> open source code, I think we would agree that "costs borne by every Bitc= oin >> node operator on the planet", is something they ought to bear in mind in >> their work. >> >> >>> >>> I hope you will take these questions seriously. I really want to >>> understand your thinking. >>> >> >> Hope this helps. >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZubiN= WuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.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/CAPDT2SSC4p97xpDUKGE%2BwsRe3= vw1%3D1q6-72UJHvzMPoTau7A7g%40mail.gmail.com > > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%40mail.gmail.com. --000000000000b6cd30064256c280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I searched for the source of your quotation and am un= able to find it, but its author appears to be confused or missing a complet= e understanding.

The particular size isn't mot= ivated by application but because major miners had already removed the rule= completely.=C2=A0 As such no lesser setting would achieve the goal of matc= hing relay to what will actually get mined and completely solve the bad sit= uation created by the mismatch.

If you consider th= is regrettable it's worthwhile to consider that a failure to increase i= t previously (on several prior proposals) and even a failure to discuss and= evaluate it was likely due to the unprofessional and relentless harassment= of Luke-jr.=C2=A0 Had that not occurred=C2=A0perhaps the limit would have = been incrementally increased previously before major miners on their own fo= und it to be in their interest to simply remove it (as removing it is much = easier than twiddling it).=C2=A0 The consequence of failing to be pragmatic= is the loss of that nudge.

That said, the economi= cs and incentives of bitcoin are such that the removal was inevitable once = people were willing to pay for it-- and I would have happily told you this = in 2014 or whenever back when op_return was reallowed for relay.=C2=A0 Beyo= nd the current situation with the rule completely bypassed this inevitably = favors removal once the policy has started eroding.=C2=A0 Even if miners ha= d only bypassed to a few kilobytes or whatnot moving to match that would on= ly result in repeated cycles of transactions that will get mined failing to= relay, each cycle favoring private submission mechanisms and promoting min= ing centralization.=C2=A0 Policy is only at best a nudge and a fragile one.=

I think in many people's view-- certainly in = mine-- cirtia or whatever was irrelevant to the discussion except as a conc= rete example of a fake pubkey user that would rather not do that-- and one = that wasn't some random NFT thing that we'd all rather not be using= Bitcoin at all. In other words, that the benefit of avoiding more utxo blo= at wasn't speculative.










On Thu, Oct 30, 2025 at 1:15=E2=80= =AFAM yes_please <caucasian= jazz12@gmail.com> wrote:
Hi all,=C2=A0

Perhaps w= e can find a meeting point if we focus on the max size of OP_return ?=C2=A0=
The increase from 83 to 100'000 bytes has been motivated as = "probably we will have to increase it again=C2=A0in the future, it req= uires energy=C2=A0and time for code maintenance, so we'd rather increas= e it now to 100'000 bytes and be done with it". While these are va= lid points, the unknown consequences that might manifest with such a drasti= c increase all at once may not be the most prudent approach.=C2=A0
Considering also that "the canary in the coal mine", namely Cit= rea use case, requires only 144 bytes to utilize op_return instead of more = harmful ways, the increase to 100'000 bytes appears disproportionate gi= ven the circumstances, and=C2=A0again=C2=A0non-prudent enough (which is wha= t I suspect is creating most of the debate at hand).

caucasianjazz12=C2=A0

On Wed, Oct 29, 2025 at 4:38=E2=80=AFPM '= Russell O'Connor' via Bitcoin Development Mailing List <bitcoindev@google= groups.com> wrote:
On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM TokyoBitcoiner &l= t;arthurmyer@gmai= l.com> wrote:
Questions reacting to text in reply of Russell O'Connor:
    <= li>"=C2=A0there exist some protocols that require":=C2=A0<= ul>
  • Which protocols?
Citrea= =E2=80=99s Clementine bridge, which needs 144 bytes for zk-proofs.=C2=A0 I = don't know anything about their=C2=A0protocol beyond that.
= =C2=A0
  • =
    • Why does bitcoin need to cater to their needs?=C2=A0
    • =
If we don't support these in OP_RETURNs, C= itrea, and other folks like them, will use something like bare multisigs in= stead, which will be a little more expensive for them and much more expensi= ve for every other Bitcoin node operator on the planet because=C2=A0those (= likely) unspendable UTXO will have to remain in the UTXO set forever becaus= e they will be indistinguishable from legitimate=C2=A0bare multisigs.
=
    • Do w= e cater to any protocol that comes along?
      • How do we choose which to = enable, and which to discourage?
Clamping down on OP_RETURNs won't discourage the use of thes= e Citrea-like protocols.=C2=A0 Instead it will encourage them to instead us= e uncensorable publication channels such as bare multisigs, which will bloa= t the UTXO set and drive up costs for every Bitcoin node operator on the pl= anet.=C2=A0
  • "the folks using these protocols will simply have no choice&qu= ot;:=C2=A0
    • Did we force them to use bitcoin for their pro= ject?=C2=A0
    • It sounds like "if you don't change the code t= o enable my project, I will be forced to trash your project." Is this = wrong?
    • By "force" I me= an in the sense that when a recent KDE upgrade dropped the ability to speci= fy some command to be run whenever the screen is locked, KDE "forced&q= uot; me to write a systemd service to run dbus-monitor to watch for screen = locking events instead.=C2=A0 Fortunately, in the case of KDE, being "= forced" to work around their changes only makes my life worse.=C2=A0 H= owever in the case of limiting OP_RETURNs, users who are "forced"= to find workarounds for their proof of publication protocols=C2=A0 will ul= timately lead to them using the uncensorable data channel of bare-multisigs= , or similar, which have consequences not only for themselves but every oth= er Bitcoin node operator on the planet.

    It is spec= ifically the externalities caused by the bare-multisig workaround that we n= eed to address. If these externalities didn't exist, then I, and presum= ably others, wouldn't care so much.
    • "any attempt to cap OP_RETURN outp= uts will=C2=A0force=C2=A0those users":=C2=A0
      • Again, forc= e is a form of coercion. Is the bitcoin code with it's current sett= ing forcing anyone to do anything?=C2=A0
      • Are the external pr= otocol designers the victims here?
    The victims will be every node operator on the planet who has to deal wi= th the unprunable UTXO bloat caused by users posting their proof-of-publica= tion data via the uncensorable bare-multisig avenue.=C2=A0 This collective = cost will actually be much higher than the cost to the external protocol de= signers who only have to pay a few more pennies for their transactions.
    =C2=A0
    <= ul>
  • "Bitcoin Core 30 is *fixing* an existing problem":= =C2=A0
    • What problem?
    • The = problem is a combination of protocols that require using proof-of-publicati= on choosing to use uncensorable bare-multisigs instead, and/or, so long as = this proposal isn't adopted, the problem of users bypassing the network= to get their OP_RETURN transactions mined which leads to poor quality bloc= k reconstruction and poor quality fee estimates and the like.
      • Is the bitco= in code responsible for fulfilling the needs of an external project or prot= ocol?=C2=A0
        • If yes, why?
    Again the victims here wouldn't be the external protocol desi= gners.=C2=A0 They will just pay the extra pennies to publish using bare-mul= tisig.=C2=A0 The victims would be every Bitcoin node operator on the planet= .=C2=A0 And while the core developers have no warranties or responsibilitie= s=C2=A0attached to their open source code, I think we would agree that &quo= t;costs borne by every Bitcoin node operator on the planet", is someth= ing they ought to bear in mind in their work.
    =C2=A0

    I hope you w= ill take these questions seriously. I really want to understand your thinki= ng.

    Hope this helps.=C2=A0
    <= /div>

    --
    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 ht= tps://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza= 4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.com.

    --
    You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
    To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D= 1q6-72UJHvzMPoTau7A7g%40mail.gmail.com.

    --
    You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%= 40mail.gmail.com.
    --000000000000b6cd30064256c280--