From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 08:38:26 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vE8Fm-0005WK-13 for bitcoindev@gnusha.org; Wed, 29 Oct 2025 08:38:26 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3c9ac0fb0adsf12185fac.2 for ; Wed, 29 Oct 2025 08:38:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761752300; cv=pass; d=google.com; s=arc-20240605; b=PsTB8peiXFfJ0ElrOZFV8PhlOHBiXhC2yydesmhnj6/9qkeNehenEX9vVfm0q/TaEk svF6Ip8I8jD12/ZBq2CzgZvUEL9imV12uDQG2aMkrm1lv/OEB5Z5yjs5/FQLlpbvdF4K avz8KZOVnROKqcse4g9/ZqIx6yMI5kVX9ZAShgPa60VqLhFOef5IKho+K0HCWbNJQByk EbGBpKBX4OBRDyTlm2o4fJTVjWSqvWp7U2T/Tf2kQnP/qV4rzRw3PWYUvNbc9GT4fI2J 9FQ2+wymgOC8b1ZrWOAuPF0nS9u68iOsetfJ8su8nkv1kSqje8HPUV9KguCzdab7MsyX z4EA== 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:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=bVMIrvhCGOZHKI8VqvxN3ElcqBzl56mPBb2ztl0cUiE=; fh=ykgeitxeGHttQzBHwVZImGKoQ77U+EfiJzIUKsxBp9U=; b=XDNFOgmkNZe3FFROMqbQ8XwiGVQmfi/7s89Migxl8UbigEUjdZ2eDEwkMaPd0ATiNx vXzsxu2C6/1onfXmpH0mZCO0YgAgUDZk1p56TZadaW9+9d4VkRUZftKX/fnQfBBzQ7ca 2cEqZZZI5nHh811HpNGBaBGkD0BQRLULoiLHIYUvr0edfxnKinkoQYW1X01D1fyk5hzW e776tUSH2belxMZJX1Qw8sXOxqa6RYUQ5JU5mgpNelINXghVYGKNK3FO72g/5VJEZdzl FSrY/iTHsrjCJHR+Fk+ds4pk64q5uGh/tpX9jxHgXhoTfZ5LyRWKydxc0nkP5KDZW3ao uX6w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=nRVrT+Ya; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761752300; x=1762357100; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=bVMIrvhCGOZHKI8VqvxN3ElcqBzl56mPBb2ztl0cUiE=; b=hJ6YCH100RJStAZUJt+Tt9r/P1MfKmni+ZG6W9mhyY3itxnq0Wiz7Lc3nsP55wMgg5 WYatPPEVNAzu2TuZ42E2T9JFq4Mg1IehMXTFM+nQbyLM2Prp1ODj88Gl7t3X41z22SQw r18kE/cYFf+d7nBF1U6LMkMCU7WAIVQTNncrqzUxzJTv26o6lYugWM0RCLCa6FrbQKID mWMKtYiUE69Mb4f4Cy835V90TcZsEDO3X7vGZvdCZGYYaEt6tH261YUANkrQEB4HUuMR wpSeVNzVj8LXY653Mk6lgaVUdSkMp1PS/KvFgCbiH6k4tMZKM2rwLd0pdb4ElD5sPJBZ GzEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761752300; x=1762357100; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bVMIrvhCGOZHKI8VqvxN3ElcqBzl56mPBb2ztl0cUiE=; b=KO2MeQDMmveClz8QJ8yxuPCY1bJsvR66iO7qsmzNK84RiFX9E6fjF42+y2RbETPsQL hdAX+K/hPrlq/bSZXcfXnN0/tD+GwFUDNie89BKuahei0KJymUcAB9b3xRLCWyrL15PX u+PctybJoJ0mtDrzw6jUrcBsTCveO6tupaBp9TlJJSW6D5Y/5GhTPDxSC7Z/Wx454OzO bqZ11bBhydE6bAwjLfJUWrf0L1zlaypLqA3aypEHvRNf8c1NnkZZqpP+TBVhD/JM6wTO m2LkZCiTGpDJ6ylq8QXcOrrXwgMfeHUf3GA2g48ozYW2bhGuGuQVcliKLzKrXrY2Cunm V8ig== X-Forwarded-Encrypted: i=2; AJvYcCU2nh2g76uDE0NxP+idSC2DlU1ZQoFK1fZ4hYDg4phndFzI6nM+VVZagaJiXyCSZnq7OW5WBXlM0r4/@gnusha.org X-Gm-Message-State: AOJu0YxjrgBix5USnBKS+iQP6Pn5wU9e2xZfu3fdQP2kwHn/Z6/K4RUY 7KRO3kqtpXiCM/RfhFfsJ0cmZZRuabeexi6rEfnkbeD561H+FMFPGBV2 X-Google-Smtp-Source: AGHT+IEloQXGJoby8YMjn0ShiSt8fLY852MV7uxB0kect4VrfbRuPdELDNuzpaQm8ozZqNdTEJAh/g== X-Received: by 2002:a05:6870:a111:b0:395:9e1b:b0e6 with SMTP id 586e51a60fabf-3d74b68e05dmr797888fac.7.1761752299601; Wed, 29 Oct 2025 08:38:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Y2yjfqob24R4SAGd96VGPeEwtizhFgTeW3TThjxvwi4A==" Received: by 2002:a05:6870:e11:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3d592b86897ls813130fac.0.-pod-prod-09-us; Wed, 29 Oct 2025 08:38:15 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXW3xq7iYuGnxjACGeApD03V1mezHvc6xn0CfnBQ7EnCQik6bSBHULOAX4IEuBLmqCmbesgxgZjYYCb@googlegroups.com X-Received: by 2002:a05:6808:509f:b0:43f:78ff:65ec with SMTP id 5614622812f47-44f7a402c61mr1448975b6e.19.1761752295506; Wed, 29 Oct 2025 08:38:15 -0700 (PDT) Received: by 2002:a05:6808:6557:10b0:44f:6c18:6870 with SMTP id 5614622812f47-44f7b05f2d7msb6e; Wed, 29 Oct 2025 08:03:55 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUqc+ZfibyrHkdf9QOJwY1WZuOIs9itIhX7glEcarLE/t4Zofi8Q9AfYhd3HuId2gFf6c2Ng4CES63T@googlegroups.com X-Received: by 2002:a17:903:38d0:b0:25c:e895:6a75 with SMTP id d9443c01a7336-294def2d8e2mr36854905ad.28.1761750234057; Wed, 29 Oct 2025 08:03:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761750234; cv=none; d=google.com; s=arc-20240605; b=EJm0uqBtSY3oObchmjLx4ryWnykkP1XiDUF3pB19qxw2YgA1cK7YfG2MNGnjGGi7KV 6Z0vcLGcOdiJOPw0JHKDTuEPvPRjFXu4U6y5XEZsyEI4wgbZMabx6bqXFtK4PyT2Zu02 6wzW/UE048jD3PioTXA94Xdg/nnxs5LVZKOUOIUl7LPZKJAxckSchksr9vFLMr1E6azY dLLBRGMTyKAVrZKbqriBW+WXf6s11blnB76diCGloS6/nHtXmDeuFQGdb5doKtZUbe8t yLzby7/Va9/RYeuCLtWbX3kbpRZkEuZqXPdq9ySDAwaTFUG/56wy82ADKhfmMQvpHTIq ReKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=deMSApVhvjkmrnfNypD+uHGe6iKfStTrilKlQZNMvdg=; fh=FtxdgBi9YsuQb6LJdcTkQNUvT2S9lQEH8q3hrtQc62w=; b=Gg30FgDDN/XC8iHEJ4oeprbhshb+2IwiOv/LvdmWiJAGVXz1cmUWVlJij6vq5Ns1Qf XA0P62+dVlV0PQUCkpDf60DA6W3xC08gVksz/3jt6fCTP8ciqyZ7p0L5tzW26clO+94f d1ntOslfp9lHf4kRbmquV8P5Q/ze1UDugWoaJWVjZ0XGSra3ByakXU8++2K287iSikPx IuO8RZnUICOSxbp67gDK9CNcsaI6zrcmyy2c0yJEHiH5fWm0ZmtxxKTBF4ccMSLVejW2 AP40A/SqjzVDTpNmfxGaB9F/TbrxAZ70Io83ZdoFRiQ2n6q3bgK1LUw9rm/J5YjgO4xg DVMQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=nRVrT+Ya; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com. [2607:f8b0:4864:20::634]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2949a6febaesi7041195ad.0.2025.10.29.08.03.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 08:03:53 -0700 (PDT) Received-SPF: pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::634 as permitted sender) client-ip=2607:f8b0:4864:20::634; Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-26a0a694ea8so53093285ad.3 for ; Wed, 29 Oct 2025 08:03:53 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUxiNNmCDGd478nkbq8+r2/CpYBhOW65N0ZmRkXyI/e9rXIViMlc1n7uuxU9qbOnpIo89tmdIF3YXYx@googlegroups.com X-Gm-Gg: ASbGncuF2eFJd4ny8xkfvn2gSuidXV5u1DyAMVvWGuO1UuDOip/LZSzZSPNKDnD3tFt JkCtJkGUnXHXopam1W7OhV5+UtaY5v7/eckU2dSah50SIIzDdE0Qf9uNdHqP5/34/vJrRDpi+qs HbHL5A4WXgthKFEUe17WjZW2uQgWZilh/HZtKpbNgA79GPvmu49EcT543h8Iq/WjghrnOOjoRU+ RKTw2cwrOAx27QFD1u0tA07CMtokQZ92Pa9Zdzlwh5+gw6RNIHMtgA7YUYIeQ== X-Received: by 2002:a17:902:cec6:b0:293:623:324c with SMTP id d9443c01a7336-294deea2049mr35745745ad.22.1761750232599; Wed, 29 Oct 2025 08:03:52 -0700 (PDT) MIME-Version: 1.0 References: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> In-Reply-To: <0f35a624-92bd-4bdb-933b-a6fb28b91bd0n@googlegroups.com> From: "'Russell O'Connor' via Bitcoin Development Mailing List" Date: Wed, 29 Oct 2025 11:03:40 -0400 X-Gm-Features: AWmQ_bmEwdzvZDUSN282cvgITYMxLWzbkVwRhLDrkzkLRHZcw606cHuRiXHN6-8 Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: TokyoBitcoiner , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000cc227006424d7000" X-Original-Sender: roconnor@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=nRVrT+Ya; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: "Russell O'Connor" Reply-To: "Russell O'Connor" 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: -1.0 (-) --000000000000cc227006424d7000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 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 wit= h 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 external 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 leads 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. The victims would be every Bitcoin node operator on the planet. And while the core developers have no warranties or responsibilities attached to 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. > > I hope you will take these questions seriously. I really want to > understand your thinking. > Hope this helps. --=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/= CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21%2BDg%2Bi3uA%40mail.gmail.com. --000000000000cc227006424d7000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29, 2025 at 5:45=E2=80=AFAM Tokyo= Bitcoiner <arthurmyer@gmail.com<= /a>> wrote:
Q= uestions reacting to text in reply of Russell O'Connor:
  • = "=C2=A0there exist some protocols that require":=C2=A0
      Which protocols?
=C2=A0
    • = Why does bitcoin need to cater to their needs?=C2=A0
If we don't support these in OP_RETURNs, Citrea, a= nd other folks like them, will use something like bare multisigs instead, w= hich will be a little more expensive for them and much more expensive for e= very other Bitcoin node operator on the planet because=C2=A0those (likely) = unspendable UTXO will have to remain in the UTXO set forever because they w= ill be indistinguishable from legitimate=C2=A0bare 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.=C2=A0 Instead it will encourage them to instead use uncens= orable publication channels such as bare multisigs, which will bloat the UT= XO set and drive up costs for every Bitcoin node operator on the planet.=C2= =A0

Again the 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 to their open source code, I think we would agree that "co= sts borne by every Bitcoin 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.<= br>

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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CAMZUoK%3DuAxX_UGb7MBJZubiNWuHza4E1eKbiW7cG21%2BDg%2Bi= 3uA%40mail.gmail.com.
--000000000000cc227006424d7000--