From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 11:41:33 -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 1vEu44-000196-S2 for bitcoindev@gnusha.org; Fri, 31 Oct 2025 11:41:33 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3d9676b7c66sf2500350fac.1 for ; Fri, 31 Oct 2025 11:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761936086; x=1762540886; 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=vlCn7YcGVDSa4S8ZBjscgGc586Ek6TuPFBW9HOH2X2w=; b=H5x297nhvZZ96O0rlYVv2cr5yXynG27xRbFfcPkNyTB13lEwrUwKlCXo8rEjKjYJRF tlXnOOgJph7Hz+ye2LPaIatdR/8MMi+t7dAdCO9vaAdQ9aiXO/etWzFfHKIB2NslQx+K KohgILFC/o1aspPCIkpXc8z5kqkwFkwlFTN8i1JpWfoDHLUEbNtYeSwtdztBwAlLl+u6 4onnJcloJHUr3gAnoec8xusnz8xzw2b+YtY8vxsghqAIxlc2EC6uY637oErCdHOrV95Z WIJfTmBf48uEMNrCCPDmq0cH5q4ulZJNpnzJ+OAl8VNry8xzXRcvbG+I7Lo/wymirzU4 pfJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1761936086; x=1762540886; 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=vlCn7YcGVDSa4S8ZBjscgGc586Ek6TuPFBW9HOH2X2w=; b=C50nSztN+/Zi9EL8xl3nFSlvjcfs+mfPZpbCQd6I8DOBlXCQSuEtazEjlW8HlP6IVf j2Dn55RZ1XMNs7TOrXV1wYhCUJeHAThw3A4ggmp4JMIVoP6Pnjxcj/MNMae4PZ6dOflc Vk4LX4ZnNKjtB79MGO2HbLbSqdsVSsRjsBSArXlp87VQpY7oSwTQedb3+9vxldfOYhmY o/8B15074p/0qLLmD8ISM2eWaZVQnL2dKYSFVhyLSo8Zv7wpdl1HevjzDG79l9kvMxnQ PtTxmwrL1UlE89Z/AWp6lmb3Z4a8oVYMLcLWVW0VRsE6Og8Qc4nBqgKT1tC+8JjzmTQL fyOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761936086; x=1762540886; 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=vlCn7YcGVDSa4S8ZBjscgGc586Ek6TuPFBW9HOH2X2w=; b=FwshIAEkqX/KNiQnArS+wvEXFu0FqtxPrePg5uYCYqgO2FOGNGznRckBfmM6sBjlQv Vd9Fj6dHgLU8xOh82ygDrTZzSDoFeXpOfUxZxtDjGjiQJqxrSPR4E+S7asZsERtnaXnk rW67xzQQ1zmKFJuow5gDIgFbMKAXvgA4/DiBHIEi6FRmqSRu0P7oL/eTGRC9wKr9QQhN 9uqG9n4VaDP/sR5uw07W1X3Y+Yc9BKM46TUHMsIQvdbDHI8ZTOwsP+sD/Ca9rCBn565B tkO4L4TbzWEvyQAnEggGNgvcilxPF7w7vsjjqq6R2eqONmIGS6aejIkEZipBlkiF+CGj m0BQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW2eUiJ3MVTu0mp/fPgPQmbpfoq6dgfL7u0jttOkXUATteF7WbJc7mfEsQynIiQukHqQRU7pCfAVsp+@gnusha.org X-Gm-Message-State: AOJu0YyDMAzPaHhwHFX3v1f0amcXsXkwz+xU217Q7rTpu+0YY84x+V5O 7fnxF3WZKRC8y+M3wkR1CSy1xxL2xl7LPwyRWN8WQ+bKI53kDl1syV/Q X-Google-Smtp-Source: AGHT+IGgqyU32lvz1CqQ0VVEis30QGG5zq50tRHSieFvVeI/YZkCRTwFcfdIhE9yIYZdnKbr3ehsqw== X-Received: by 2002:a05:6870:2498:b0:3d3:76f:5108 with SMTP id 586e51a60fabf-3dacdb70b3dmr1853773fac.33.1761936086538; Fri, 31 Oct 2025 11:41:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bHek4SdyxHAY9s2SUPYNjCEHsB8CqvX6LKAdoNvueDGg==" Received: by 2002:a05:6870:ad0b:b0:31d:8e96:6f5e with SMTP id 586e51a60fabf-3d8bf40ccb1ls1287640fac.2.-pod-prod-08-us; Fri, 31 Oct 2025 11:41:22 -0700 (PDT) X-Received: by 2002:a05:6808:3a08:b0:44d:bf47:6ee5 with SMTP id 5614622812f47-44f95ec05c6mr2238709b6e.20.1761936082391; Fri, 31 Oct 2025 11:41:22 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Fri, 31 Oct 2025 11:32:55 -0700 (PDT) X-Received: by 2002:a05:690c:680b:b0:786:5100:f6bf with SMTP id 00721157ae682-786510123efmr34158997b3.50.1761935574660; Fri, 31 Oct 2025 11:32:54 -0700 (PDT) Date: Fri, 31 Oct 2025 11:32:54 -0700 (PDT) From: Juan Aleman To: Bitcoin Development Mailing List Message-Id: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_117782_1206070128.1761935574334" 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_117782_1206070128.1761935574334 Content-Type: multipart/alternative; boundary="----=_Part_117783_147579457.1761935574334" ------=_Part_117783_147579457.1761935574334 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Greg, thanks for your feedback. I am already starting to do 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 wrote: > 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 li= st.=20 >> But I've been involved with Bitcoin since 2017. First only as a hard mon= ey=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 m= ove=20 >> forward in agreement. >> >> The changes in v30 defaults got my attention (similar to many of you), a= s=20 >> they are completely opposite to what has historically been "standard"=20 >> practice. A highly controversial change that surfaces the influence over= =20 >> default policy in the network, escalating to the point of a fork proposa= l=20 >> . >> >> First, it must be reminded that a fork should be unnecessary if defaults= =20 >> are simply reverted ,=20 >> while still allowing all policy possibilities. >> >> After my second PR =20 >> attempt was (also) closed (and I was blocked from the repo), I realized= =20 >> that the main issue here is social-political, not technical. It's about = the=20 >> powerful influence the "Official Reference Implementation" centralized n= ode=20 >> software repository has. >> >> This needs a different kind of solution. I'd like to propose a high-leve= l=20 >> structural change to the "Official Bitcoin Repository": Separating=20 >> consensus code from policy-based node distribution. >> >> *Problem Statement:* >> >> The "official" Bitcoin Core node repository ( >> https://github.com/bitcoin/bitcoin) maintains consensus code while also= =20 >> 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 "pedesta= l",=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) disrup= t=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 expectatio= n.=20 >> Bitcoin's hidden limits are being revealed. >> >> *Proposal:* >> >> To address humans' flaws, I suggest reorganizing the repository structur= e=20 >> to better safeguard against unwarranted political (policy) 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 ALL= =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 the= =20 >> current bitcoin/bitcoin node software. This repository embeds the=20 >> consensus-focused bitcoin-core (objective), while including "current cor= e=20 >> devs"-recommended default policies (subjective). Other clients would use= =20 >> this as their foundation, to customize policy and beyond. (Also, there i= s=20 >> nothing preventing multiple bitcoin-node- existing in parallel, be= st=20 >> addressing default-bias concerns.) >> >> >> The initial implementation of this separation might not be elegant, but= =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 defaults.= =20 >> Then, a subsequent release could adopt v30 defaults, with the home READM= E=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 on!= =20 >> Open-Data is out of the bag anyway.)* >> >> This proposal attempts to find a compromise where no side feels "forced= =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 consensus= =20 >> 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 dee= p=20 >> disruptions (which some will see as a benefit, forcing a conscious ch= oice=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 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/d397e2e1-3d5b-473a-b915-aca= 2cfc9da32n%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/= 55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com. ------=_Part_117783_147579457.1761935574334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Greg, thanks for your feedback. I am already starting to do something, but the main point IS about the centralization = 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=A0think= it would be valuable, feel free to create it. 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 <bitco...@juanaleman.com> wrote:
Hello bitcoin developers,

My name is Juan Alem=C3=A1n, an= d this is my first post to the mailing list. But I've been involved wit= h Bitcoin since 2017. First only as a hard money investor, but later also a= s a developer, specially fascinated by this permanent medium. I hope this p= roposal can be appreciated by all perspectives as a pragmatic (maybe unorth= odox, but timely) solution to move forward in agreement.

The changes= in v30 defaults got my attention (similar to many of you), as they are com= pletely opposite to what has historically been "standard" practic= e. A highly controversial change that surfaces the influence over default p= olicy in the network, 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 allowing all policy possibilities.

After my second PR atte= mpt was (also) closed (and I was blocked from the repo), I realized that th= e main issue here is social-political, not technical. It's about the po= werful influence the "Official Reference Implementation" centrali= zed node software repository has.

This needs a different kind of sol= ution. I'd like to propose a high-level structural change to the "= Official Bitcoin Repository": Separating consensus code from policy-ba= sed node distribution.

Problem Statement:

The "of= ficial" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) maintains consensus co= de while also defining default relay and mining policies, among all other n= ode functionalities, in a single piece of software. This concentration of r= esponsibilities leads to elevating this single repository to a "pedest= al", thus a point of centralization, giving a few too much influence.<= br>
This kind of influence can be considered "harm" when abrup= t default policy changes (like v30's shift toward permissive data carry= ing) disrupt "standard" network practices and its users.

H= owever, the v30 release itself may have caused a point of no return, where = "globally agreed standardness" is no longer a realistic expectati= on. Bitcoin's hidden limits are being revealed.

Proposal:=

To address humans' flaws, I suggest reorganizing the repository= structure to better safeguard against unwarranted political (policy) influ= ence.

1. Rename and Refocus Core Repo:

=C2=A0 =C2=A0 R= ename (github.com/)bitcoin/bit= coin to bitcoin/bitcoin-core. This repo would focus mainly on consensus= rules, removing arbitrary or non-critical policies from its scope. It beco= mes a neutral base for ALL node implementations, emphasizing on hardening a= nd testing consensus without policy distractions.

2. Introduce No= de Client Repo(s):

=C2=A0 =C2=A0 Create a separate repository fo= r the full-featured node client, starting with (github.com/)bitcoin/bitcoin-node as the fou= ndational template. This would effectively serve as the direct replacement = for the current bitcoin/bitcoin node software. This repository embeds the c= onsensus-focused bitcoin-core (objective), while including "current co= re devs"-recommended default policies (subjective). Other clients woul= d use this as their foundation, to customize policy and beyond. (Also, ther= e is nothing preventing multiple bitcoin-node-<type> existing in para= llel, best addressing default-bias concerns.)


The initial implementation of this separation might not be elegant, but= future releases can progressively refactor based on this new reorganizatio= n, potentially incorporating more modularity (where beneficial).

For= a smooth transition that resolves ongoing tensions, the suggested first re= lease of bitcoin/bitcoin-node should revert to pre-v30 defaults. Then, a su= bsequent release could adopt v30 defaults, with the home README clearly doc= umenting options/alternatives (e.g. "For legacy Money-First policies, = use X").

(But STILL the simplest solution is just to allow s= omething like this. And let's just move on! Open-Data is out of the bag any= way.)

This proposal attempts to find a compromise where no side = feels "forced to comply", and represents a more neutral position = from the "Official Reference Implementation" repository in this n= ew era.

Benefits:
  • Bitcoin-Core reaches its epitome= , focusing on a hardened consensus core that serves all clients, regardless= of policy.
  • Reduction of the "official" repo's influe= nce on default policy, better aligning with Bitcoin's decentralization = principles.

Drawbacks:
  • Breaks existing infra= structure tied to github.com/bit= coin/bitcoin. However, bitcoin/bitcoin-node is a 1-to-1 replacement, mi= tigating deep disruptions (which some will see as a benefit, forcing a cons= cious choice about what node software to run moving forward).
  • Also,= there must be caution of not using the original github.com/bitcoin/bitcoin name for anything else, as = that would break automatic GitHub url redirects.


Thank you for your time. This is just an idea I wanted to shar= e 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+...@googlegro= ups.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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com.
------=_Part_117783_147579457.1761935574334-- ------=_Part_117782_1206070128.1761935574334--