From: Juan Aleman <bitcoindev@juanaleman.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
Date: Sat, 1 Nov 2025 08:59:33 -0700 (PDT) [thread overview]
Message-ID: <f60a2f77-ab31-4bde-ad5b-736a0f19a915n@googlegroups.com> (raw)
In-Reply-To: <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 12727 bytes --]
Hello Antoine,
Nice to meet you. The main issue here is with the bitcoin/bitcoin repo
itself. A single authority with too much influence, now escalating to the
point of a fork over defaults.
The power of defaults.
I don't know how you feel about this whole situation, but for me, it's
quite uncomfortable to be in deep conflicts with peers, and even friends.
But "CoreDevs" seem way too invested to remain unbiased, clearly missing
the forest for the trees.
Glad to learn that bitcoin/bitcoin-core already has some headway, seems
like libbitcoinkernel could eventually be integral in this new
consensus-focused repo I'm proposing bitcoin/bitcoin be repurposed to. But
for a v1, we can K.I.S.S.:
- bitcoin/bitcoin-node continues as an exact duplicate of the current
bitcoin/bitcoin (heading into using the NEW core, eventually)
- bitcoin/bitcoin is renamed to bitcoin/bitcoin-core, and can start
fat-trimming (heading into libbitcoinkernel integration, apparently)
Or we can just revert <https://github.com/bitcoin/bitcoin/pull/33682>
defaults.
Let's be adults. Do you really want to continue fighting? There's this
thing called the golden rule, and Core broke it. Accept it, let's fix what
we can, and move on.
I anticipate this whole situation has been very educational for many, and
it is actually GOOD to have the option to use multiple OP_RETURNs instead
of burn outputs. But a 1000x increase of non-transactional arbitrary data
by default, is undeniably abusive and risky. Which we are experiencing the
consequences of... Let's stop the escalation!
On Friday, October 31, 2025 at 8:09:25 PM UTC-4 Antoine Riard wrote:
> Hi Juan,
>
> Confirming you that libbitcoinkernel is mature enough to hack on it.
>
> Completely split out the mempool from the validation engine on
> bitcoinbackbone.org.
>
> ```
> block-daemon:
> cargo build --bin block_relayd
> cp target/debug/block_relayd block_relayd
>
> addr-daemon:
> cargo build --bin addr_relayd
> cp target/debug/addr_relayd addr_relayd
>
> tx-daemon:
> cargo build --bin tx_relayd
> cp target/debug/tx_relayd tx_relayd
>
> topo-daemon:
> cargo build --bin topo_mngrd
> cp target/debug/topo_mngrd topo_relayd
>
> mempool-daemon:
> cargo build --bin mempool_mngrd
> cp target/debug/mempool_mngrd mempool_mngrd
>
> txcontroller-daemon:
> cargo build --bin tx_controllerd
> cp target/debug/tx_controllerd tx_controllerd
>
> backbone-cli:
> rm -f backbone-cli
> cargo build --bin backbone-cli
> cp target/debug/backbone-cli backbone-cli
>
> ```
>
> Now I can be the Staline of my own relay policy, and I'm very happy with
> that.
>
> Define "power" seriously, I read almost the integrality of Michel
> Foucault, and I don't get you.
>
> Best,
> Antoine
> OTS hash: 3f4d81c217237a38d5f47457d51c9e6990068e47
> Le vendredi 31 octobre 2025 à 19:14:30 UTC, Juan Aleman a écrit :
>
>> 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.
>> "Official Bitcoin Core" has become itself the power grab.
>>
>> 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 PM UTC-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 spending their efforts trying to harm
>>> something they love just to satisfy other people who disagree with them.
>>> Maybe they are wrong, but fortunately you have the freedom to go your own
>>> way. There is no 'official' anything. Continuing to try to coerce others
>>> to do what you want when they think it would be wrong and harmful is a bad
>>> choice which will make enemies out of people who otherwise would be
>>> indifferent to your efforts that they regard as misguided.
>>>
>>>
>>> On Fri, Oct 31, 2025 at 6:41 PM Juan Aleman <bitco...@juanaleman.com>
>>> wrote:
>>>
>>>> Hello Greg, thanks for your feedback. I am already starting to do
>>>> something
>>>> <https://github.com/jotapea/bitcoin/commit/97d61c4b8eb0c044b06e1a8d5f280b17a6d7b5aa>,
>>>> but the main point IS about the centralization risks of the "official"
>>>> repo...
>>>>
>>>> On Friday, October 31, 2025 at 2:24:36 PM UTC-4 Greg Maxwell wrote:
>>>>
>>>>> 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 <bitco...@juanaleman.com>
>>>>> 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 <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+...@googlegroups.com.
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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+...@googlegroups.com.
>>>>
>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
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/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17625 bytes --]
next prev parent reply other threads:[~2025-11-01 16:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 17:54 Juan Aleman
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 [this message]
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=f60a2f77-ab31-4bde-ad5b-736a0f19a915n@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