From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 12:14:37 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEua4-0001Y2-Fm for bitcoindev@gnusha.org; Fri, 31 Oct 2025 12:14:37 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-656820f2627sf2833883eaf.2 for ; Fri, 31 Oct 2025 12:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761938070; x=1762542870; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=8upXm0s1hNCcol+s6LhhvkwCIb423DOE7XRl2tZTGT8=; b=QUw/AXMyi8DwZol6FGu87fVD7C8y1GWv6KuSh1EW/EXpjTvEdwHfTpe+wVkt6okS7S ZxhmwenFQkUiuWuvm2q+ri6KReXrsNtGEbdnZIMxlJHgq7GiEcy5hN2d3JXRDRkgTt5J mAFL6I8Xf9utqzex9LVhsIiHhT4UVtnPnHV5363V0wi86GNK8/eUtpeW+9dGzHm+ekuj ODL20luPKJr5QAIZ770mZgS4g/wXCqXfi+XtMKcnHEE3/fLCDpT4pYf/zBEKwCDZh6uH F0Eje0hSWASYD8bjPqvfgdGrriO3q7y8UmIePClw+o5zM32Q1wFwbN18nZpTmXgEynOv 39PA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1761938070; x=1762542870; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=8upXm0s1hNCcol+s6LhhvkwCIb423DOE7XRl2tZTGT8=; b=OBLHy7ZPo40/aHt1Vjv4qH7pcZYciSlV2Bhnx5xY9VJ71UW2svlHOJNucz3qiVyA8E K5YP8Gr8J08csTaslunmX+fIc56KvkyQ9bku3xKyzhWHqP7OBHQliHk1wXmkfpBhlaoj 4j47oiNrFe+De15cPWpUyXI7Lnpz2aWTkIagAcm274oKSdYIytTzqjzrUHQrxp525I+j dn5LUiR2QOFSB2euYrfWixTkeDw9c5cnDf8/nx3KqcVd9fq/9LXU5xTpUQgMcFiiV7DA Bxl81cSLnO34g8uaYJZMRXN6nTtGcIr5Z/ZgOpLexP8+z3a0oWr+UPNH8MoCYQ1d8cR2 ELCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761938070; x=1762542870; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=8upXm0s1hNCcol+s6LhhvkwCIb423DOE7XRl2tZTGT8=; b=r0JKOy+XO9XR3GLI9wKFbvDABJNZd/TFY/fgO1JvTEFGNMXs0evfDo6Zm/fuLSaS97 XZW5fHCdR4IbI76cCDnJbcIryPA6zB11HeksI52+VnHSUsBcyfePBAvXSfVkscconEFg k7V84a7bGnKCndlE2/QVQSPLwVshsAW4j6XV7JT4XhuYWBO8NCKBWVDCHWnrWKtw4zjq n4CrwgMBMsctqgWsRI0O/vM66dYWpntRaGJv3PrrVJkNkmby7KIssMYWDosTKEkpJ1SM e8BPVSYxhhFOwUq0fgrn0g6kZQVKl3XdZ1uxSpCCrJSgSW4azK/XOxdkiNqQvHZOu5/f RFZQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWjdh5ZD32QOuzWBh6y0AM52YyX157LjjmApvvdX39nqLyjSnMN2w3wq8uwFsmJTZXB7Q4N49lGZbyg@gnusha.org X-Gm-Message-State: AOJu0YzD0YnlvT9bPZvMCuqYhK1wimnQrClFho67xpU7swwAYI6D7mpp qcJqNv5YbYpZYJE3jb11hmOkFmNW1nEgciDo6PDRTbtPBB4JwUjBLpnn X-Google-Smtp-Source: AGHT+IGvIVDjo9Ja0qrZ0ucsJhTVMAwo9BNVYLrHNqhNKIPaBkAAAiZhbmf/YMxFUlsssYWvvZi1lQ== X-Received: by 2002:a05:6820:2d04:b0:654:f6f1:dd07 with SMTP id 006d021491bc7-6568a6823e3mr2231700eaf.4.1761938070258; Fri, 31 Oct 2025 12:14:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+adGy38URfQePu7TUsRkzEVsYUNuaOf6Y43llXqpa/vVA==" Received: by 2002:a05:6820:4585:b0:656:7f32:7776 with SMTP id 006d021491bc7-656823cd7a9ls1839780eaf.0.-pod-prod-01-us; Fri, 31 Oct 2025 12:14:26 -0700 (PDT) X-Received: by 2002:a05:6808:1384:b0:44d:b760:f1dc with SMTP id 5614622812f47-44f95e2787emr2006773b6e.1.1761938066636; Fri, 31 Oct 2025 12:14:26 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Fri, 31 Oct 2025 11:56:27 -0700 (PDT) X-Received: by 2002:a05:690c:338f:b0:786:393c:5f18 with SMTP id 00721157ae682-786484c3ba4mr42083047b3.39.1761936986504; Fri, 31 Oct 2025 11:56:26 -0700 (PDT) Date: Fri, 31 Oct 2025 11:56:26 -0700 (PDT) From: Juan Aleman To: Bitcoin Development Mailing List Message-Id: <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> In-Reply-To: References: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_207462_1117405390.1761936986134" X-Original-Sender: bitcoindev@juanaleman.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.7 (/) ------=_Part_207462_1117405390.1761936986134 Content-Type: multipart/alternative; boundary="----=_Part_207463_802124134.1761936986134" ------=_Part_207463_802124134.1761936986134 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greg I actually agree there should be no "official" anything. That is why I= =20 purposefully always use "quotes" around it. Unfortunately for both of us, this is not a reflection of reality.=20 "Official Bitcoin Core" has become itself the power grab. My proposal is about bringing this to the forefront. Most discussions I see= =20 revolve around who can win an argument. All these are distractions IMO, the= =20 issue here IS with the structure we have "trusted" for so many years is no= =20 longer viable. On Friday, October 31, 2025 at 2:48:48=E2=80=AFPM UTC-4 Greg Maxwell wrote: > Other people don't do what you want because they believe it would harm=20 > Bitcoin and they have no interest in spending their efforts trying to har= m=20 > something they love just to satisfy other people who disagree with them. = =20 > Maybe they are wrong, but fortunately you have the freedom to go your own= =20 > way. There is no 'official' anything. Continuing to try to coerce other= s=20 > to do what you want when they think it would be wrong and harmful is a ba= d=20 > choice which will make enemies out of people who otherwise would be=20 > indifferent to your efforts that they regard as misguided. > > > On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Juan Aleman =20 > wrote: > >> Hello Greg, thanks for your feedback. I am already starting to do=20 >> something=20 >> ,=20 >> but the main point IS about the centralization risks of the "official"= =20 >> repo... >> >> On Friday, October 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell wro= te: >> >>> If you want that and think it would be valuable, feel free to create it= .=20 >>> No one will stop you and you don't need anyone's permission. >>> >>> On Fri, Oct 31, 2025 at 6:20=E2=80=AFPM Juan Aleman =20 >>> wrote: >>> >>>> Hello bitcoin developers, >>>> >>>> My name is Juan Alem=C3=A1n, and this is my first post to the mailing = list.=20 >>>> But I've been involved with Bitcoin since 2017. First only as a hard m= oney=20 >>>> investor, but later also as a developer, specially fascinated by this= =20 >>>> permanent medium. I hope this proposal can be appreciated by all=20 >>>> perspectives as a pragmatic (maybe unorthodox, but timely) solution to= move=20 >>>> forward in agreement. >>>> >>>> The changes in v30 defaults got my attention (similar to many of you),= =20 >>>> as they are completely opposite to what has historically been "standar= d"=20 >>>> practice. A highly controversial change that surfaces the influence ov= er=20 >>>> default policy in the network, escalating to the point of a fork=20 >>>> proposal . >>>> >>>> First, it must be reminded that a fork should be unnecessary if=20 >>>> defaults are simply reverted=20 >>>> , while still allowing= =20 >>>> all policy possibilities. >>>> >>>> After my second PR =20 >>>> attempt was (also) closed (and I was blocked from the repo), I realize= d=20 >>>> that the main issue here is social-political, not technical. It's abou= t the=20 >>>> powerful influence the "Official Reference Implementation" centralized= node=20 >>>> software repository has. >>>> >>>> This needs a different kind of solution. I'd like to propose a=20 >>>> high-level structural change to the "Official Bitcoin Repository":=20 >>>> Separating consensus code from policy-based node distribution. >>>> >>>> *Problem Statement:* >>>> >>>> The "official" Bitcoin Core node repository ( >>>> https://github.com/bitcoin/bitcoin) maintains consensus code while=20 >>>> also defining default relay and mining policies, among all other node= =20 >>>> functionalities, in a single piece of software. This concentration of= =20 >>>> responsibilities leads to elevating this single repository to a "pedes= tal",=20 >>>> thus a point of centralization, giving a few too much influence. >>>> >>>> This kind of influence can be considered "harm" when abrupt default=20 >>>> policy changes (like v30's shift toward permissive data carrying) disr= upt=20 >>>> "standard" network practices and its users. >>>> >>>> However, the v30 release itself may have caused a point of no return,= =20 >>>> where "globally agreed standardness" is no longer a realistic expectat= ion.=20 >>>> Bitcoin's hidden limits are being revealed. >>>> >>>> *Proposal:* >>>> >>>> To address humans' flaws, I suggest reorganizing the repository=20 >>>> structure to better safeguard against unwarranted political (policy)= =20 >>>> influence. >>>> >>>> *1. Rename and Refocus Core Repo:* >>>> >>>> Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This= =20 >>>> repo would focus mainly on consensus rules, removing arbitrary or=20 >>>> non-critical policies from its scope. It becomes a neutral base for AL= L=20 >>>> node implementations, emphasizing on hardening and testing consensus= =20 >>>> without policy distractions. >>>> >>>> *2. Introduce Node Client Repo(s):* >>>> >>>> Create a separate repository for the full-featured node client,=20 >>>> starting with (github.com/)bitcoin/bitcoin-node as the foundational=20 >>>> template. This would effectively serve as the direct replacement for t= he=20 >>>> current bitcoin/bitcoin node software. This repository embeds the=20 >>>> consensus-focused bitcoin-core (objective), while including "current c= ore=20 >>>> devs"-recommended default policies (subjective). Other clients would u= se=20 >>>> this as their foundation, to customize policy and beyond. (Also, there= is=20 >>>> nothing preventing multiple bitcoin-node- existing in parallel, = best=20 >>>> addressing default-bias concerns.) >>>> >>>> >>>> The initial implementation of this separation might not be elegant, bu= t=20 >>>> future releases can progressively refactor based on this new=20 >>>> reorganization, potentially incorporating more modularity (where=20 >>>> beneficial). >>>> >>>> For a smooth transition that resolves ongoing tensions, the suggested= =20 >>>> first release of bitcoin/bitcoin-node should revert to pre-v30 default= s.=20 >>>> Then, a subsequent release could adopt v30 defaults, with the home REA= DME=20 >>>> clearly documenting options/alternatives (e.g. "For legacy Money-First= =20 >>>> policies, use X"). >>>> >>>> *(But STILL the simplest solution is just to allow something like this= =20 >>>> . And let's just move o= n!=20 >>>> Open-Data is out of the bag anyway.)* >>>> >>>> This proposal attempts to find a compromise where no side feels "force= d=20 >>>> to comply", and represents a more neutral position from the "Official= =20 >>>> Reference Implementation" repository in this new era. >>>> >>>> *Benefits:* >>>> >>>> - Bitcoin-Core reaches its epitome, focusing on a hardened=20 >>>> consensus core that serves all clients, regardless of policy. >>>> - Reduction of the "official" repo's influence on default policy,= =20 >>>> better aligning with Bitcoin's decentralization principles. >>>> >>>> >>>> *Drawbacks:* >>>> >>>> - Breaks existing infrastructure tied to github.com/bitcoin/bitcoin= .=20 >>>> However, bitcoin/bitcoin-node is a 1-to-1 replacement, mitigating d= eep=20 >>>> disruptions (which some will see as a benefit, forcing a conscious = choice=20 >>>> about what node software to run moving forward). >>>> - Also, there must be caution of not using the original=20 >>>> github.com/bitcoin/bitcoin name for anything else, as that would=20 >>>> break automatic GitHub url redirects. >>>> >>>> >>>> >>>> Thank you for your time. This is just an idea I wanted to share for=20 >>>> discussion, and I would appreciate any thoughts. >>>> >>>> Juan=20 >>>> >>>> --=20 >>>> You received this message because you are subscribed to the Google=20 >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-a= ca2cfc9da32n%40googlegroups.com=20 >>>> >>>> . >>>> >>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535= d965f3a74n%40googlegroups.com=20 >> >> . >> > --=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/= 9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n%40googlegroups.com. ------=_Part_207463_802124134.1761936986134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg I actually agree there should be no "official" anything. That is = why I purposefully always use "quotes" around it.

Unfortunately for both of us, this is not a reflection of reality. "Offic= ial Bitcoin Core" has become itself the power grab.

<= div>My proposal is about bringing this to the forefront. Most discussions I= see revolve around who can win an argument. All these are distractions IMO= , the issue here IS with the structure we have "trusted" for so many years = is no longer viable.
On Friday, October 31, 2025 at 2:48:48=E2=80=AFPM UT= C-4 Greg Maxwell wrote:
Other people don't do what you want = because they believe it would harm Bitcoin and they have no interest in=C2= =A0spending their efforts trying to harm something they love just to satisf= y other people who disagree with them.=C2=A0 Maybe they are wrong, but fort= unately you have the freedom to go your own way.=C2=A0 There is no 'off= icial' anything.=C2=A0 Continuing=C2=A0to try to coerce=C2=A0others to = do what you want when they think it would be wrong and harmful is a bad cho= ice which will make enemies out of people who otherwise would be indifferen= t to your efforts that they regard as misguided.

=
On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Juan Ale= man <bitco...@juanaleman.com<= /a>> wrote:
Hello Greg, thanks for your feedback. I am= already starting to do something, but the main point IS about the centralizatio= n risks of the "official" repo...

On Friday, October 31, 2025 at 2:= 24:36=E2=80=AFPM UTC-4 Greg Maxwell wrote:
If you want that and=C2=A0= think it would be valuable, feel free to create it. No one will stop you an= d you don't need anyone's permission.

On Fri, Oct 31, 2025 at 6:20=E2=80=AFPM Juan Aleman <bitco...@juanaleman.com> wrote:
Hello bi= tcoin developers,

My name is Juan Alem=C3=A1n, and this is my first = post to the mailing list. But I've been involved with Bitcoin since 201= 7. First only as a hard money investor, but later also as a developer, spec= ially fascinated by this permanent medium. I hope this proposal can be appr= eciated by all perspectives as a pragmatic (maybe unorthodox, but timely) s= olution to move forward in agreement.

The changes in v30 defaults go= t my attention (similar to many of you), as they are completely opposite to= what has historically been "standard" practice. A highly controv= ersial change that surfaces the influence over default policy in the networ= k, escalating to the point of a fork proposal.

First, it must be reminded that a= fork should be unnecessary if defaults are simply reverted, while still allowi= ng all policy possibilities.

After my second PR attempt was (also) close= d (and I was blocked from the repo), I realized that the main issue here is= social-political, not technical. It's about the powerful influence the= "Official Reference Implementation" centralized node software re= pository has.

This needs a different kind of solution. I'd like = to propose a high-level structural change to the "Official Bitcoin Rep= ository": Separating consensus code from policy-based node distributio= n.

Problem Statement:

The "official" Bitcoin= Core node repository (https= ://github.com/bitcoin/bitcoin) maintains consensus code while also defi= ning default relay and mining policies, among all other node functionalitie= s, in a single piece of software. This concentration of responsibilities le= ads to elevating this single repository to a "pedestal", thus a p= oint of centralization, giving a few too much influence.

This kind o= f influence can be considered "harm" when abrupt default policy c= hanges (like v30's shift toward permissive data carrying) disrupt "= ;standard" network practices and its users.

However, the v30 re= lease itself may have caused a point of no return, where "globally agr= eed standardness" is no longer a realistic expectation. Bitcoin's = hidden limits are being revealed.

Proposal:

To address= humans' flaws, I suggest reorganizing the repository structure to bett= er safeguard against unwarranted political (policy) influence.

1.= Rename and Refocus Core Repo:

=C2=A0 =C2=A0 Rename (github.com/)bitcoin/bitcoin to bitcoi= n/bitcoin-core. This repo would focus mainly on consensus rules, removing a= rbitrary or non-critical policies from its scope. It becomes a neutral base= for ALL node implementations, emphasizing on hardening and testing consens= us without policy distractions.

2. Introduce Node Client Repo(s):=

=C2=A0 =C2=A0 Create a separate repository for the full-feature= d node client, starting with (github.com/)bitcoin/bitcoin-node as the foundational template= . This would effectively serve as the direct replacement for the current bi= tcoin/bitcoin node software. This repository embeds the consensus-focused b= itcoin-core (objective), while including "current core devs"-reco= mmended default policies (subjective). Other clients would use this as thei= r foundation, to customize policy and beyond. (Also, there is nothing preve= nting multiple bitcoin-node-<type> existing in parallel, best address= ing default-bias concerns.)


The initial im= plementation of this separation might not be elegant, but future releases c= an progressively refactor based on this new reorganization, potentially inc= orporating more modularity (where beneficial).

For a smooth transiti= on that resolves ongoing tensions, the suggested first release of bitcoin/b= itcoin-node should revert to pre-v30 defaults. Then, a subsequent release c= ould adopt v30 defaults, with the home README clearly documenting options/a= lternatives (e.g. "For legacy Money-First policies, use X").
<= br>(But STILL the simplest solution is just to allow something like this. An= d let's just move on! Open-Data is out of the bag anyway.)

T= his proposal attempts to find a compromise where no side feels "forced= to comply", and represents a more neutral position from the "Off= icial Reference Implementation" repository in this new era.

= Benefits:
  • Bitcoin-Core reaches its epitome, focusing on a ha= rdened consensus core that serves all clients, regardless of policy.
    • Reduction of the "official" repo's influence on default pol= icy, better aligning with Bitcoin's decentralization principles.
    Drawbacks:
    • Breaks existing infrastructure tied to = github.com/bitcoin/bitcoin. = However, bitcoin/bitcoin-node is a 1-to-1 replacement, mitigating deep disr= uptions (which some will see as a benefit, forcing a conscious choice about= what node software to run moving forward).
    • Also, there must be cau= tion of not using the original github.com/bitcoin/bitcoin name for anything else, as that would break= automatic GitHub url redirects.


    Tha= nk you for your time. This is just an idea I wanted to share for discussion= , and I would appreciate any thoughts.

    Juan

--
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+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da3= 2n%40googlegroups.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+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a7= 4n%40googlegroups.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/bitcoind= ev/9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n%40googlegroups.com.
------=_Part_207463_802124134.1761936986134-- ------=_Part_207462_1117405390.1761936986134--