* [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
@ 2025-10-31 17:54 Juan Aleman
2025-10-31 18:21 ` Greg Maxwell
2025-10-31 18:36 ` Matt Corallo
0 siblings, 2 replies; 12+ messages in thread
From: Juan Aleman @ 2025-10-31 17:54 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 17:54 [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation Juan Aleman
@ 2025-10-31 18:21 ` Greg Maxwell
2025-10-31 18:32 ` Juan Aleman
2025-10-31 18:36 ` Matt Corallo
1 sibling, 1 reply; 12+ messages in thread
From: Greg Maxwell @ 2025-10-31 18:21 UTC (permalink / raw)
To: Juan Aleman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6630 bytes --]
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 <bitcoindev@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+unsubscribe@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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTNs%2B04X_pVLx%2BEXUUMk7bzTG2-qGHDTZ5NwxaMDkjp6g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7871 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 18:21 ` Greg Maxwell
@ 2025-10-31 18:32 ` Juan Aleman
2025-10-31 18:47 ` Greg Maxwell
0 siblings, 1 reply; 12+ messages in thread
From: Juan Aleman @ 2025-10-31 18:32 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7131 bytes --]
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10611 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 17:54 [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation Juan Aleman
2025-10-31 18:21 ` Greg Maxwell
@ 2025-10-31 18:36 ` Matt Corallo
2025-10-31 18:51 ` Juan Aleman
1 sibling, 1 reply; 12+ messages in thread
From: Matt Corallo @ 2025-10-31 18:36 UTC (permalink / raw)
To: Juan Aleman; +Cc: bitcoindev
[-- Attachment #1: Type: text/html, Size: 7414 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 18:32 ` Juan Aleman
@ 2025-10-31 18:47 ` Greg Maxwell
2025-10-31 18:56 ` Juan Aleman
0 siblings, 1 reply; 12+ messages in thread
From: Greg Maxwell @ 2025-10-31 18:47 UTC (permalink / raw)
To: Juan Aleman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8446 bytes --]
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 <bitcoindev@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+unsubscribe@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/CAAS2fgQYKDHS3C%3DTuTACUoH%2B59rkfCXkqAzSd9Jev9ik%3DE5%3D1g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10384 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 18:36 ` Matt Corallo
@ 2025-10-31 18:51 ` Juan Aleman
0 siblings, 0 replies; 12+ messages in thread
From: Juan Aleman @ 2025-10-31 18:51 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7260 bytes --]
Hello Matt, thanks for your response.
I searched about libbitcoinkernel and it does look like some effort is
being put into the creation of this library.
But again, my focus is SPECIFICALLY on the powerful influence of the
bitcoin/bitcoin repo itself. If you don't this merits a BIP, what would be
the appropriate avenue to address and potentially do something about
reorganizing the repo itself?
On Friday, October 31, 2025 at 2:41:30 PM UTC-4 Matt Corallo wrote:
> You should probably dig into the libbitcoinkernel project (and the immense
> amount of work that has gone into it, as well as the immense amount of work
> that it requires). Also this is not anything that would merit a BIP.
>
> On Oct 31, 2025, at 14:20, 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/73a08ea3-b9be-424b-a1cb-beac3206723cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10866 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 18:47 ` Greg Maxwell
@ 2025-10-31 18:56 ` Juan Aleman
2025-10-31 22:59 ` Antoine Riard
0 siblings, 1 reply; 12+ messages in thread
From: Juan Aleman @ 2025-10-31 18:56 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9266 bytes --]
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/9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 13799 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-10-31 18:56 ` Juan Aleman
@ 2025-10-31 22:59 ` Antoine Riard
2025-11-01 15:59 ` Juan Aleman
0 siblings, 1 reply; 12+ messages in thread
From: Antoine Riard @ 2025-10-31 22:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10745 bytes --]
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/5b81ebfc-7e9e-4e6b-908a-dc538d032908n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15506 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
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
0 siblings, 2 replies; 12+ messages in thread
From: Juan Aleman @ 2025-11-01 15:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
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
1 sibling, 0 replies; 12+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-11-01 17:54 UTC (permalink / raw)
To: Juan Aleman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 12922 bytes --]
Juan,
Bitcoin Core only sets default for those users who choose to run it.
You may disagree with Bitcoin Core users' choice of software, but your failure to persuade them to run something else does not entitle you to force authors of the software they run to make undesirable changes by fantasizing about their public workplace.
You know who ultimately controls the bitcoin/bitcoin repo? Microsoft. Bitcoin would be completely uninteresting if this had any bearing on the definition of the system.
The bitcoin-dev mailing list is an appropriate venue to share your work on an alternative approach to developing a Bitcoin client. It is not one for spamming all subscribers to this list with a demagogic attempt at redefining the voluntary nature of Bitcoin.
Antoine Poinsot
On Saturday, November 1st, 2025 at 12:58 PM, Juan Aleman <bitcoindev@juanaleman.com> wrote:
> 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.
>>>>>
>>>>> --
>>>>> 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.
>
> --
> 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.
--
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/fofKj6a1afiS_xE53RaeN6ipreL9rkpHda8IV2ihSIJKP2Y4vn3nyjYB0ogyq9H0AOJbkSc9AHlOlcQHMBdCOXOc5d3Qd62836mtWW0w8cc%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 19996 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
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
1 sibling, 1 reply; 12+ messages in thread
From: Antoine Riard @ 2025-11-02 20:04 UTC (permalink / raw)
To: Juan Aleman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 17563 bytes --]
Hi Juan,
Not sure if you're confusing me with the other Antoine or not,
but still here my honest answer to your post.
The power is within the hands of the multitude of users.
The users are the ones who freely picked up a full-node software,
use it to support their bitcoin endeavors, recommend it to their
friends, bring back technical feedback to the devs to improve it,
make it the evangelism for free at their local meetup or on social
network and ultimately who are free to allocate capital and ressources
to further the development of a full-node software.
If you think that bitcoin core isn't adverse to the desiderata of the
users, I do think the lastest months where we have seen an alternative
client suddenly being adopted by large swarm of full-node operators is
quite telling. While core has been deemed being in a situation of quasi-
monopoly for years and that situation would be de facto immutable, the
story of the last months points towards another reality.
So there is no real "repository authority" as you're describing, or if
there is one it's rather because season after season, we see the same
cycle repeating. Some groups of users or developers wish to have their
consensus ideas or policy mechanisms adopted in bitcoin (core), there is
a grounded pushback from another faction of users and developers and then
the first dimissed group goes to re-patch their ideas on top of a core
fork and finally engage in a "my way or the fork highway" kind of
escalation.
In my view, the root of the problem is not that "Core" is "corrupted" or
"compromised". It's a human institution, so of course there are things that
can be improved, and things are constantly improved. The real problem is
that
most of the time, the dissatisfied of the Core process don't have the cold
determination to go for real in developing their own alternative bitcoin
clients, with its own set of features, its own culture of development and
in patiently growing its user base.
Apologies if I say something obvious, but it's not by threatening to
soft-fork
that a full-node project is going to earn the credibility and the "trust" of
large swarm of the community. Quite the contrary, it's more likely to have
the
opposite effect in the low-time preference minds. Basic of "product
management",
if you have hundreds of users that are okay to choose a lower quality
software
because of default settings, that's great news. You have already a niche,
now
professionalize a bit the project and keep growing from it.
I really hope that one of the positive outcome that will emerge from the
last
months of circus will be that finally that Bitcoin Gnocchi starts to be a
real
project, that it grows its own community of contributors and go to live
more a
life of its own. And if Gnocchi is not a delicious enough software in the
taste
of some, the good news is that libbitcoinkernel probably slashes by few
order of
magnitude the complexity of building a full-node. More freedom to make your
own
kitchen and cook your own recipes.
Frankly, what you're proposing with the repository label renaming, it's
just cosmetic.
Bitcoin core won't loose its shamanic-like "authority" just because some
repository
would have changed its name. But because, there would be an ecosystem with
multiple
high-quality well-maintained clients to pick up from, and network-wide
change would
have to be the fruit of a high-flying technical debate, or at least to be
experimented
on its own by an implementation for a while resulting in unequivocal
improvements.
But on the stability of the network and not slipping into fork adventurism,
bitcoin
core is right here and one can be sure I share plainly the opinion of many
of core
contributors.
Best,
Antoine
OTS hash: 17d321f45c7499543a96fb660d9e18ba6448bb9514d51c77e7868d5bdb125b95
Le sam. 1 nov. 2025 à 16:58, Juan Aleman <bitcoindev@juanaleman.com> a
écrit :
> 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 a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/hb39zFTnYLc/unsubscribe.
> To unsubscribe from this group and all its topics, 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
> <https://groups.google.com/d/msgid/bitcoindev/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%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/CALZpt%2BE%2BepbPTH%2Bv3UOw-dS6UfXhPysmmx-b5Aj7zkND_uuj9A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 20744 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation
2025-11-02 20:04 ` Antoine Riard
@ 2025-11-02 20:43 ` Juan Aleman
0 siblings, 0 replies; 12+ messages in thread
From: Juan Aleman @ 2025-11-02 20:43 UTC (permalink / raw)
To: Antoine Riard; +Cc: Juan Aleman, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 19030 bytes --]
Hello Antoine,
For a moment I did confuse you, but (at least part of) the response still
applies ;)
Seriously though, thank you for your elaborated response. I think you
actually agree with the structural issue when bitcoin/bitcoin is called
Bitcoin Core, but is actually a one-stop client application, the reference
implementation of what has been Bitcoin since Satoshi.
It creates this “elite”. This “elite” is not a very organic grown species,
is trust based. 99% of your marketers and customers don’t verify anything.
I for sure could, but never did. I delegated that responsibility… until v30
(and I should have been like this since Segwit, but that was ahead of me).
But you’re also telling me that you don’t have to change anything. And I
agree.
I’m just sharing what I would do, to end the divide, and don’t get
conquered.
Thank you for your feedback.
Juan
On Sun, Nov 2, 2025 at 4:04 PM Antoine Riard <antoine.riard@gmail.com>
wrote:
> Hi Juan,
>
> Not sure if you're confusing me with the other Antoine or not,
> but still here my honest answer to your post.
>
> The power is within the hands of the multitude of users.
>
> The users are the ones who freely picked up a full-node software,
> use it to support their bitcoin endeavors, recommend it to their
> friends, bring back technical feedback to the devs to improve it,
> make it the evangelism for free at their local meetup or on social
> network and ultimately who are free to allocate capital and ressources
> to further the development of a full-node software.
>
> If you think that bitcoin core isn't adverse to the desiderata of the
> users, I do think the lastest months where we have seen an alternative
> client suddenly being adopted by large swarm of full-node operators is
> quite telling. While core has been deemed being in a situation of quasi-
> monopoly for years and that situation would be de facto immutable, the
> story of the last months points towards another reality.
>
> So there is no real "repository authority" as you're describing, or if
> there is one it's rather because season after season, we see the same
> cycle repeating. Some groups of users or developers wish to have their
> consensus ideas or policy mechanisms adopted in bitcoin (core), there is
> a grounded pushback from another faction of users and developers and then
> the first dimissed group goes to re-patch their ideas on top of a core
> fork and finally engage in a "my way or the fork highway" kind of
> escalation.
>
> In my view, the root of the problem is not that "Core" is "corrupted" or
> "compromised". It's a human institution, so of course there are things that
> can be improved, and things are constantly improved. The real problem is
> that
> most of the time, the dissatisfied of the Core process don't have the cold
> determination to go for real in developing their own alternative bitcoin
> clients, with its own set of features, its own culture of development and
> in patiently growing its user base.
>
> Apologies if I say something obvious, but it's not by threatening to
> soft-fork
> that a full-node project is going to earn the credibility and the "trust"
> of
> large swarm of the community. Quite the contrary, it's more likely to have
> the
> opposite effect in the low-time preference minds. Basic of "product
> management",
> if you have hundreds of users that are okay to choose a lower quality
> software
> because of default settings, that's great news. You have already a niche,
> now
> professionalize a bit the project and keep growing from it.
>
> I really hope that one of the positive outcome that will emerge from the
> last
> months of circus will be that finally that Bitcoin Gnocchi starts to be a
> real
> project, that it grows its own community of contributors and go to live
> more a
> life of its own. And if Gnocchi is not a delicious enough software in the
> taste
> of some, the good news is that libbitcoinkernel probably slashes by few
> order of
> magnitude the complexity of building a full-node. More freedom to make
> your own
> kitchen and cook your own recipes.
>
> Frankly, what you're proposing with the repository label renaming, it's
> just cosmetic.
> Bitcoin core won't loose its shamanic-like "authority" just because some
> repository
> would have changed its name. But because, there would be an ecosystem with
> multiple
> high-quality well-maintained clients to pick up from, and network-wide
> change would
> have to be the fruit of a high-flying technical debate, or at least to be
> experimented
> on its own by an implementation for a while resulting in unequivocal
> improvements.
>
> But on the stability of the network and not slipping into fork
> adventurism, bitcoin
> core is right here and one can be sure I share plainly the opinion of many
> of core
> contributors.
>
> Best,
> Antoine
> OTS hash: 17d321f45c7499543a96fb660d9e18ba6448bb9514d51c77e7868d5bdb125b95
>
> Le sam. 1 nov. 2025 à 16:58, Juan Aleman <bitcoindev@juanaleman.com> a
> écrit :
>
>> 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 a topic in the
>> Google Groups "Bitcoin Development Mailing List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/bitcoindev/hb39zFTnYLc/unsubscribe.
>> To unsubscribe from this group and all its topics, 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
>> <https://groups.google.com/d/msgid/bitcoindev/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%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/CADNMaA4vWnDMoPOc%2B7tUOnYap%2BPLxnj2HS0rMz0Ecd11OQwxJQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 23451 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-11-02 20:58 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-31 17:54 [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox