If you want that and think 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 PM Juan Aleman wrote: > Hello bitcoin developers, > > My name is Juan Alemán, and this is my first post to the mailing list. But > I've been involved with Bitcoin since 2017. First only as a hard money > investor, but later also as a developer, specially fascinated by this > permanent medium. I hope this proposal can be appreciated by all > perspectives as a pragmatic (maybe unorthodox, but timely) solution to move > forward in agreement. > > The changes in v30 defaults got my attention (similar to many of you), as > they are completely opposite to what has historically been "standard" > practice. A highly controversial change that surfaces the influence over > default policy 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 > attempt was (also) closed (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 repository has. > > This needs a different kind of solution. I'd like to propose a high-level > structural change to the "Official Bitcoin Repository": 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 also > defining default relay and mining policies, among all other node > functionalities, in a single piece of software. This concentration of > responsibilities leads to elevating this single repository to a "pedestal", > thus a point of centralization, giving a few too much influence. > > This kind of influence can be considered "harm" when abrupt default policy > changes (like v30's shift toward permissive data carrying) disrupt > "standard" network practices and its users. > > However, the v30 release itself may have caused a point of no return, > where "globally agreed 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 better safeguard against unwarranted political (policy) influence. > > *1. Rename and Refocus Core Repo:* > > Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This > repo would focus mainly on consensus rules, removing arbitrary or > non-critical policies from its scope. It becomes a neutral base for ALL > node implementations, emphasizing on hardening and testing consensus > without policy distractions. > > *2. Introduce Node Client Repo(s):* > > Create a separate repository for the full-featured node client, > starting with (github.com/)bitcoin/bitcoin-node as the foundational > template. This would effectively serve as the direct replacement for the > current bitcoin/bitcoin node software. This repository embeds the > consensus-focused bitcoin-core (objective), while including "current core > devs"-recommended default policies (subjective). Other clients would use > this as their foundation, to customize policy and beyond. (Also, there is > nothing preventing multiple bitcoin-node- existing in parallel, 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 > reorganization, potentially incorporating more modularity (where > beneficial). > > For a smooth transition that resolves ongoing tensions, the suggested > first release of bitcoin/bitcoin-node should revert to pre-v30 defaults. > Then, a subsequent release could adopt v30 defaults, with the home README > clearly documenting options/alternatives (e.g. "For legacy Money-First > policies, use X"). > > *(But STILL the simplest solution is just to allow something like this > . And let's just move on! > Open-Data is out of the bag anyway.)* > > 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 new 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 influence on default policy, > 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 > disruptions (which some will see as a benefit, forcing a conscious 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 share for > discussion, and I would appreciate any thoughts. > > Juan > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com > > . > -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTNs%2B04X_pVLx%2BEXUUMk7bzTG2-qGHDTZ5NwxaMDkjp6g%40mail.gmail.com.