From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 23:34:39 -0700 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEiib-0007dR-Vf for bitcoindev@gnusha.org; Thu, 30 Oct 2025 23:34:39 -0700 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-447735e863asf3676512b6e.0 for ; Thu, 30 Oct 2025 23:34:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761892471; cv=pass; d=google.com; s=arc-20240605; b=EAdUD1t+Cx+zm7lX0RkLW7LfG7X+WyH2Zm++F2NoyxWx/3wuMZXNg+zAPSD2UFBMth Vey+YZK8S07KzoE1b1iWg8lTZ7Nh8ZLLZY12kAZU0gxo3hc/1YtT8zioVB5UBDt0HDp0 x67sZZP+tv+JQVNYduN+aqGEwNvzPQ066ScZFrSKjaNj0sHcjm/L5cvdeVs4wkXA52nL pkUwM9vzafkW2YhZS0mxP8aZELHjnKozHXxQeeLshTf4OHcR0q6Xp0gtbaYUCS1In2DI xqLmwhkWFmaQEGMop5UgG++cRL8384nJPWOc203J7rXYdBUGCzYJiWR151IpjwHxiAYN fWCQ== 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=vP068KHvUl0u4avROfwwNw/ccAQMasLpcwiXpXaNRlU=; fh=BljOCb4C9YZILre8CsVy0wyvku1ZmB1z/vl4rf1oSMU=; b=Ks0Vi5wG86HoMKbYCaYWHrDkVEYaoQICIUEoQBWVd6oRg5Ct2eHbHNP8JPYxlciVns GsZmoozYttwkEc+3gTAs8sM7ot2ynF3C1FCiJvLg0dLOq5ivxrywjLgQm9qIVFTxo1/u YxJZx1K1TCU1YViqqjL4H7ntLCMQiuY4jejtETwWA6pcb5ogycICO8m5logW2tv41pY5 jm17Pl+NvckI4zu8wx2fQA5XKMRQXXRlhkVOkhlnwv2rJlZZWRcGm9/YyGildOEg3aXA 377HIyZBcQo7ipNPKNdfY5KxJDT/p8swFQhz2qIe2dVImBNrOp8KWe04q+JFSGpH570T fq8A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=koWGdOE3; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1032 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=1761892471; x=1762497271; 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=vP068KHvUl0u4avROfwwNw/ccAQMasLpcwiXpXaNRlU=; b=h8FuilpMj0aaUVJjcuFArGEF0tjAHg2oAO4JVLG+sAt+Vv2WL148Znpfj1jWQkwIf8 tHnNckX+hAZ/+uQ1XivlK4bu13KWfgz+sOtpAn+1DhvwTi6n0mh3wTJCqaoL43qY4OiT yastP+FlK6T4k/qxTXSGONZP5f3G2FVrGmXuHKYWCrx0BawC041dlgo4yYb3DDs1k/Cl WzZyNLZ1EhR7dM5QSn539nzz0tsfFQpmIj5521VgRv7L+PrSEpU45la/uEIXyk2Ml/v6 XvfpouYXnj96tujy+9SnVGKJ0d6TJrYdfKpg+1w8aVQBPVJ/kOEBxXD9K867I96cIjfo TCyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761892471; x=1762497271; 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=vP068KHvUl0u4avROfwwNw/ccAQMasLpcwiXpXaNRlU=; b=kJ6hHlfedryjz068St9gcM4ogTJO8tI3qa8ltt3+8+pWj9ZadxEMjoVkEsV5hhtfE1 3rWhWGr2xlJodZiB/mPWGowH73welBXJsNLT1cleEOOXwqSWS2TFgm2jQbS7c9FTRPu9 gtND1V9EXdq/7vVylH9ae03Lflqimztqy+WeI6gkZjPSzKgYqQQcrcBNm6RfpGUh9+tC QqwAMDAyYYta7PRi9Y7JqMCXbzsp/Ak2obJA0B2sYL4NJpExIXwf8l14Xq6hRO2+xIHa eb46or575+oWvJYADVKmwpqgwiPG/p4tcEkF8hqbMCr7C3cuntjZtlbPQsjjay8Ff8v0 76Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761892471; x=1762497271; 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=vP068KHvUl0u4avROfwwNw/ccAQMasLpcwiXpXaNRlU=; b=pNAE8lpiyJk/q1Bf+KcpsruBtG1jmrbI0DB8EkK2eSFlHz8TdB3kddbhrms+Kaq8+A pc52I4OhDJnzj+pL08TnRZkoMxUc+Zcswhbt942t09h4YvcROiKi2oLEtnV6NmSxU5wP p2De0f/FF71F3rRAfUL1hnNINa0rzSmTQ9VK1GaUPBYlJf1wlBpKLEFz2TbNx43m4O1a aaxs+OYFwZjOCI8wM6EKT1WuJ1XumGjVw8sSh2K/WDSxc1Gv+UBuM7MCvo95eRsHRC/6 5D2UQY1wZ/0E7BB2MjjwicnT6nw5Wx3zvRoWbZ9HFIrsJ2oAPOQFlXfnOJkJW9Tl/y/x mDlw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXLip9xe3PAZRvkOwjuWxi3RIR733/c0KmtJl1lui71pn0zUfmCRE2KdDMswMtCPyn+qU3/4eJo3IKf@gnusha.org X-Gm-Message-State: AOJu0YzpFbnmqKesO8Eo4/IR+b6wnbtKE/RJKrw1GVWhA36Tiar+jGP7 gTob+FRN1CgfUPyYKl2xVVDkccbboeP1OZ6af2NIthhZl7+SwYn+E5vc X-Google-Smtp-Source: AGHT+IG9qe35rq26TqzhWqgDinW6k88DZEO8JsX6B1+a5qdGErMbglgsNeMWPcWLJSTKGBLtuXe0zA== X-Received: by 2002:a05:6808:4496:b0:441:8f74:f1d with SMTP id 5614622812f47-44f95ff9f44mr1158104b6e.55.1761892471370; Thu, 30 Oct 2025 23:34:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+b3RBtXg9KTlRGWOfZwiqvaSLuU3++nWKIuIyfIrxT07g==" Received: by 2002:a05:6820:2d0a:b0:656:7cf6:9258 with SMTP id 006d021491bc7-656824a6568ls1048606eaf.2.-pod-prod-05-us; Thu, 30 Oct 2025 23:34:27 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWG/eWgHxbIsYSWS4J35iO6ocmOBFbTXMKRfJF7X35ae5UnAI5ztyRYs8U5jDUzIJo3S3K+hBegUr5N@googlegroups.com X-Received: by 2002:a05:6808:331a:b0:44f:6a32:535e with SMTP id 5614622812f47-44f95e4c546mr1180643b6e.10.1761892467236; Thu, 30 Oct 2025 23:34:27 -0700 (PDT) Received: by 2002:a05:6808:668b:10b0:44f:6c18:6870 with SMTP id 5614622812f47-44f99095f9fmsb6e; Thu, 30 Oct 2025 23:31:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXg0iChX/mp19LoVpJW/xXRdx1XN1WDfpURi+E6HgfRcgqgGAhKuhTtJV43p56J8x7VSG3/4aIw5PG2@googlegroups.com X-Received: by 2002:a17:903:41c4:b0:290:c902:759 with SMTP id d9443c01a7336-2951a4b0520mr39991355ad.51.1761892281910; Thu, 30 Oct 2025 23:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761892281; cv=none; d=google.com; s=arc-20240605; b=C+nL9lbqcXHDWxojlmF9eC3SYeDOHccp0andxOxn42Rt9tupLh8AkGcZuvLuAFhn1A d4rDZq/hJkXDJS/Z5eB82B0lUvwSV/YDu07vb+850Mpgx2/Pg5IY8PDvONDi6rPVSNop iwG11IxFmNOtTiYu/yygz3ak+wO+jGhm0uiqOqOm8E+5fhSJQdw8RgPgR+GOsqTTFz2A BnmCl7tqMarNfLkcFBgjszql6RLu6ZQLuehk/hUa3+8ru8rW09aQtRs7HmIsZs9Lo9yW IAvX9HmR+LPN0r2enn3xfac4125C5L6/T148UUDdhfK8nGz8ly8qxhpoUF+6xdgN+pA8 xHPw== 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=9jRB1UWQEGki87O9aKnHwzUwnB3MdhvtoqvyB53lSHI=; fh=muiFWwDvOak5gycDcDZvm0bIhjMT5Ieyc0lGSOZjFIw=; b=c1IfyXSCefKGc+xB2+jqotZgOSMb3qjp5PjCBhkHQzmhD/nVICjy0iHxNi405j4C7r K4vpTAtbkPJ11r8mUkVJ0D7XW3VMoSB0ATX7HEHbiNrC83n1qaH7DQsTD0BOmcLcG/Ku 4WOIJTNy9O7/o7bf2DwXKybYNGEYEv7jg44ezTPPtLmej2f3zSovOYLuYgONcfpS+z1j rymRL99qpi8Ckt7+BUtdPjWAqywxQbsOHTneydFDHYAH8SJpn1dX4Ttdd5MCNh0FJT7d SeyMQQzb4tqu4h9sSJxiMjbtig6Lvd83yU7yEmBMnF7p5zapOtkl0AU2psuad1GY1Wz5 VBEw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=koWGdOE3; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1032 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-x1032.google.com (mail-pj1-x1032.google.com. [2607:f8b0:4864:20::1032]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-29526868bc9si752355ad.1.2025.10.30.23.31.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Oct 2025 23:31:21 -0700 (PDT) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1032 as permitted sender) client-ip=2607:f8b0:4864:20::1032; Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-32ec291a325so1584755a91.1 for ; Thu, 30 Oct 2025 23:31:21 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWdcqqXnilNczOXHi8D0D/UcbNoH7TPe5Ov/QM8dLWdIcUiTmuMzDD6qjVGsHTW6FmC1SHrJC+kNzWD@googlegroups.com X-Gm-Gg: ASbGncvhXgUOG35XoxQUjhFZAXeDgSj4Pen0HzY0vTpsc6fr504omqMMdtU4ADX0xFg 23C1upn6NuGBASIK2xj8D7FVencE1i+G48Iaptg8MIpJ9z2BrdqbVcQRH3e+ftQhTu1XGrvPvmz xZX7bdmL9/vFXp9UJyZpTXcP3Kzhispe64qzG1BtTQNwwI3OrX4/qbHjhDZvvwhFiTok1oCDPyn TkCNf8noK1TAAPfncG1fvEU99I+MjNkgZHJb9x66GuqLrqUzeT06DDQ7Ut9vgTmY4xyyiwgYnkX 0hYQjPEVn4TNyp6hOaZ3w3ua0RwlitivWL+cyfhjLAr0 X-Received: by 2002:a17:90b:3e88:b0:327:f216:4360 with SMTP id 98e67ed59e1d1-34082fa5968mr3820795a91.8.1761892281380; Thu, 30 Oct 2025 23:31:21 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: From: Melvin Carvalho Date: Fri, 31 Oct 2025 07:31:03 +0100 X-Gm-Features: AWmQ_bnnee70nSD1lSSqRztdLLxLOOvZFf7cKBByHLt3mLNAqf7jUxGyC2qGsUk Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Cc: Greg Maxwell , yes_please , "Russell O'Connor" , TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000009072a706426e83b9" 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=koWGdOE3; spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::1032 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 (/) --0000000000009072a706426e83b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C4=8Dt 30. 10. 2025 v 20:35 odes=C3=ADlatel Martin Habov=C5=A1tiak < martin.habovstiak@gmail.com> napsal: > "Honest" only refers to miners not trying to reverse the transactions by > making an alternative chain. It has nothing to do with your subjective > evaluation of the transactions worth trying to censor the "bad ones". > Hi Martin, Small clarification per the white paper: "honest" isn=E2=80=99t only about reversing transactions. Section 8 of the white paper also discusses honest nodes and which transactions are accepted into blocks. Satoshi further clarified standardness: "The design supports a broad range of transaction types that are possible, but not all are standard. Standard transactions are the ones that are designed to be used for the common case." -- June 2010 Per Section 11, the white paper's security model shows honest miners (e.g. following standard operation) outpacing alternatives. In practice, miners following a standardness agreement or soft fork for OP_RETURN would, on affected blocks, earn around $100,000 more, than under a mixed policy, making prioritizing standard transactions the economically optimal strategy= . This is because there are a finite number of blocks before each halving, so the opportunity cost of non-standard payloads is half the subsidy, which is more than enough economic upside to offset fees. A standardness agreement soft fork is therefore economically compelling for miners: it aligns with long-standing practice and provides long-term incentives. Best, Melvin > > Bitcoin was specifically designed to prevent censorship of transactions > that follow the consensus rules. Trying to go against it makes you a fool > at best or an attacker at worst. > > D=C5=88a =C5=A1t 30. 10. 2025, 18:37 Melvin Carvalho > nap=C3=ADsal(a): > >> >> >> =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 understandi= ng. >>> >>> The particular size isn't motivated by application but because major >>> miners had already removed the rule completely. As such no lesser sett= ing >>> would achieve the goal of matching relay to what will actually get mine= d >>> 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 li= mit >>> would have been incrementally increased previously before major miners = on >>> their own found it to be in their interest to simply remove it (as remo= ving >>> 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 w= ould >>> have happily told you this in 2014 or whenever back when op_return was >>> reallowed for relay. Beyond the current situation with the rule comple= tely >>> bypassed this inevitably favors removal once the policy has started >>> eroding. Even if miners had only bypassed to a few kilobytes or whatno= t >>> moving to match that would only result in repeated cycles of transactio= ns >>> that will get mined failing to relay, each cycle favoring private >>> submission mechanisms and promoting mining centralization. Policy is o= nly >>> 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 ra= ndom >>> NFT thing that we'd all rather not be using Bitcoin at all. In other wo= rds, >>> that the benefit of avoiding more utxo bloat wasn't speculative. >>> >> >> While much of this discussion has focused on policy, there=E2=80=99s als= o an >> 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 h= ere >> 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 an= d >>>> time for code maintenance, so we'd rather increase it now to 100'000 b= ytes >>>> and be done with it". While these are valid points, the unknown >>>> consequences that might manifest with such a drastic increase all at o= nce >>>> 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 har= mful >>>> ways, the increase to 100'000 bytes appears disproportionate given the >>>> circumstances, and again non-prudent enough (which is what I suspect i= s >>>> 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-pro= ofs. 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 lik= e >>>>> them, will use something like bare multisigs instead, which will be a >>>>> little more expensive for them and much more expensive for every othe= r >>>>> Bitcoin node operator on the planet because those (likely) unspendabl= e 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 = bloat >>>>> the UTXO set and drive up costs for every Bitcoin node operator on th= e >>>>> 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 wron= g? >>>>>> >>>>>> By "force" I mean in the sense that when a recent KDE upgrade droppe= d >>>>> 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-monito= r to >>>>> watch for screen locking events instead. Fortunately, in the case of= KDE, >>>>> 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= find >>>>> workarounds for their proof of publication protocols will ultimately= lead >>>>> to them using the uncensorable data channel of bare-multisigs, or sim= ilar, >>>>> which have consequences not only for themselves but every other Bitco= in >>>>> 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 exi= st, >>>>> 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 dea= l >>>>> with the unprunable UTXO bloat caused by users posting their >>>>> proof-of-publication data via the uncensorable bare-multisig avenue. = This >>>>> collective cost will actually be much higher than the cost to the ext= ernal >>>>> 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 inst= ead, >>>>> 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 poor quality fee estimates a= nd 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. = The >>>>> victims would be every Bitcoin node operator on the planet. And whil= e the >>>>> core developers have no warranties or responsibilities attached to th= eir >>>>> open source code, I think we would agree that "costs borne by every B= itcoin >>>>> 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 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d >>>>> an email to bitcoindev+unsubscribe@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZu= biNWuHza4E1eKbiW7cG21%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%2Bws= Re3vw1%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-h= C1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%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/CAKaEYh%2BD9y6r0RZJPAGY08KS= c1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%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/= CAKaEYhKdhJ1vP5BBYNAMF7557M9dSoQx8_uqjdAzRM3DgA6ajg%40mail.gmail.com. --0000000000009072a706426e83b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C4=8Dt 30. 10.= 2025 v=C2=A020:35 odes=C3=ADlatel Martin Habov=C5=A1tiak <martin.habovstiak@gmail.com> napsa= l:
"Honest" only refers to miners not trying to reverse the tra= nsactions by making an alternative chain. It has nothing to do with your su= bjective evaluation of the transactions worth trying to censor the "ba= d ones".

Hi Martin,

Small= clarification per the white paper: "honest" isn=E2=80=99t only a= bout reversing transactions. Section 8 of the white paper also discusses ho= nest nodes and which transactions are accepted into blocks.

Satoshi = further clarified standardness:
"The design supports a broad range = of transaction types that are possible, but not all are standard. Standard = transactions are the ones that are designed to be used for the common case.= "
-- June 2010

Per Section 11, the white paper's securit= y model shows honest miners (e.g. following standard operation) outpacing a= lternatives. In practice, miners following a standardness agreement or soft= fork for OP_RETURN would, on affected blocks, earn around $100,000 more,= =C2=A0than under a mixed policy, making prioritizing standard transactions = the economically optimal strategy.

This is because there are a finit= e number of blocks before each halving, so the opportunity cost of non-stan= dard payloads is half the subsidy,=C2=A0which is more than enough economic = upside to offset fees. A standardness agreement soft fork is therefore econ= omically compelling for miners: it aligns with long-standing practice and p= rovides long-term incentives.

Best,
Melvin
=C2=A0
=

Bitcoin was specifically designed to= prevent censorship of transactions that follow the consensus rules. Trying= to go against it makes you a fool at best or an attacker at worst.=C2=A0

D=C5=88a =C5=A1t 30. 10. 2025, 18:37 Melvin Carvalho <melvincarvalho@gmail.com> nap=C3=ADsal(a):


=C4=8Dt 30. 10. 2025 v=C2=A03:= 16 odes=C3=ADlatel Greg Maxwell <gmaxwell@gmail.com> napsal:
<= /div>
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 applicatio= n but because major miners had already removed the rule completely.=C2=A0 A= s such no lesser setting would achieve the goal of matching relay to what w= ill actually get mined and completely solve the bad situation created by th= e mismatch.

If you consider this regrettable it= 9;s worthwhile to consider that a failure to increase it previously (on sev= eral prior proposals) and even a failure to discuss and evaluate it was lik= ely due to the unprofessional and relentless harassment of Luke-jr.=C2=A0 H= ad that not occurred=C2=A0perhaps the limit would have been incrementally i= ncreased previously before major miners on their own found it to be in thei= r interest to simply remove it (as removing it is much easier than twiddlin= g it).=C2=A0 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.=C2=A0 Beyond the current situa= tion with the rule completely bypassed this inevitably favors removal once = the policy has started eroding.=C2=A0 Even if miners had only bypassed to a= few kilobytes or whatnot moving to match that would only result in repeate= d cycles of transactions that will get mined failing to relay, each cycle f= avoring private submission mechanisms and promoting mining 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 wh= atever was irrelevant to the discussion except as a concrete example of a f= ake pubkey user that would rather not do that-- and one that wasn't som= e 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 specu= lative.

While much of this disc= ussion 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 <caucasianj= azz12@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<= /div>
The increase from 83 to 100'000 bytes has been motivated as &= quot;probably we will have to increase it again=C2=A0in the future, it requ= ires energy=C2=A0and time for code maintenance, so we'd rather increase= it now to 100'000 bytes and be done with it". While these are val= id points, the unknown consequences that might manifest with such a drastic= increase all at once may not be the most prudent approach.=C2=A0
Considering also that "the canary in the coal mine", namely Citr= ea use case, requires only 144 bytes to utilize op_return instead of more h= armful ways, the increase to 100'000 bytes appears disproportionate giv= en the circumstances, and=C2=A0again=C2=A0non-prudent enough (which is what= 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@googlegroups.com> wrote:
On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM= TokyoBitcoiner <arthurmyer@gmail.com> wrote:
Questions reacting to text in rep= ly of Russell O'Connor:
  • "=C2=A0there exist some pro= tocols that require":=C2=A0
    • Which protocols?
    • =
Citrea=E2=80=99s Clementine bridge, which need= s 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 t= o their needs?=C2=A0
If we don&#= 39;t support these in OP_RETURNs, Citrea, and other folks like them, will u= se something like bare multisigs instead, which will be a little more expen= sive for them and much more expensive for every other Bitcoin node operator= on the planet because=C2=A0those (likely) unspendable UTXO will have to re= main in the UTXO set forever because they will be indistinguishable from le= gitimate=C2=A0bare multisigs.
    • Do we cater to any protocol that comes alon= g?
      • 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.=C2=A0 Instead = it will encourage them to instead use uncensorable publication channels suc= h as bare multisigs, which will bloat the UTXO set and drive up costs for e= very Bitcoin node operator on the planet.=C2=A0
  • "the folks using these pro= tocols will simply have no choice":=C2=A0
    • Did we force them to use bitcoin for their project?=C2=A0
    • It sounds like &quo= t;if you don't change the code to enable my project, I will be forced t= o 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 r= un dbus-monitor to watch for screen locking events instead.=C2=A0 Fortunate= ly, in the case of KDE, being "forced" to work around their chang= es only makes my life worse.=C2=A0 However in the case of limiting OP_RETUR= Ns, users who are "forced" to find workarounds for their proof of= publication protocols=C2=A0 will ultimately lead to them using the uncenso= rable data channel of bare-multisigs, or similar, which have consequences n= ot only for themselves but every other Bitcoin node operator on the planet.=

It is specifically the externalities caused by th= e bare-multisig workaround that we need to address. If these externalities = didn't exist, then I, and presumably others, wouldn't care so much.=
  • &qu= ot;any attempt to cap OP_RETURN outputs will=C2=A0force=C2=A0those users&qu= ot;:=C2=A0
    • Again, force is a form of coercion. Is the bit= coin code with it's current setting forcing anyone to do anythin= g?=C2=A0
    • Are the external protocol designers the victims here?
      • =
The victims will be every node opera= tor 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-mul= tisig 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
  • "Bitcoin Core 30 is *fix= ing* an existing problem":=C2=A0
    • What problem?
The problem is a combination of protocols th= at require using proof-of-publication choosing to use uncensorable bare-mul= tisigs instead, and/or, so long as this proposal isn't adopted, the pro= blem of users bypassing the network to get their OP_RETURN transactions min= ed which leads to poor quality block reconstruction and poor quality fee es= timates and the like.

I hope you will take these questions seriously. I re= ally 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 https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAx= X_UGb7MBJZubiNWuHza4E1eKbiW7cG21%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 https://groups.google.com/d/msgid/bitcoindev/CAPDT2SSC4p97xp= DUKGE%2BwsRe3vw1%3D1q6-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 https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTBNYUA%2= Bu6qhywK7-hC1CB%2BzqWSU9a8JsOG8nd-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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2BD9y= 6r0RZJPAGY08KSc1s%2BxUZ9UY4fR2f%3DdDc0joXEfQ%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/ms= gid/bitcoindev/CAKaEYhKdhJ1vP5BBYNAMF7557M9dSoQx8_uqjdAzRM3DgA6ajg%40mail.g= mail.com.
--0000000000009072a706426e83b9--