From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 05 May 2025 02:27:31 -0700 Received: from mail-qt1-f192.google.com ([209.85.160.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uBs6k-0007KW-Hz for bitcoindev@gnusha.org; Mon, 05 May 2025 02:27:31 -0700 Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-4770cbdb9c7sf96671351cf.1 for ; Mon, 05 May 2025 02:27:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746437244; cv=pass; d=google.com; s=arc-20240605; b=O5JWCfGpzGLhNadgOtut1ypyD24VV29GIOV4GodvXX3mZ8DGKRHVFrYE3He5N4aQtp 9rke56GkR4Nxr32B1rYzlGBvJnBSk2KAIRIiBucJqwkf4vKgEEEsf+3GbMR8qQl1wfcd SMflDHQFVDeyvdvluq9jC81xVBku4expGOCDPqBaHkhKULVxJZTJ7Gr6UBls6zGRjNrW sMTXTR6Fs9BniyZXqq/ThJOnZxBbRpWz260GethnHy+Uqi59yaGUyfzSTi2w82ZyuyPJ 1HX/lPq3JOpy9NN4FOhY68O6wDv1AigjjrJeH3+BbYbM8HdP1+ckIhEZ9AAzpMytpPTq fJxA== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=yB937YbEOEiSjdEySxIfcBZwNZqsBUpUtcBPDtxRh1w=; fh=LdS08ec/d/w57NFeVJblRN8Exn0W+gg8aAxSK+ffyHk=; b=aOwPfOZX69Eh0O/aCb08AH3vpzZoneAwI2y3UR4RmuCzlG5x1lYUutlW5VsQwD+t2b GtNGaEuGATMrqsKUG9naRErqGXfTbBJGyLvR+XuGANyLdtoYVS963nx1bdQHLrVgtEVr vhLmI7ujCcf04ta8IZ2RSVm6WdW1Nf51tKh8eTpJhxyxd9iOxJroltW9hXaTGYJBoTLD pBWrdjBxOeb+PBHaz9af/xC9HYezsfNf1cG9tKaLuth62iW19ma5TEEBVu/kpzUMlqi2 KeNTOMOd15tj4AW+MvBtUNHGx7gLOTatDyFEElwzcrOoKp7FpATtYu+Ya263TX97vmH5 /uMg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bx7puZo6; spf=pass (google.com: domain of bitcoinerrorlog@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=bitcoinerrorlog@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=1746437244; x=1747042044; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=yB937YbEOEiSjdEySxIfcBZwNZqsBUpUtcBPDtxRh1w=; b=MCnIFNHLHSV2N542g79gjS6qWBPJTnTvJbdQ5hclGjJI7NuHkDGOTBPweo0xtzoH70 U/POPwGzwTdjY0k/U2nqK/HFujn14f3KEhPNDJGbt3UAT6HusSuMdCzhlhJHGB/FieWq GMTBtTyKPHgoDJaUlAddrRzUc2spl+Dr9vE7KZ5K0nnzEkvI3qqudR5+70S7OBnpDLKz kfzHL17QPOAtKbe2EqzKpJYspmIox4h1izRgctoY90c+QnL+Hk6QjwFZjchYpYDGjEe2 Hqg5f/zWYNh0/rPoDLdquKT1q4AA2y5VzyKFZh7K0uoH79ARRm+QELBiiwSlh+Az78g3 5ybQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746437244; x=1747042044; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yB937YbEOEiSjdEySxIfcBZwNZqsBUpUtcBPDtxRh1w=; b=hZOLHqMItxWgJM3la97E4gLqjTZz2h67Lwtq8q8fl1IAIBLnAxDPUD50C6D8MoXd+0 MyAnSrfNIRsriiAYjAYX7YGdOGB6f5MIQeKeggD4ZMhy+hW3oQ6pCJiQfjOGhKyDCizu 0P3/9QbNUQWW0FFjf/Vz+QUpfkrk46+bprVU+uAL5acsw80Q2+rlkxgWxJ0bhxvmPWGw QLlmY9clhqaensRzbYWoPLweo8+1vSEFsqWf8AFBLOWaEncZY0wXVoFIIblu1bWFJRVc 0hgquzMlnKxW1avBmTDq8JlKGOSsJ2JNjECCYV+xHhNlbsdWWRhSAwI+Qfs9KemHZTza UaaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746437244; x=1747042044; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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:sender:from :to:cc:subject:date:message-id:reply-to; bh=yB937YbEOEiSjdEySxIfcBZwNZqsBUpUtcBPDtxRh1w=; b=VGKh66PvINWEsdPLazeMhJbLW7zUDdfzJ24/Fkzf/d7hLk+/N94agz8cFZXyII2A+o MuwQLK90mNaSlo0rVeNRsqQ3muKqHe64/os0JtCI89HF99rQpPoX4a1tak6OCr5skDb1 /55HjJ2SlIAkiq33Xft9+JFdCtPyy9Z//sMcFST3zjnKdWKomwz50la66Y+O7HEZavSm NpzQw8XJudGDEA0ud7lpHQJfF6gdorXkFLCAPGYDnS6PxdS0dhzRdnFM+NETqOh6qB6l ZBnBjneDkQFeGWM9XWq45MB7fhosxwKmpxmQEnQL3p65SLf4KYk9UmtCNkeVR9JFT2bS FBZQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVtrBvP+EZRRM/fuM4VKCaWFWK5NValiCEQi/8jx5uEu6GHFnbooVo/B4c4bnlF7J6sgfeN6PmDZJVq@gnusha.org X-Gm-Message-State: AOJu0Yxa5qxJFLYhOnH7RpJfqUSGVtS2dEKAfHry1U1eXM9BtKcfflYa FJ0Sjhz/s0Mg0Q3BbTZ4EV+X+cToO4zskDr1qva22xPEayoPqsdU X-Google-Smtp-Source: AGHT+IGjI9zt9lqi7TwxZcrbMOd1EbtZQssDHZYCBa+Waqb9ACE3v4zcJapDM72aKGuVLmls6c1grQ== X-Received: by 2002:a05:622a:199c:b0:48d:e36e:9836 with SMTP id d75a77b69052e-48de36ea26cmr82839001cf.35.1746437244186; Mon, 05 May 2025 02:27:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEiVUWhL94AZ6YI+vV+3jjjWuQ8ehCayFckGNxH8/NutQ== Received: by 2002:a05:622a:68c6:b0:477:78b2:dc08 with SMTP id d75a77b69052e-48ad5b1749dls40360231cf.0.-pod-prod-01-us; Mon, 05 May 2025 02:27:19 -0700 (PDT) X-Received: by 2002:a05:620a:3782:b0:7ca:df98:2d7 with SMTP id af79cd13be357-7cadf9805d4mr951289785a.25.1746437239346; Mon, 05 May 2025 02:27:19 -0700 (PDT) Received: by 2002:ab3:11b:0:b0:293:3256:5107 with SMTP id a1c4a302cd1d6-2acb761afabmsc7a; Sun, 4 May 2025 23:04:38 -0700 (PDT) X-Received: by 2002:a2e:a58d:0:b0:31a:3744:6ecd with SMTP id 38308e7fff4ca-320c3af1527mr37150101fa.6.1746425076674; Sun, 04 May 2025 23:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1746425076; cv=none; d=google.com; s=arc-20240605; b=ZQZDihZn76P3oyQyo6RkUIYXGvPEcE8tTC9OzYEfLOby0J7FUMFxGeyodnSek3CUJj lk5zLOQbdzS8nJtlX/LCB7RxuvE5wL7pzVEDANWmfUakDl6TZmoLo2COpN1pMV56fMQ3 3b6fj7REjyQ7w8xqIcQVBg2EqtN7+n1a6ktQoh4EsR81kCV8GVs1Gi+PFtMZDXNBx5S5 hIfnAIQt6Xo3TOCxpHtLqW+2PhggKtIFRrqUjrTfUzaeEB5wlfXGXgmUFRMV8AFxs2CF mPosi1vjbLZqnDJZiqEAOojqGdAsJWHDDugeAu/U+eXUpuG/zttoUMLveKGegFLR/GD1 60qg== 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=I+ZVmNgA2IZrKYr7MLQKgB1pLIHDMYpwKo6AJihwL1g=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=kxyZrsLiPQJJzKZA4FvgJ7WKuZtKkUhi8R+ury3yNN+Kp/EyupuN2Fjy7IgY5qbhvI YANG1fhiQCSgPqNaQLSz2riKqgKM2IdQXwfiCiJClibczaDWAZpU//LMDSSS+S9e65Zi j9kJCqaGEyGqLGhA84zp1Hg9nfRZ8as+CD2lOGnUaoSBVXYivujHHgWvT1Kixlr/u8/4 tRwweLvxARfGRdlf5cTV/IlhUSmSe/1FUocohrLDmttURFIjVN9NoePwl+aLKBrA+jYI 3bMaGa09QaLETUXqSHZred5ZkMqL2hvLpDthH5a0P41M6UF8ybViiYJoluvuZEBHHt55 yQDA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bx7puZo6; spf=pass (google.com: domain of bitcoinerrorlog@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=bitcoinerrorlog@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com. [2a00:1450:4864:20::62c]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3202a5b2067si2709361fa.5.2025.05.04.23.04.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 23:04:36 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoinerrorlog@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) client-ip=2a00:1450:4864:20::62c; Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ac3eb3fdd2eso743275666b.0 for ; Sun, 04 May 2025 23:04:36 -0700 (PDT) X-Gm-Gg: ASbGncvjyshn9tsYvm0YuKPePsw3Pwx2ADlsHyM0Ly4MkHhY3DEZJ9AXUfIfgmOk72o PWe1jbG8j4UFF3tOpctj7TRgDezUjNYNjdj9p/jt26s9eLPXN/wFgz2PGbJLZdGbHHa7r36HrI3 tH0LLrgwqtu93e8LAx8YK0ngRIquw5qwiEtTvnasXeZPMQ7pikyrzeYnM= X-Received: by 2002:a17:906:dc8a:b0:ac3:afb1:dee7 with SMTP id a640c23a62f3a-ad17b5dbc98mr1087374066b.28.1746425075807; Sun, 04 May 2025 23:04:35 -0700 (PDT) MIME-Version: 1.0 References: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> In-Reply-To: From: Bitcoin Error Log Date: Mon, 5 May 2025 07:04:23 +0100 X-Gm-Features: ATxdqUHiNqD4ptBOtOzWzOhBZ2wEWrvSf3PNVXsTGz6qVCMwRye7JxK20_1I1BY Message-ID: Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions To: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000453b2206345d46dc" X-Original-Sender: bitcoinerrorlog@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bx7puZo6; spf=pass (google.com: domain of bitcoinerrorlog@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=bitcoinerrorlog@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 (/) --000000000000453b2206345d46dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it=E2=80=99s worth raising a meta-topic in light of the OP_RETURN d= ebate: namely, the importance of respecting the status quo as consensus, and the need for Bitcoin Core to distance itself from acting as a governance body. Most of you appreciate the idea of respecting user space, and the principle that consensus is most easily expressed by the software already being run. That=E2=80=99s the essence of Bitcoin=E2=80=99s credibility. In this specific case, I don=E2=80=99t even care about the outcome. The uti= lity and consequence of policies and data use cases are already fundamentally accounted for in Bitcoin=E2=80=99s design. It just isn=E2=80=99t a big deal= . But here are some things I think we should consider: 1. Even if we tweak OP_RETURN, Bitcoin Core will still enforce policies that reject certain valid transactions, even when they are harmless (non-flagged RBF, for example). The only way to eliminate this form of protocol-level censorship is to remove the policy engine=E2=80=99s influenc= e from consensus-critical infrastructure altogether. As long as Core shapes what is considered standard, it acts as a gatekeeper. True neutrality requires removing these centralized filters, not tweaking them. We should not be arguing over user-configurable settings in something called "Core." 2. Mempool fragmentation isn't caused by inscriptions alone. Fragmentation of the mempool arises from disharmony, complexity, and policy change, not from any specific class of transactions. Bitcoin Core is not the only implementation and the default config is not the only config. Adding a small set of explicit data use cases to OP_RETURN would not prevent users from continuing to encode data in Taproot outputs or other mechanisms for other reasons. 3. If Core plans to make Taproot witness data pruneable (they do, right?), then the very premise of this conflict becomes largely irrelevant. Is the UTXO =E2=80=9Cpollution=E2=80=9D argument moot? 4. Even if you give data users a clean OP_RETURN path, the original reasons for encoding data elsewhere haven=E2=80=99t gone away: =E2=80=A2 They may want resistance to censorship, since OP_RETURN data i= s potentially filterable. =E2=80=A2 They may want to emulate =E2=80=9Cfirst-seen=E2=80=9D behavior= for zero-conf coordination, especially in merchant or custodial systems. =E2=80=A2 They may simply not trust Core=E2=80=99s intentions, fearing f= uture reversals or targeted policy changes. Fragmentation doesn=E2=80=99t go away by offering alternatives, it follows incentives and distrust. Additional encoding options will coexist with existing ones, not replace them. 5. Bitcoin Core should avoid being a governance body. Core=E2=80=99s behavi= or has shown a pattern of shaping Bitcoin policy outside of consensus, through policy enforcement and behavioral changes that affect what nodes and miners relay and accept. This is de facto governance. Therefore, every Core policy change, especially those affecting transaction relay or validation, should be rejected by default (unless, MAYBE, they emerge organically, from actual consensus in the wild or from config-based downstream distros). The most dangerous centralizing force in Bitcoin today is not Ordinals or data use, it=E2=80=99s Core acting as a de facto standards body, redefining behavior outside the consensus process. If we are serious about decentralization, we must decouple policy from protocol, and resist all attempts by any one group to dictate Bitcoin=E2=80=99s rules unilaterally. Also consider that, compared to the drama and disruption, the utility/scaling/impact of Bitcoin rule changes overall, aside from the blockspace increase, has been a disappointment anyway. ~John Carvalho --=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/= CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%40mail.gmail.com. --000000000000453b2206345d46dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it=E2=80=99s worth raising a meta-topic in light o= f the OP_RETURN debate: namely, the importance of respecting the status quo= as consensus, and the need for Bitcoin Core to distance itself from acting= as a governance body.=C2=A0

Most of you appreciate the = idea of respecting user space, and the principle that consensus is most eas= ily expressed by the software already being run. That=E2=80=99s the essence= of Bitcoin=E2=80=99s credibility.=C2=A0

In this s= pecific case, I don=E2=80=99t even care about the outcome. The utility and = consequence of policies and data use cases are already fundamentally accoun= ted for in Bitcoin=E2=80=99s design. It just isn=E2=80=99t a big deal.=C2= =A0

But here are some things I think we should con= sider:

1. Even if we tweak OP_RETURN, Bitcoin Core will st= ill enforce policies that reject certain valid transactions, even when they= are harmless (non-flagged RBF, for example). The only way to eliminate thi= s form of protocol-level censorship is to remove the policy engine=E2=80=99= s influence from consensus-critical infrastructure altogether. As long as C= ore shapes what is considered standard, it acts as a gatekeeper. True neutr= ality requires removing these centralized filters, not tweaking them. We sh= ould not be arguing over user-configurable settings in something called &qu= ot;Core."

2. Mempool fragmentation isn't = caused by inscriptions alone. Fragmentation of the mempool arises from dish= armony, complexity, and policy change, not from any specific class of trans= actions. Bitcoin Core is not the only implementation and the default config= is not the only config. Adding a small set of explicit data use cases to O= P_RETURN would not prevent users from continuing to encode data in Taproot = outputs or other mechanisms for other reasons.=C2=A0

3. If Core plans to make Taproot witness data pruneable (they do, right?= ), then the very premise of this conflict becomes largely irrelevant. Is th= e UTXO =E2=80=9Cpollution=E2=80=9D argument moot?

= 4. Even if you give data users a clean OP_RETURN path, the original reasons= for encoding data elsewhere haven=E2=80=99t gone away:=C2=A0
=C2= =A0 =C2=A0=E2=80=A2 They may want resistance to censorship, since OP_RETURN= data is potentially filterable.=C2=A0
=C2=A0 =C2=A0=E2=80=A2 The= y may want to emulate =E2=80=9Cfirst-seen=E2=80=9D behavior for zero-conf c= oordination, especially in merchant or custodial systems.=C2=A0
= =C2=A0 =C2=A0=E2=80=A2 They may simply not trust Core=E2=80=99s intentions,= fearing future reversals or targeted policy changes.=C2=A0
Fragm= entation doesn=E2=80=99t go away by offering alternatives, it follows incen= tives and distrust. Additional encoding options will coexist with existing = ones, not replace them.=C2=A0

5. Bitcoin Core shou= ld avoid being a governance body. Core=E2=80=99s behavior has shown a patte= rn of shaping Bitcoin policy outside of consensus, through policy enforceme= nt and behavioral changes that affect what nodes and miners relay and accep= t. This is de facto governance. Therefore, every Core policy change, especi= ally those affecting transaction relay or validation, should be rejected by= default (unless, MAYBE, they emerge organically, from actual consensus in = the wild or from config-based downstream distros).=C2=A0

The most dangerous centralizing force in Bitcoin today is not Ordina= ls or data use, it=E2=80=99s Core acting as a de facto standards body, rede= fining behavior outside the consensus process. If we are serious about dece= ntralization, we must decouple policy from protocol, and resist all attempt= s by any one group to dictate Bitcoin=E2=80=99s rules unilaterally.

Also consider that, compared to the drama and disruption,= the utility/scaling/impact of Bitcoin rule changes overall, aside from the= blockspace increase, has been a disappointment anyway.

<= br>~John Carvalho


--
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/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%= 40mail.gmail.com.
--000000000000453b2206345d46dc--