From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 10:37:43 -0700 Received: from mail-oi1-f183.google.com ([209.85.167.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEWak-0008Qs-G2 for bitcoindev@gnusha.org; Thu, 30 Oct 2025 10:37:43 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-43fb00e0d45sf1735249b6e.3 for ; Thu, 30 Oct 2025 10:37:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761845856; cv=pass; d=google.com; s=arc-20240605; b=RUmM/bLuER94uEvdnUvUrKiZrmaIkdIztCMKptkksJeRkMNsyQNbkj2h3LsQ9IwV2J +gfDATEVlwFtSkg/aHvskVpVYS1m8VU3h4fQwMuznEGYKPiZd7mXyZSvH4DKwt9BNldf QY0pzO7o3BteetW/pHK/KjOLbK5jdXxlLZ8cxcLIqDgYEOvkkiFOXEMl784ut+sg8luF a1KwHFQHg6RNwH9JQsyTyEVpMbohJWDcOEYgUMW8AJWuzTlpKijdI6Jrft+JeX9wg+x0 3U/HYEfjNC3Ydig8pfkLz37nOu5ddtEv/YHnBq/GKl+HCuwzYU81UFf1YxjsHXnDyduN RL3w== 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=3drsRtmrRiDDNndTrCTXzpXWJ/Np4Cv1U/ZxAu7jjiQ=; fh=jmxvtf2nK+LEK6+kG/63f/IfZi28048S7IsbNamQLG4=; b=HaqS5BRDxGJhJLwSjBVZ9lvK2VBwOpWB8f85uHhJFRSNiK0owO6AwtI0u1HFpIpVM9 TvfuNnsymOJnB7nNFLr7D3Ja61tM69T+51HKZSJ5BoQg1SY3Knvhhz5LZ28KQLsERFYh CO+PNDTmw9AogTCWRe8V5RqdFs6dfs1tVlZFS/jjwtoq1o8suR+2q2FRKOibDwzaJ2vQ 6eHrtjzdhx+wvFIkWke2A9Hy6cEvG90k57fUnAHxacAWUEvWc6Uc45Rt/NE+m2LNYKsP bZj5URIfKKtf8BSckn2HNyUBcO0ONwnXhT3DgnduEP15JFEwjPcJftnlexuQU7MqU+Hz rdrA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lm2hig7D; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=melvincarvalho@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=1761845856; x=1762450656; 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=3drsRtmrRiDDNndTrCTXzpXWJ/Np4Cv1U/ZxAu7jjiQ=; b=iHc81Hl7uVD4dx0RZNhX/TPkHc5txUwIibPuWmCxmmUxakkcyFabJk7IN//g8oMgPj QP3t+s/1FUizIhrgPMnGHQnDv1MKTZLrSjEBKVQZkBS7F/KWVcjzVtqk0sfya4kt5Pmo 7VrFWpF3fZWhIPOqvUVPL9z3MXSeNGNfoyRD3aBU4l5LwvN+rCQbbqH9Q15EE31zpHkg 2Yi/J/NC/83qL9ojpX3zIiryvFgtrQ72OXzgEPC5Dg7S1/8WzgaCWiMK+nuCO34vhn0O ksdy4M9FHsp2ugxryeH/Wd2tysX1nwJKh8Llfg6hOVCPl8AJ+tU+1PLc7UMqxDWM+M/C budQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761845856; x=1762450656; 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=3drsRtmrRiDDNndTrCTXzpXWJ/Np4Cv1U/ZxAu7jjiQ=; b=GBLbcp4TiBKS5GJj9dwn9d9NlyCMGR6ekDVqMCgf0r2z+sIhBnu4IZsPn7gcImxaLv fC9TT+/YPlszcM7OUMIJvsruGMOSydHCalSG8sv96MQ3nfsNqFLyGDv4J3qm857p81ka ltCx5/zYedh71aGjdNFvF5NettYQMXCHOej1U770hJwgFvwmQabks+qHPxlcN7bJEnIc 7yzlj61tOUypO/iwmWXX1fbtaWb0nKJTT6BPF5hW/BRW+prWqpa3H+lC+iH8dH0HKIsF FmEQ5tZMB7Spaab53O4pm/30g++AwqVn/K6g1MDpa5FD5m9StFOuy7VTtAxh+/AYA4kB Ea9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761845856; x=1762450656; 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=3drsRtmrRiDDNndTrCTXzpXWJ/Np4Cv1U/ZxAu7jjiQ=; b=VfuwJNzjsViAgFVNLwZ1xHfQh+2ViV9KkcdSuhpBpRWANouN9YpCXk3ihgK2uWRs/B Ly5McP75P2xgm8pI3h+GFuGGxQrU1Qov0kNOaGY+xZ5F+Ww50UcNBdDPE4NBwG5gveQY 7r4J7kMYyzx+KFI9mC0S5GRAesSOWmDwIxQNzOa7VgimiiJI+9JIGzB+l76g2YcrMreq rKCvvaYtlxGPkEJDYt8c9yc0jLOff6sKTxJ5RYNHNZgqYoNMJaVft5DcddTOj+S9OTfl fGmQlJ+kao8uMh7EVCJCtPCqcFqBt5s+DPN5MYxxqp+k/HWL9zcqd1mShEMonpcxc6y7 Ok/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWjnKy+wMyLJKx8dyrd3sCcwDkNfuHmWkUp7/VEFYX8+pNmoF/Qinc8WjU34SzRQ54Vt+KiMlsC/HNf@gnusha.org X-Gm-Message-State: AOJu0YwWFdMAq6RqfEFRWDfaYycxx+y9bBydxNbtJfxHNIXU7/gWMNqK PHjVvemn5FbRkFVbTp+Ym1vBUYOykq2J7bT3VACrwBE44ehi7dQ0iXBg X-Google-Smtp-Source: AGHT+IGtcBa8L6AG0YmdIGszIDeP+Zd0wTNSg5MOTK/OAXL1t3AWD7yx2/HVIOeKSZQNr26F1wO4QA== X-Received: by 2002:a05:6808:5086:b0:44d:abf8:8d3f with SMTP id 5614622812f47-44f960b7235mr221246b6e.58.1761845856247; Thu, 30 Oct 2025 10:37:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+b4drCVRmPUsvJTJ1pAzXwyy3izMDwjE8Ate2VPgGE4wA==" Received: by 2002:a05:6820:4585:b0:623:4d59:817b with SMTP id 006d021491bc7-65682496065ls409436eaf.2.-pod-prod-09-us; Thu, 30 Oct 2025 10:37:31 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWjNQcsvtHmgJUtRTYkhyUn+/PHa+v+t1MzG0pGP5ltlQtKrh+P+ps87cIyzZuvOEdWcUB0lQdeEwRO@googlegroups.com X-Received: by 2002:a05:6808:13cb:b0:44d:a3a1:c86 with SMTP id 5614622812f47-44f95f2014dmr221343b6e.22.1761845851901; Thu, 30 Oct 2025 10:37:31 -0700 (PDT) Received: by 2002:a05:690c:6d91:b0:780:f7eb:fdf with SMTP id 00721157ae682-786295b01cdms7b3; Thu, 30 Oct 2025 08:04:22 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXwKdjjf4Smb5+8QVOZFxtzu6dlMDb9L4+pd0Uh/AV5tJ3Ao3JKZeYuOGrC07hvnbY4j1RqNrDQMHRv@googlegroups.com X-Received: by 2002:a53:d504:0:b0:63f:7c91:51eb with SMTP id 956f58d0204a3-63f83ad7e71mr1817992d50.66.1761836660873; Thu, 30 Oct 2025 08:04:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761836660; cv=none; d=google.com; s=arc-20240605; b=AJmx2wabzOaBA9GB3eTnAAN6C+JbtF9senf8yO+Q0jHTcN8wGGq0O39UyEo03cGvH1 EDA6Cc3rhWeooCJRx7fZpZ0mZOtNKeRn8n6+PvWBo7XBRYQ06y3pgoQIRvdLyV1uop2S /VXEjSvtxTNzY8iybfzpXow8gc0breOYxpDd0NEq0O53H8kZFFGNv+oXka84htBmZgNv F6iENEBdslUbxdJSG2/ID33tRKWUwzlk+s56z9Vnm20DWZv/u1hLE4gGTB0QG2P/K98q nB4iTTOJQU6nhOoGKhqERkZgllDDCin3IaXWiwrhmG53KGwLvO+maP+NfML9NGCZoR0y S9Ng== 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=0hRnkWu2uzhlrlLPeDAjxblD+K5EDaWwqLwvhrcNbGY=; fh=C1ToxHWx1tpPtsAkHewDRcYVSR1JGaw0i5N5mjS6clg=; b=CYDEdtMZ5XGRoImt4Egty4YfDy58bkK0wq4u7kfJC03qj9IUn9u7LDUeFLJEl8H9rc ObDEzEEylTHSU+XNlwCgK0u+3KeMyTywOk2+9eGEs19K7ihAlTNX2FRWsukQwqAZda1s HrSGTIg2BeKYL7l7dd1Qnj0pr1UOfrf7+ugu27FUEjc7dUQB0rL1xZGwop6TbgfHHWp3 PcSqGTJTZdTOwI/2Ts2cEMtmD5ghYoxrxwZ3p2pWDe0S8A4CmdWX3wwgiza8kpQPFVhE u4ytTDjeNTn0i5YWFGp4IxqBCrETGe45sz68MNQoaEFvNVpQogy4OYXi0TYloRqyCx4r Nqzw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lm2hig7D; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com. [2607:f8b0:4864:20::1030]) by gmr-mx.google.com with ESMTPS id 00721157ae682-785ee4c83e1si8230707b3.3.2025.10.30.08.04.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Oct 2025 08:04:20 -0700 (PDT) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) client-ip=2607:f8b0:4864:20::1030; Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-33b9dc8d517so1212469a91.0 for ; Thu, 30 Oct 2025 08:04:20 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVD+qoJXQwhM2kn5CGgCQoujjYZ6YB66kcnLTPO37KKC4rvHH1KFCZlBzAQOAlKwyD4zqWxjSJ4Tuys@googlegroups.com X-Gm-Gg: ASbGnctAPHwtwXZGDPqiguAWTB3DwgW0SRdP/+/kKvgJwodkC+4Sm3wBHm3YIdj2j+0 XFqFH1KBtwkVkjT/nKvaT4wWBh5pDTHGQFiN9qWLoAKaoCxXLe8nnDBQMBzhYpm8vi4oS8AK7zh 68UBLc1Q+EPAD0+2mqBgyWaLTdj4CIL0+daXiS+YgTV5OrSvo62zYLcp3pFZTWxnuwwlELzMGCS IzTi45e/DFnCi5SVyadVHEsV78TeEVKskimr1VBi8uayDjyxs0dAXjaIsgaUxn3GBkMhQeAtVZL saFpYcdWNG11YKWSo9Q1fWDhDNw5WSbI6/0gMucpZQ9Y X-Received: by 2002:a17:90b:1f88:b0:340:66f9:381 with SMTP id 98e67ed59e1d1-34082fd8457mr49786a91.10.1761836659633; Thu, 30 Oct 2025 08:04:19 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: From: Melvin Carvalho Date: Thu, 30 Oct 2025 16:04:03 +0100 X-Gm-Features: AWmQ_bmjiWUIEqpX5dS5NuOpPKjzRbRA954fz8t7C0anXlp-uEOgSQ2iUTETaJo Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: Greg Maxwell Cc: yes_please , "Russell O'Connor" , TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000003ff0f0064261905c" X-Original-Sender: melvincarvalho@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lm2hig7D; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=melvincarvalho@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 (/) --0000000000003ff0f0064261905c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C4=8Dt 30. 10. 2025 v 3:16 odes=C3=ADlatel Greg Maxwell napsal: > 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 settin= g > 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 a= nd > relentless harassment of Luke-jr. Had that not occurred perhaps the limi= t > would have been incrementally increased previously before major miners on > their own found it to be in their interest to simply remove it (as removi= ng > 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 wou= ld > have happily told you this in 2014 or whenever back when op_return was > reallowed for relay. Beyond the current situation with the rule complete= ly > 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 onl= y > at best a nudge and a fragile one. > > I think in many people's view-- certainly in mine-- cirtia or whatever wa= s > irrelevant to the discussion except as a concrete example of a fake pubke= y > 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. > While much of this discussion has focused on policy, there=E2=80=99s also a= n incentive perspective. Section 11 of the white paper notes that consensus holds *iff* honest nodes outpace dishonest ones. If we interpret *honest* as mining blocks consistent with standard monetary use, excluding large OP_RETURN payloads, then miners who do so are likely to earn more. When fees from arbitrary data are smaller than roughly half the block reward, standard ("honest") miners are effectively producing *double-value* blocks each epoch: they gain both the reward and a more secure, stable fee market over time. That economic feedback alone could be enough to restore convergence back to standard size OP_RETURNs. Of course, setting back the default helps here too. > > > > > > > > > > > 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 tim= e >> for code maintenance, so we'd rather increase it now to 100'000 bytes an= d >> 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 = the >> 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 harmf= ul >> 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 >> Development 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-proof= s. 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 = UTXO >>> 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 bl= oat >>> 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 = to >>> watch for screen locking events instead. Fortunately, in the case of K= DE, >>> 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 f= ind >>> workarounds for their proof of publication protocols will ultimately l= ead >>> to them using the uncensorable data channel of bare-multisigs, or simil= ar, >>> 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. T= his >>> collective cost will actually be much higher than the cost to the exter= nal >>> 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 instea= d, >>> 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 l= eads >>> 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. T= he >>> victims would be every Bitcoin node operator on the planet. And while = the >>> core developers have no warranties or responsibilities attached to thei= r >>> open source code, I think we would agree that "costs borne by every Bit= coin >>> node operator on the planet", is something they ought to bear in mind i= n >>> 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 >>> 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/CAMZUoK%3DuAxX_UGb7MBJZubi= NWuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.com >>> >>> . >>> >> -- >> 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/CAPDT2SSC4p97xpDUKGE%2BwsRe= 3vw1%3D1q6-72UJHvzMPoTau7A7g%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/CAAS2fgTBNYUA%2Bu6qhywK7-hC1= CB%2BzqWSU9a8JsOG8nd-WsDLCQ%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/= CAKaEYh%2BD9y6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%40mail.gmail.com. --0000000000003ff0f0064261905c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C4=8Dt 30. 10.= 2025 v=C2=A03:16 odes=C3=ADlatel Greg Maxwell <gmaxwell@gmail.com> napsal:
I searched for the s= ource 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 mi= ners had already removed the rule completely.=C2=A0 As such no lesser setti= ng 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 cons= ider 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 unprofe= ssional 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 found it to be in their interest to simply= remove it (as removing it is much easier than twiddling it).=C2=A0 The con= sequence of failing to be pragmatic is the loss of that nudge.
That said, the economics and incentives of bitcoin are such th= at 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 Beyond the current situation with the rule c= ompletely bypassed this inevitably favors removal once the policy has start= ed eroding.=C2=A0 Even if miners had only bypassed to a few kilobytes or wh= atnot moving to match that would only result in repeated cycles of transact= ions that will get mined failing to relay, each cycle favoring private subm= ission mechanisms and promoting mining centralization.=C2=A0 Policy is only= at best a nudge and a fragile one.

I think in man= y 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 th= at we'd all rather not be using Bitcoin at all. In other words, that th= e benefit of avoiding more utxo bloat wasn't speculative.

While much of this discussion has focused on= policy, there=E2=80=99s also an incentive perspective.

Section 11 of the white paper notes that consensus holds iff hones= t nodes outpace dishonest ones.

If we interpret honest as mining blocks consistent with standard m= onetary use, excluding large OP_RETURN payloads, then miners who do so are = likely to earn more.

When fees from arbitrary data are smaller than roughly half the block rewar= d, standard ("honest") miners are effectively producing doubl= e-value blocks each epoch: they gain both the reward and a more secure= , stable fee market over time.
That economic feedback alone could be enough to restore convergence back to= standard size OP_RETURNs. Of course, setting back the default helps here t= oo.
=C2=A0










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

Perhaps we can find a meeting= point if we focus on the max size of OP_return ?=C2=A0
The incre= ase from 83 to 100'000 bytes has been motivated as "probably we wi= ll have to increase it again=C2=A0in the future, it requires energy=C2=A0an= d 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 unkn= own consequences that might manifest with such a drastic increase all at on= ce may not be the most prudent approach.=C2=A0
Considering also t= hat "the canary in the coal mine", namely Citrea use case, requir= es only 144 bytes to utilize op_return instead of more harmful ways, the in= crease to 100'000 bytes appears disproportionate given the circumstance= s, and=C2=A0again=C2=A0non-prudent enough (which is what I suspect is creat= ing most of the debate at hand).

caucasianjazz12= =C2=A0

On Wed, Oct 29, 2025 at 4:38=E2=80=AFPM 'Russell O'Conn= or' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> = wrote:
O= n Wed, Oct 29, 2025 at 5:45=E2=80=AFAM TokyoBitcoiner <arthurmyer@gmail.com> wrote= :
Questions reac= ting to text in reply of Russell O'Connor:
  • "=C2=A0t= here exist some protocols that require":=C2=A0
    • Which protoc= ols?
Citrea=E2=80=99s Clementine= bridge, which needs 144 bytes for zk-proofs.=C2=A0 I don't know anythi= ng about their=C2=A0protocol beyond that.
=C2=A0
    • Why does bitcoi= n need to cater to their needs?=C2=A0
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 Bitc= oin node operator on the planet because=C2=A0those (likely) unspendable UTX= O will have to remain in the UTXO set forever because they will be indistin= guishable from legitimate=C2=A0bare multisigs.
    • Do we cater to any protocol= that comes along?
      • How do we choose which to enable, and which to di= scourage?
Clamping dow= n on OP_RETURNs won't discourage the use of these Citrea-like protocols= .=C2=A0 Instead it will encourage them to instead use uncensorable publicat= ion channels such as bare multisigs, which will bloat the UTXO set and driv= e up costs for every Bitcoin node operator on the planet.=C2=A0
  • "the folks= using these protocols will simply have no choice":=C2=A0
    • D= id we force them to use bitcoin for their project?=C2=A0
    • 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 wh= en a recent KDE upgrade dropped the ability to specify some command to be r= un whenever the screen is locked, KDE "forced" me to write a syst= emd service to run dbus-monitor to watch for screen locking events instead.= =C2=A0 Fortunately, in the case of KDE, being "forced" to work ar= ound their changes only makes my life worse.=C2=A0 However in the case of l= imiting OP_RETURNs, users who are "forced" to find workarounds fo= r their proof of publication protocols=C2=A0 will ultimately lead to them u= sing the uncensorable data channel of bare-multisigs, or similar, which hav= e consequences not only for themselves but every other Bitcoin node operato= r on the planet.

It is specifically the externalit= ies caused by the bare-multisig workaround that we need to address. If thes= e externalities didn't exist, then I, and presumably others, wouldn'= ;t care so much.
  • "any attempt to cap OP_RETURN outputs will=C2=A0force=C2= =A0those users":=C2=A0
    • Again, force is a form of coe= rcion. Is the bitcoin code with it's current setting forcing any= one to do anything?=C2=A0
    • Are the external protocol designers the v= ictims 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 unce= nsorable bare-multisig avenue.=C2=A0 This collective cost will actually be = much higher than the cost to the external protocol designers who only have = to pay a few more pennies for their transactions.
=C2=A0
  • "Bitcoi= n Core 30 is *fixing* an existing problem":=C2=A0
    • What prob= lem?
The problem is a combinatio= n of protocols that require using proof-of-publication choosing to use unce= nsorable 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 block reconstruction and po= or quality fee estimates and the like.
    • Is the bitcoin code responsible for= fulfilling the needs of an external project or protocol?=C2=A0
      • If y= es, why?
Again the vic= tims here wouldn't be the external protocol designers.=C2=A0 They will = just pay the extra pennies to publish using bare-multisig.=C2=A0 The victim= s would be every Bitcoin node operator on the planet.=C2=A0 And while the c= ore developers have no warranties or responsibilities=C2=A0attached to thei= r open source code, I think we would agree that "costs borne by every = Bitcoin node operator on the planet", is something they ought to bear = in mind in their work.
=C2=A0

I hope you will take these question= s seriously. I really want to understand your thinking.

Hope this helps.=C2=A0

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CAAS2fgTBNYUA%2Bu6qhywK7-hC1CB%2Bz= qWSU9a8JsOG8nd-WsDLCQ%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.co= m/d/msgid/bitcoindev/CAKaEYh%2BD9y6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joX= EfQ%40mail.gmail.com.
--0000000000003ff0f0064261905c--