From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 Oct 2025 13:41:46 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEZSq-0002iY-0I for bitcoindev@gnusha.org; Thu, 30 Oct 2025 13:41:46 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3c9a6b6caa8sf2505031fac.0 for ; Thu, 30 Oct 2025 13:41:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761856894; cv=pass; d=google.com; s=arc-20240605; b=D4TdPVcZl9BwVTQjMoKM8e+kTn2mUh88/IG4T0gJllMj3tb/j/TLrEbzQ7EFaWsQph 1J7EdMc37jYdq6DizxSfgUHhB8jfrkxvUa5sXTxwkWFk8NvhxPcGnRa2ZbxbstktWFq4 Cb2ULJcTaF9wLzx6DfKsJgh4dvBg8kP0tznGCj0xcGR0lCtqtzjkU3wpUnqfFSS0RThi mxarkjWNZWl03t5AZkYxfONoViBbDdkvohaeGoL/OK4sgmNEIFNjTNt+B2MIS8J26pun +lqne945U5vTpkZ9+lb/h1jS87G/nd9GTHX2bPwidDkYLurnkQJni1ud2x6/DFoAsVaS f6bQ== 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=obxjqrvuIcNE+Jc7Xnv8joV6+jtrVfRxRqD5Uh6NOX0=; fh=glwo91bJPzcc0DiVN33dUMoFp3lKikCnMnwp80vlTsg=; b=eTXe03g8+sTnCi9bF/zLREiLI3o/ByTxo1b+nAn3QExGziu5VAfsAQ5C9JMp3X1bnD AnzEh0iiTwAHyWQdLx/D8bx2SfY8jvkTfFAU95fxnNibLNng1y/siqyXAeH5bv5sHI32 vwQxZrPdwHeP95kTeLYyUWCMRRA5w880yPYZbnpD34bG5tvH4YgRpZRuBc8KoNGX+GL1 O51/j8artDSyvLzCS2it1s3kP/MyCOzMuWMJhcoRpI2xKeMlnGlmhVxAFsaMSdaOTyoQ Uas253ebI6xTSo7Yx00M3qJzLl/7H6yXOLKoA2UVnTVeddzcvIvl9Eywsu4d9oumUOe1 4cww==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TRCGnAOA; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::935 as permitted sender) smtp.mailfrom=martin.habovstiak@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=1761856894; x=1762461694; 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=obxjqrvuIcNE+Jc7Xnv8joV6+jtrVfRxRqD5Uh6NOX0=; b=GygwoN58kRS5I5fMVt7r5EQ5ODSVCLadLaS4RpcyUxDdRoQ9diUIQXWWvPR8SdFXAJ g67jwvTWQek+Y6TZpBpgHoZnW6G9Ahj20abhnDSEgLrvA0mU3ert3JL5+mpGOZyiBV0f r74b5H9h5zToPUhgN/ZxSuW00aJRxsi7o2gpa0iH5JyhgIEvdzfTI0//QU0shgTCilKo ijE5munYDR/noPxaU+UMqEAcjyNjirz+w4+0nWx/uGQGfjckFwCK74SWfuJF54lRFXB6 Bk488VbPwpqBXrb1tqDMYDoQ5vGA5zLGtqeH2fCQR8l4MlGkoS5P2VBfN00SORIjZaKV PF0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761856894; x=1762461694; 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=obxjqrvuIcNE+Jc7Xnv8joV6+jtrVfRxRqD5Uh6NOX0=; b=Ttp5sLP9Ee9BscXvjiTUL9ul1cvTEXV/X/masrHkCJ18zuo8MfYgB5bCN0YQlKBMuh 4lATNgAPZ+Io7EBbKeqcKKlqaf31j3o8XJnHUgBMJ6NXu+W00u5tkwv5YepzbKEY5Tm2 9aR60DLGnS96oxMRaGcrLNCn1gZKJkHfeXBXMGhz9AnJ/nPn6ddMvQoi1Ext7GEefhdt 180/eLzhXyLrY1XhGurRiBwyo8+8lLdMsY7F6ROCSyYknEC7p9lkxQeZFOCxqYOX8KNw Ch0M3wHc+pWNxdX6xFzbd04QxDEj4KN5rKA2A9CqIbgMpkIf3nixM4vixeIzKhQvI+yz z96A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761856894; x=1762461694; 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=obxjqrvuIcNE+Jc7Xnv8joV6+jtrVfRxRqD5Uh6NOX0=; b=EpFP7Ekk2WRgsz/GfDWiliQQLkwqSCNnd1gOR6YLAdue4GvDjegarcUI4d5X30FjWr oCQ3CMX3oQvNKDhmbNzO9eeC/bLuqhhjkelmotg4SOf01DiyCjhr1OWu2Kij7hwFG5BG 9wV/lASUMl6AoCfOLw7atx9EwcOlPTSdVDAMe9tXPjBWyq4SOXaAIcQB/j1abz63wmrU 0DBA4yfji+7/+tuO2eX6Fa152bLwMVV8my2uWQzF6hdu4by41y8zt82LMjZNN4QLKL0p RAIIexqBRbez+gCr2H7RkVw4+bJ/BUMsOSC3bYM9r2FXOuHsWHjG0nKN+6Z2RvDhN5R/ jxig== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVVfbZgWo+ayNz0C7lzpspshAZ4e+QZ5WVolNL5d0Sftg4+9pZ3YxRYXG+qI4/oTM7pzs5wWV+ITrFb@gnusha.org X-Gm-Message-State: AOJu0YxJfXmrJtUv3uwb2u7ysGRg40siTORe4CrmBS4y6ypY4niWULVB EhBrol0xvzDiTCgEpqPMxxwjQl1NR26ObrdEhL4thCx8aFkzWs8JqPgh X-Google-Smtp-Source: AGHT+IEyVxdeC+lUik+wmISuk0psR37Xxg0turBdb0Hnq2bTlss6pIvdGywppsVt53x9oFGyLVhYHw== X-Received: by 2002:a05:6870:d284:b0:3d1:ae96:e72c with SMTP id 586e51a60fabf-3dace49469bmr495346fac.27.1761856893864; Thu, 30 Oct 2025 13:41:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YmspBPF/eKA1EcYq37YaxwQg/QzqhXoLxJ8gGeICMGCA==" Received: by 2002:a05:6870:458f:b0:315:8af6:e4ed with SMTP id 586e51a60fabf-3d8bf3e53b5ls778704fac.2.-pod-prod-05-us; Thu, 30 Oct 2025 13:41:29 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWVqWTWK/FNXvqR6eadGUKnHTaE4D79nh07M8Hr/DeLgX9ginyrLt8+itlku+jbLWwB1eDdtX4omuVZ@googlegroups.com X-Received: by 2002:a05:6808:4f23:b0:44d:baaa:c53e with SMTP id 5614622812f47-44f95ea9590mr482925b6e.25.1761856889899; Thu, 30 Oct 2025 13:41:29 -0700 (PDT) Received: by 2002:a05:6808:aab:b0:442:1282:b401 with SMTP id 5614622812f47-44f994aeb87msb6e; Thu, 30 Oct 2025 12:35:56 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCU/L5eGsPMgWidcNQfmRRb9ouIuDetW1UiNabBYSjuTyUEK4XcZyJ3L5o32xK/ONQaqq9Ac6YzJPUBw@googlegroups.com X-Received: by 2002:a05:6a00:3cc8:b0:7a2:6caa:38b6 with SMTP id d2e1a72fcca58-7a779bf3707mr679603b3a.29.1761852955023; Thu, 30 Oct 2025 12:35:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761852955; cv=none; d=google.com; s=arc-20240605; b=UP3BCjdrflWYTUBrWOhnh3qOsEtODTUeY8W5v7RsI1Oax7r5aBobuxXkg9T8E5A4Bh Z3s2tLjsD7uG5GLH5/bxpVmhTTjylvc/nLKJyVookNK+wAZVuhk24xLIdcJcbdKR3oS0 53/t6RPRVzfMjKfYCc2Jp7K2zDoJhhp8v42R+yv6HDoKBNxRIUf8Vr++pHuisXL8H+cv gt3wCv93+VRl6fHJGL4LD+2pqmVgTLbp5s3UWia40Lab5CsZn0XJoda9ysOvR/xE0mJ0 +g+xaEC+VrnA4sQleP8/z8Oiv24cykmcYJFXRbh4twBbqr4WorkcJ+GgKmvWvLSqxOza fwFg== 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=CMFW9mHeVLV1zzhAGhygusRAHrBiRTcVQpLAYG3ygC4=; fh=lfRoH0k6EVXm+VEuvQpPwKgiGBfe5k4mBeHpctYsZSU=; b=a1DMpxfRDiEQaatVNrFhJFQH0yZ8wbUC/mv7hiE6ULwFnk38eS1Ujw+kKgrIY8GRJ8 /LgeOD0vPMhPkUAZv/ZVO4r/1++PwRSAgm2hShOnlyL07keK8FYvOjySseT93jWjeZ9X CxTfV6nNsX7QoO6hpFor6Rv9YVQbxoORKfqsZk/nfnx+rTuPVvtWEd0d8k+W/iDpWKKI /u2nYbWMBIQST8W7KQT9GJzKYVUWlL708LUwqWYHakPDu1mudnevJvCACb2E/6xUzOUt lH7KTWUHhat8rP/p02M3mFfN4EUem1qRmY35o2yllnFzxjzNyK/L19/EzHPOtLTtoxya tBjg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TRCGnAOA; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::935 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com. [2607:f8b0:4864:20::935]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7a4156769f5si837728b3a.5.2025.10.30.12.35.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Oct 2025 12:35:54 -0700 (PDT) Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::935 as permitted sender) client-ip=2607:f8b0:4864:20::935; Received: by mail-ua1-x935.google.com with SMTP id a1e0cc1a2514c-932cb562289so491769241.3 for ; Thu, 30 Oct 2025 12:35:54 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXP0TRIvuMAnN2z3UUupPaeUEfw4HQdPASQ54GiYbydZNwVxiRz5yDwv4f0wvz28zuIMYhGHC/fHA7t@googlegroups.com X-Gm-Gg: ASbGncuDUIjYZIcAUgnbuCmA945pZv7I53aCprN21JVW5QREYpwQYx5/O6duGBD6k8P g+uVxJu3mkOP7BlMCUvrxzENUZlkqLINMf73rigUsIvWjEEIey9avI+sTmVPQC0So0e2CXS/7p0 RR28WCAdA/JfNnpWLjEk3rQkmXhOeFI1E8PV2Hdh9ZI+Vl5on4CMAcIOsKw6MY0QCcc1x8OYRj8 wYCxp7PMhiOms/EpTq0HiZMRSC2eGhry1M7ciKvW6JnfimsXyl3TrK+KMX6/jolZHFvbNc= X-Received: by 2002:a05:6102:3050:b0:5db:2867:5699 with SMTP id ada2fe7eead31-5dbb1383f0amr204519137.44.1761852954422; Thu, 30 Oct 2025 12:35:54 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Date: Thu, 30 Oct 2025 20:35:44 +0100 X-Gm-Features: AWmQ_bmGCgXkE4p0NmEHXDBWKzXQH_b0bqsDEl7xSY30ybdVlr97Yqz4NvhJpYI Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: Melvin Carvalho Cc: Greg Maxwell , yes_please , "Russell O'Connor" , TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007eb0dd0642655bfa" X-Original-Sender: martin.habovstiak@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TRCGnAOA; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::935 as permitted sender) smtp.mailfrom=martin.habovstiak@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 (/) --0000000000007eb0dd0642655bfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "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". 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, bu= t >> 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 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 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 lim= it >> would have been incrementally increased previously before major miners o= n >> their own found it to be in their interest to simply remove it (as remov= ing >> 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 wo= uld >> have happily told you this in 2014 or whenever back when op_return was >> reallowed for relay. Beyond the current situation with the rule complet= ely >> 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 transaction= s >> that will get mined failing to relay, each cycle favoring private >> submission mechanisms and promoting mining centralization. Policy is on= ly >> 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 ran= dom >> NFT thing that we'd all rather not be using Bitcoin at all. In other wor= ds, >> 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= 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 a= re > 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 he= re > 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 w= e >>> will have to increase it again in the future, it requires energy and ti= me >>> for code maintenance, so we'd rather increase it now to 100'000 bytes a= nd >>> be done with it". While these are valid points, the unknown consequence= s >>> 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 harm= ful >>> 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-proo= fs. 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 b= loat >>>> 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 = 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 simi= lar, >>>> which have consequences not only for themselves but every other Bitcoi= n >>>> 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 exis= t, >>>> 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. = This >>>> collective cost will actually be much higher than the cost to the exte= rnal >>>> 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 inste= ad, >>>> 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 an= d 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 while= the >>>> core developers have no warranties or responsibilities attached to the= ir >>>> open source code, I think we would agree that "costs borne by every Bi= tcoin >>>> 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, send >>>> an email to bitcoindev+unsubscribe@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZub= iNWuHza4E1eKbiW7cG21%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%2BwsR= e3vw1%3D1q6-72UJHvzMPoTau7A7g%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/CAAS2fgTBNYUA%2Bu6qhywK7-hC= 1CB%2BzqWSU9a8JsOG8nd-WsDLCQ%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/CAKaEYh%2BD9y6r0RZJPAGY08KSc= 1s%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/= CALkkCJYEQAnj4MVVXnr5ufNz_SXFTg5s4JW5Uud2wipzzfQrXQ%40mail.gmail.com. --0000000000007eb0dd0642655bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Honest" only refers to miners not trying to re= verse 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".

Bit= coin was specifically designed to prevent censorship of transactions that f= ollow 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:
I searched for the source of your quotation and am unab= le to find it, but its author appears to be confused or missing a complete = understanding.

The particular size isn't motiv= ated by application but because major miners had already removed the rule c= ompletely.=C2=A0 As such no lesser setting would achieve the goal of matchi= ng relay to what will actually get mined and completely solve the bad situa= tion 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 e= valuate it was likely due to the unprofessional and relentless harassment o= f Luke-jr.=C2=A0 Had that not occurred=C2=A0perhaps the limit would have be= en incrementally increased previously before major miners on their own foun= d it to be in their interest to simply remove it (as removing it is much ea= sier than twiddling it).=C2=A0 The consequence of failing to be pragmatic i= s the loss of that nudge.

That said, the economics= and incentives of bitcoin are such that the removal was inevitable once pe= ople 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 completely bypassed this inevitably fa= vors 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 repeated cycles of transactions that will get mined failing to r= elay, each cycle favoring private submission mechanisms and promoting minin= g centralization.=C2=A0 Policy is only at best a nudge and a fragile one.

I think in many people's view-- certainly in mi= ne-- cirtia or whatever was irrelevant to the discussion except as a concre= te example of a fake pubkey user that would rather not do that-- and one th= at wasn't some random NFT thing that we'd all rather not be using B= itcoin 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 <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/CAPDT2SSC4p97x= pDUKGE%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%= 2Bu6qhywK7-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/CALkkCJYEQAnj4MVVXnr5ufNz_SXFTg5s4JW5Uud2wipzzfQrXQ%40mail.g= mail.com.
--0000000000007eb0dd0642655bfa--