From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 18:15:30 -0700 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEHGD-00038c-9u for bitcoindev@gnusha.org; Wed, 29 Oct 2025 18:15:30 -0700 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-44dbaaac901sf192112b6e.3 for ; Wed, 29 Oct 2025 18:15:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761786923; cv=pass; d=google.com; s=arc-20240605; b=eVWzdII0r0hHUNb+wLiKd3lh3zPVlZmtBA1Pdp0gJucq2UGR8KtKKF4BGsMOUiO+hU IBfRVpjv4OempHExmSpdHtCdl+Gs9GkW6DqgKbvDSW5MqF8CBF4GZbCF1Et3/aW5gbjV TnVP0/m+zAu4QBIJCTzxjmKcjcMeCWpaXrCFJwdakUuYX0WMk6QhdcF+AjgYdT2psO52 D0mgnq92SgLLh9TJ0177K4ry6iZVNtPQkbwhyfRPn0OJ95fVfPduO8PBqiGPUBj0zt/j WOO8MCAdnuLtJ2BBT0eWF5UQKeVleWArQY4fEQ2pYaIneIKqTD0PmGJYwM+VDaCRjPB2 KzQg== 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=kVQGa92FTnQba1G4s8WaQG5Q7KBe2b6LI698C/RKyEI=; fh=8ezPuFYKaI26OAoDTPWk6jl1h2sSJr1giXMLv6Z4/+M=; b=Zh+Q0aKLfnIqNiJ9n8Gy9P4oe0JtmOJBa4zf2Id4/njXIL5a9lX+3+cULgvMkf4JPs RgLk6JQdw1kMnyi4SkLTwtIClWXl58lmH5sSkgWoN9m4tIPULcXUxOrG8np7V2AtZnue tXlAAcSVCmO/vquXdY27BdpOQcFfsVLgDnIV6N9gqpyjKoCklgJWZYatwTOHlsxIb5BU qca/WxpHQz0F7mhwKApv9Ro5Rj208cUwmcPoisCLhYZkgwcMaKAkGIu4LluTNilWjYlF CeqUy9SESBDq2hO6nRTceRq3hN0ZhU+rCaq+gcTCdEW9dFwgnrmTZN9814gzO4+Cl4ve b6Jg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d0ifMPfC; spf=pass (google.com: domain of caucasianjazz12@gmail.com designates 2607:f8b0:4864:20::1131 as permitted sender) smtp.mailfrom=caucasianjazz12@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=1761786923; x=1762391723; 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=kVQGa92FTnQba1G4s8WaQG5Q7KBe2b6LI698C/RKyEI=; b=wzrcMvDasICL+YE1MnI7LU5ekWCjVUnwEYlfN6dfSgCWemoR+kOJtjpim1wtvU2GE8 1zisqfJvEJ5iGK01nxevyWQaqidy0firrAkEVUMD8/2xmtVK5wlFBqQybiAhj1vcKWSC sy/Obl+oPURXZJ6xAohat+cyGX2DqE/63VKPoxY/04JJJA2NXk2Da+hO0CloPBRIsL5z 3nri4e0O5/Me0HRofYBIWoUkYjyyRMQXkUM70lTW6t2JtGoPlC72U+6nuzSJIj0RXER9 Ha7lBoOoLU4R+GyNwZjHezaN4Swv249ahZMxaay79blRspMvEpwGvKcFQ0waPcaCZIsf VnFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761786923; x=1762391723; 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=kVQGa92FTnQba1G4s8WaQG5Q7KBe2b6LI698C/RKyEI=; b=gkbdufk4sXb8Ww3Cpb3y8Nx5uBaaTw3V+pa4xEDZ7re89VU1gxv48bNG3U2x7yqhtc YZIHl7JwHjy0VcpvwFOnnybHRATMbU6Z7qiD9oC3itHQnqjnv7KU1NME/00z0T+I0aIa XyeDbKaAYDgwae5epHWXz9IBjkgIHPBNcjTbYQN81CuQThgn8XyYgFKKz2WgJAT6Mxc8 Gw+5Q8oOW0u+JyI4a1FSuLICAANCp/eu8MgICT+eFkvyVQdrG8kWePAGmgIVhbW8ejWI BozKHdgRp0GRw2bRgJrI8WGSK1pYQiSRRj+xVox/NrFsvrUsTfHUA+jz28ixWCSe6QPc z9XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761786923; x=1762391723; 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=kVQGa92FTnQba1G4s8WaQG5Q7KBe2b6LI698C/RKyEI=; b=jZqIYRPwcNZ0kkY+NHB/8kxeUSldOpITfue82lQivsEOj5vqRphiupph5q0Gd5/XE0 Pv8+L029L7O6dl5+fzkaD9GjTLI1brqi8cgE+PogynVtjpfrYYtdeHO9xi/QKohlDzUU qXrimZdUjGD4U3BfeLVrmWoS9BtS14GgMeIwvg2SxwtrJNs92H7OjkGTcd5WXfbYoEIX lEQ0C+nWISM011gexSm1ZYv380cJgFbJpFKq765HhtXLk23LPii2Fht3DrjCDrjWHyo8 vAhVEQcBt5cnbgMIlUDloil2NkAt9fNMW2JP3dbhBqhL608I8pNsTNUXM/F6AIEnvxdF sfRg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVgr+YrJ/UOgtvuKg58OoZR80fMXJp6MqUOE4tnUOO1fj0oHg7lo3B+Xd6r/Hz0vFAcqYxHY+JZtJx9@gnusha.org X-Gm-Message-State: AOJu0Yz9fj2/rIWuvjjl7tDRSzHHxEzt7taqhGIlqlDv14RCkDN9Bw5B leGTUl99Qxpf4+0XfKPAErpuLiwXQyvKFCQHMxo+iEVRFUsA313HhUBp X-Google-Smtp-Source: AGHT+IGSpxEzTtQg3t+snD7UVB6vL+DHDGGJ8V9Hr3znq1vsjvPQJtmjDBv3scaDsVoB+TeyCrJ+lg== X-Received: by 2002:a05:6808:14d3:b0:44d:a99e:45ca with SMTP id 5614622812f47-44f7a3dd465mr2567935b6e.13.1761786922880; Wed, 29 Oct 2025 18:15:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YHZOg77aTFvIRNVdFs2CBj4mH62SpVohdysaho2uI6IQ==" Received: by 2002:a05:6871:54d:b0:3d1:fb8f:5574 with SMTP id 586e51a60fabf-3d8bbbf6786ls179906fac.2.-pod-prod-02-us; Wed, 29 Oct 2025 18:15:18 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVWnzPcQx1UwNuW9wqVAm4+zw3ELwiC2Q6K/C6PDUwhmOmkHw0RkEKj5SNyzVfBsWICJDN82W/dHUxU@googlegroups.com X-Received: by 2002:a05:6808:2198:b0:44d:8e2c:41c0 with SMTP id 5614622812f47-44f7a4c92e7mr2892646b6e.35.1761786918805; Wed, 29 Oct 2025 18:15:18 -0700 (PDT) Received: by 2002:a05:620a:a819:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8a8ee7a603cms85a; Wed, 29 Oct 2025 09:10:39 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVFwTcBdJP1AGrtHTAn0r8LMbg+zt3SUJc6Dt1kzKjCY7SdLIshpdsIw81+0XR/1FCF7X/Kv0Iu1oo4@googlegroups.com X-Received: by 2002:a05:6102:dd1:b0:59d:b0f7:664c with SMTP id ada2fe7eead31-5db90671359mr1151318137.35.1761754238606; Wed, 29 Oct 2025 09:10:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761754238; cv=none; d=google.com; s=arc-20240605; b=HUQ+Fy3CnLI2rQZAZPEtuImYGKJRmrt/Id0mt9tLKZMJy9E4ScnSlPYZ5ldtKJCsmk ABZNyS3T/s1Atu6fPE1fuoPLjFhAADEnOUis832j9o1ce0yLJ7hCPV5+CxrSwciSGgkD 9SzJc0OhIyIEk+AfelFOrNvkyQJHn7QaGOQWVrDlbjOkdWWijM8zNZa2fTrBVBHhCLzl oDH82oYCD+dJmRdWYhCspLFcr+LJEueCVPHO+I7e6WKYmUsgnPQIP6g1q5Pi00AsDAdS f6xx1T9x7gzcdshlb2/m+BX7b8cLEHec3Sqf6WQ/XiW9jaUwdxZ7Gv47QVkrh5CVoPCv UpLQ== 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=UePW3rn41OST1muqEO9cZMIruTLX5xzH0V9wcEr0Dac=; fh=9NJiogexwCyUDOn+wh+xVU3O19aUmHS6IvZPRWWtACE=; b=aC8bNHxKeTnVZwGH+yi/XR7YFQ/ZjThzSGvxSBy0ojPDfQgiq3Nu8KBqIQcqDB8+ZC H+ZCxJM32WffU456M4sug+0qqW9dtY4yJAOaHIRkFdsVJU9RhJ7Nr7SnuEBU4MYyiIYC p7wJudWsz5eG87a4Y4ItljpJQeagrGaQXLEQBVOTPTdzEiWTVUgDoZuWjGsBjTwjkzpx i1rfCxBQsO08wmgR3HDqAyXD63DgxrPOdTemPUl/t8KgZ7QN3P5L4Q2dNi8oqCVUqkmi 3UXBhKOmk3Lc2yYlx1D9FTrRzbX7RcNDlji2d4sH5AR6J8ve+0s+WXSf5Hrs5N6gXAJV Yxmg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d0ifMPfC; spf=pass (google.com: domain of caucasianjazz12@gmail.com designates 2607:f8b0:4864:20::1131 as permitted sender) smtp.mailfrom=caucasianjazz12@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com. [2607:f8b0:4864:20::1131]) by gmr-mx.google.com with ESMTPS id ada2fe7eead31-5db4f436468si241375137.0.2025.10.29.09.10.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 09:10:38 -0700 (PDT) Received-SPF: pass (google.com: domain of caucasianjazz12@gmail.com designates 2607:f8b0:4864:20::1131 as permitted sender) client-ip=2607:f8b0:4864:20::1131; Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-781421f5be6so967457b3.0 for ; Wed, 29 Oct 2025 09:10:38 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUlCH7g7jxnImE1uB+PtMIcrHHgFvyc84LQzDfKRaJMp+RyOMYRrHgvj58PFPD7Eg/nki8cypY5ACYZ@googlegroups.com X-Gm-Gg: ASbGnculdd1ThT5HJFB/efEf0HCRE7O2g8b7CWQ58mbE68/ZvAvIpeuoeIR/MhNDhZO hVNpxy2x9URbOTsCFU209OwF++cFRoYICYVg3gpNbU0s5Ls359Dg4RFZmnt6MvHnaopzubGbZYu jBcNjzRfVU9Ccv/mfyj+Z90S1xyWAiyXkerzJww+hmtinwi7PiGIWxrbfvMbdACX9Dt4Qw1RfdL 0HZADJ4EpVpE+LmCMw0xQR9Y/eMSmKl+ur2D/Fk2TGZO9ID+k38wERqTtM= X-Received: by 2002:a05:690c:4b88:b0:748:9715:f672 with SMTP id 00721157ae682-78628e679dbmr35372757b3.24.1761754237979; Wed, 29 Oct 2025 09:10:37 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: From: yes_please Date: Wed, 29 Oct 2025 17:10:26 +0100 X-Gm-Features: AWmQ_bntHp_CMFJEttBIY3PC8aNDrdwFvxf9w-ANk1AoJN43riQMrSVkwjELt1I Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: "Russell O'Connor" Cc: TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000894f0d06424e5fc6" X-Original-Sender: Caucasianjazz12@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d0ifMPfC; spf=pass (google.com: domain of caucasianjazz12@gmail.com designates 2607:f8b0:4864:20::1131 as permitted sender) smtp.mailfrom=caucasianjazz12@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 (/) --000000000000894f0d06424e5fc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Perhaps we can find a meeting point if we focus on the max size of OP_return ? The increase from 83 to 100'000 bytes has been motivated as "probably we will have to increase it again in the future, it requires energy and time for code maintenance, so we'd rather increase it now to 100'000 bytes and be done with it". While these are valid points, the unknown consequences that might manifest with such a drastic increase all at once may not be 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 harmful 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 Deve= lopment Mailing List wrote: > On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM TokyoBitcoiner > wrote: > >> Questions reacting to text in reply of Russell O'Connor: >> >> - *" there exist some protocols that require":* >> - Which protocols? >> >> Citrea=E2=80=99s Clementine bridge, which needs 144 bytes for zk-proofs.= I don't > know anything about their protocol beyond that. > > >> >> - >> - Why does bitcoin need to cater to their needs? >> >> If we don't support these in OP_RETURNs, Citrea, and other folks like > them, will use something like bare multisigs instead, which will be a > little more expensive for them and much more expensive for every other > Bitcoin node operator on the planet because those (likely) unspendable UT= XO > 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-lik= e > protocols. Instead it will encourage them to instead use uncensorable > publication channels such as bare multisigs, which will bloat the UTXO se= t > 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 th= e > 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 f= or > 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 workaroun= ds > for their proof of publication protocols will ultimately lead to them > using the uncensorable data channel of bare-multisigs, or similar, 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. Thi= s > collective cost will actually be much higher than the cost to the externa= l > protocol designers who only have to pay a few more pennies for their > transactions. > > >> >> - *"Bitcoin Core 30 is *fixing* an existing problem"*: >> - What problem? >> >> The problem is a combination of protocols that require using > proof-of-publication choosing to use uncensorable bare-multisigs instead, > and/or, so long as this proposal isn't adopted, the problem of users > bypassing the network to get their OP_RETURN transactions mined which lea= ds > to poor quality block reconstruction and poor quality fee estimates and t= he > 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. The= y > will just pay the extra pennies to publish using bare-multisig. The > victims would be every Bitcoin node operator on the planet. And while th= e > core developers have no warranties or responsibilities attached to their > open source code, I think we would agree that "costs borne by every Bitco= in > 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_UGb7MBJZubiNW= uHza4E1eKbiW7cG21%2BDg%2Bi3uA%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/= CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D1q6-72UJHvzMPoTau7A7g%40mail.gmail.com. --000000000000894f0d06424e5fc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

Perhaps we can find a mee= ting point if we focus on the max size of OP_return ?=C2=A0
The i= ncrease from 83 to 100'000 bytes has been motivated as "probably w= e will have to increase it again=C2=A0in the future, it requires 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 valid 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 a= lso that "the canary in the coal mine", namely Citrea use case, r= equires only 144 bytes to utilize op_return instead of more harmful ways, t= he increase to 100'000 bytes appears disproportionate given the circums= tances, and=C2=A0again=C2=A0non-prudent enough (which is what I suspect is = creating most of the debate at hand).

caucasianjaz= z12=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 29, 2025 at 4:38=E2=80=AFP= M 'Russell O'Connor' via Bitcoin Development Mailing List <<= a href=3D"mailto:bitcoindev@googlegroups.com">bitcoindev@googlegroups.com> wrote:
On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM TokyoBitcoiner <arthurmyer@gmail.com>= wrote:
Question= s reacting to text in reply of Russell O'Connor:
  • "= =C2=A0there exist some protocols that require":=C2=A0
    • Which= protocols?
Citrea=E2=80=99s Cle= mentine bridge, which needs 144 bytes for zk-proofs.=C2=A0 I don't know= anything about their=C2=A0protocol beyond that.
=C2=A0
    • Why does= bitcoin need to cater to their needs?=C2=A0
If we don't support these in OP_RETURNs, Citrea, and other= folks like them, will use something like bare multisigs instead, which wil= l be a little more expensive for them and much more expensive for every oth= er Bitcoin node operator on the planet because=C2=A0those (likely) unspenda= ble UTXO will have to remain in the UTXO set forever because they will be i= ndistinguishable from legitimate=C2=A0bare multisigs.
    • Do we cater to any p= rotocol that comes along?
      • How do we choose which to enable, and whic= h to discourage?
Clamp= ing down on OP_RETURNs won't discourage the use of these Citrea-like pr= otocols.=C2=A0 Instead it will encourage them to instead use uncensorable p= ublication channels such as bare multisigs, which will bloat the UTXO set a= nd drive up costs for every Bitcoin node operator on the planet.=C2=A0
  • "th= e folks using these protocols will simply have no choice":=C2=A0
  • Did we force them to use bitcoin for their project?=C2=A0
    • =
  • It sounds like "if you don't change the code to enable my proj= ect, 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 i= nstead.=C2=A0 Fortunately, in the case of KDE, being "forced" to = work around their changes only makes my life worse.=C2=A0 However in the ca= se of limiting OP_RETURNs, users who are "forced" to find workaro= unds for their proof of publication protocols=C2=A0 will ultimately lead to= them using the uncensorable data channel of bare-multisigs, or similar, wh= ich have consequences not only for themselves but every other Bitcoin node = operator on the planet.

It is specifically the ext= ernalities caused by the bare-multisig workaround that we need to address. = If these externalities didn't exist, then I, and presumably others, wou= ldn't care so much.
  • "any attempt to cap OP_RETURN outputs will=C2=A0fo= rce=C2=A0those users":=C2=A0
    • Again, force is a form = of coercion. Is the bitcoin code with it's current setting forcing anyone to do anything?=C2=A0
    • Are the external protocol designers= the victims here?
The victims w= ill be every node operator on the planet who has to deal with the unprunabl= e UTXO bloat caused by users posting their proof-of-publication data via th= e uncensorable bare-multisig avenue.=C2=A0 This collective cost will actual= ly 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 *fixing* an existing problem":=C2=A0
    • Wha= t problem?
The problem is a comb= ination of protocols that require using proof-of-publication choosing to us= e uncensorable bare-multisigs instead, and/or, so long as this proposal isn= 't adopted, the problem of users bypassing the network to get their OP_= RETURN transactions mined which leads to poor quality block reconstruction = and poor quality fee estimates and the like.
    • Is the bitcoin code responsib= le for fulfilling the needs of an external project or protocol?=C2=A0
        If yes, why?
Again t= he victims 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 = victims would be every Bitcoin node operator on the planet.=C2=A0 And while= the core developers have no warranties or responsibilities=C2=A0attached t= o their 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 qu= estions 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAPDT2SSC4p97xpDUKGE%2BwsRe3vw1%3D1q6-72UJHvzMPoTau7A7g%= 40mail.gmail.com.
--000000000000894f0d06424e5fc6--