From: Juan Aleman <bitcoindev@juanaleman.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
Date: Fri, 31 Oct 2025 10:54:43 -0700 (PDT) [thread overview]
Message-ID: <d397e2e1-3d5b-473a-b915-aca2cfc9da32n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 5698 bytes --]
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
<https://github.com/bitcoin/bips/pull/2017>.
First, it must be reminded that a fork should be unnecessary if defaults
are simply reverted <https://github.com/bitcoin/bitcoin/pull/33682>, while
still allowing all policy possibilities.
After my second PR <https://github.com/bitcoin/bitcoin/pull/33690> 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-<type> 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
<https://github.com/bitcoin/bitcoin/pull/33682>. 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.
[-- Attachment #1.2: Type: text/html, Size: 6214 bytes --]
next reply other threads:[~2025-10-31 18:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 17:54 Juan Aleman [this message]
2025-10-31 18:21 ` Greg Maxwell
2025-10-31 18:32 ` Juan Aleman
2025-10-31 18:47 ` Greg Maxwell
2025-10-31 18:56 ` Juan Aleman
2025-10-31 22:59 ` Antoine Riard
2025-11-01 15:59 ` Juan Aleman
2025-11-01 17:54 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-11-02 20:04 ` Antoine Riard
2025-11-02 20:43 ` Juan Aleman
2025-10-31 18:36 ` Matt Corallo
2025-10-31 18:51 ` Juan Aleman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d397e2e1-3d5b-473a-b915-aca2cfc9da32n@googlegroups.com \
--to=bitcoindev@juanaleman.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox