path: root/59/b3ff8a0b3ee8c319d94393d11dda447b4d6559

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 <bitcoindev+bncBCJ6NONR3AHRB54I4LAAMGQEBGYZKXI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> <CAMHHROx7s31+cdKe0d3BdZDcjgshvsLc=fdS_JFmA5Ve=kBuJw@mail.gmail.com>
In-Reply-To: <CAMHHROx7s31+cdKe0d3BdZDcjgshvsLc=fdS_JFmA5Ve=kBuJw@mail.gmail.com>
From: Bitcoin Error Log <bitcoinerrorlog@gmail.com>
Date: Mon, 5 May 2025 07:04:23 +0100
X-Gm-Features: ATxdqUHiNqD4ptBOtOzWzOhBZ2wEWrvSf3PNVXsTGz6qVCMwRye7JxK20_1I1BY
Message-ID: <CAE2fw6sX2BA8FJkb2U8A2=RuYnBe770uNrMpgV1sxg2yf9EC=w@mail.gmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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

<div dir=3D"ltr">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<div><br></div><div>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</div><div><br></div><div>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</div><div><br></div><div>But here are some things I think we should con=
sider:<br><div><br><div>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.&quot;</div><div><br></div><div>2. Mempool fragmentation isn&#39;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</div><div><br></div><d=
iv>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?</div><div><br></div><div>=
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</div><div>=C2=
=A0 =C2=A0=E2=80=A2 They may want resistance to censorship, since OP_RETURN=
 data is potentially filterable.=C2=A0</div><div>=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</div><div>=
=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</div><div>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</div><div><br></div><div>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</div><div><br></di=
v><div>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.</div><d=
iv><br></div><div>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><div><br></div><=
br>~John Carvalho<br><br><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%=
40mail.gmail.com</a>.<br />

--000000000000453b2206345d46dc--