From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 17:09:33 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEzBU-0007tF-6K for bitcoindev@gnusha.org; Fri, 31 Oct 2025 17:09:33 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3c9b7ffe2c4sf1355764fac.0 for ; Fri, 31 Oct 2025 17:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761955765; x=1762560565; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=1HBEbaoHMzYFnSrXTMlhtG3g0WfvkGDsrQpJTNcPHRo=; b=osvRqxkIuCI1rSGs8yL6zraaNdcM9+mQMv7zU3FXQUWbXUUz3evv2YL59E3XbWVGux /pRVD95FRYRKlO9OVXK6fzT3G0HL5Ii0rsOcvavMIToq2RR6V8ZEbXSmImbuq+RLmWe+ jo97Geun2HRa6RhqZni10Tm9e4KQBCvT4kgOmuZHF9XKCUL21kDuTQbil8esulQ5A27h kvTHI3OQz4/0BO4nNHRILI880lFYhkvK+Tpc/LcUIbMfVuVP9LIhqCJR3hAJqZcvV8CF 1t2uyieSKEVNiWKLzDCGZtXvXjsNZ4a4COJhSJIuJew3xNPxpstQUjv/na4kIVxpXHA8 PC/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761955765; x=1762560565; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=1HBEbaoHMzYFnSrXTMlhtG3g0WfvkGDsrQpJTNcPHRo=; b=Cq2Lws23ub+uO7scExNm3lUug2XAeYW+YueWI7N+d+jZFgESchsuHL/CRr3L7AcQ9d PWD4vxJ8FvP6CcrUxUrGwlQEwVin8gq8RQqoshtkhukofnM8QSz9RATFfTJQuK8lJ1GU OHhB4qtQP1TqyufDMQ856SxR9uD29Uu5pH3oAcrW31j12gYQZdKYJNPsRMGaoVgVtjfh saaTbyEH7nvzBkIbD8P3E5T5a0kfWzbVLWkAV0+NtmmJChr+R0gJlLyk/59zbO4uIVs0 5NjUdIFYv4oqRdsptNwxmiFPe6MHghbKtzxRHs+AJ1xVXeLICL182mVLrvgaz6uA3Scj QDww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761955765; x=1762560565; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=1HBEbaoHMzYFnSrXTMlhtG3g0WfvkGDsrQpJTNcPHRo=; b=DLZfggOpQ7p0SQZBYmnZmrSVIVBXMg8argZmLHWsnLnazUWG9JFD4zpTsbzBDS5c4h 2CASBvI/UErtBk96tL1rQe0qYGdolByFrdmv8jvPxrzA3hbCZZQseOXhXa6ebqtdBGHT fk2Gemej62OYGEkGJuURTYh9OXOSTatm8Ec1DyUNOxpXJFmbri/IIqpwQPAXSmh5Sqtu 5PcKATIpf7h1RSMTQvD0Uref1wvrYxd49jZHplc2QX28dhaaLJaxybfOTJ1h27nNMNbk YjQ8lGf5nHKN+ISVV0vDYdS4UiqQLldZmPh/+YOPOtogHZXUON4O7uIusvKX+dOS9+dM TXNg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVpjH8B3zR0f/XlcHRDIukWmQY0V1vrJGzTLPNEIj4vun7DLLk+xCM7s9a/C+JlMa5dWPnoR0rhfDXu@gnusha.org X-Gm-Message-State: AOJu0Yy0N0xwIl5NgZT4tcCdZ0y/aWsRuLWv7gnL2oxxnBTSdnVmfkhJ chpU9nV1JCyg1H7DD4wnESULPh1vl0c7EgFObBg5GH+D93rtqFdugz/o X-Google-Smtp-Source: AGHT+IFcRO1KV9w51u/NYImzYCT8BDEvDkbvcyODBRhQwzBMPILuHggb72Udv7zaqIKZ4DaInZZHMg== X-Received: by 2002:a05:6870:2247:b0:3d5:90f3:648f with SMTP id 586e51a60fabf-3daca3135a0mr2672092fac.4.1761955765471; Fri, 31 Oct 2025 17:09:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bK0DmVe5lomzYZf0pp0fpNxV5YGy6nTHz5jk/NcVJeTA==" Received: by 2002:a05:6871:a218:b0:368:1447:4438 with SMTP id 586e51a60fabf-3d8bb301b8als806649fac.1.-pod-prod-06-us; Fri, 31 Oct 2025 17:09:21 -0700 (PDT) X-Received: by 2002:a05:6808:318a:b0:44f:8f27:e3d4 with SMTP id 5614622812f47-44f9603e644mr2908678b6e.67.1761955760983; Fri, 31 Oct 2025 17:09:20 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Fri, 31 Oct 2025 15:59:07 -0700 (PDT) X-Received: by 2002:a05:690c:9993:b0:784:9ff4:8c82 with SMTP id 00721157ae682-786485594a0mr45241327b3.62.1761951546330; Fri, 31 Oct 2025 15:59:06 -0700 (PDT) Date: Fri, 31 Oct 2025 15:59:06 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com> In-Reply-To: <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> References: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_268362_698599600.1761951546027" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_268362_698599600.1761951546027 Content-Type: multipart/alternative; boundary="----=_Part_268363_580887758.1761951546027" ------=_Part_268363_580887758.1761951546027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan, Confirming you that libbitcoinkernel is mature enough to hack on it. Completely split out the mempool from the validation engine on=20 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=20 that. Define "power" seriously, I read almost the integrality of Michel Foucault,= =20 and I don't get you. Best, Antoine OTS hash: 3f4d81c217237a38d5f47457d51c9e6990068e47 Le vendredi 31 octobre 2025 =C3=A0 19:14:30 UTC, Juan Aleman a =C3=A9crit : > Greg I actually agree there should be no "official" anything. That is why= =20 > I purposefully always use "quotes" around it. > > Unfortunately for both of us, this is not a reflection of reality.=20 > "Official Bitcoin Core" has become itself the power grab. > > My proposal is about bringing this to the forefront. Most discussions I= =20 > see revolve around who can win an argument. All these are distractions IM= O,=20 > the issue here IS with the structure we have "trusted" for so many years = is=20 > no longer viable. > > On Friday, October 31, 2025 at 2:48:48=E2=80=AFPM UTC-4 Greg Maxwell wrot= e: > >> Other people don't do what you want because they believe it would harm= =20 >> Bitcoin and they have no interest in spending their efforts trying to ha= rm=20 >> something they love just to satisfy other people who disagree with them.= =20 >> Maybe they are wrong, but fortunately you have the freedom to go your ow= n=20 >> way. There is no 'official' anything. Continuing to try to coerce othe= rs=20 >> to do what you want when they think it would be wrong and harmful is a b= ad=20 >> choice which will make enemies out of people who otherwise would be=20 >> indifferent to your efforts that they regard as misguided. >> >> >> On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Juan Aleman =20 >> wrote: >> >>> Hello Greg, thanks for your feedback. I am already starting to do=20 >>> something=20 >>> ,=20 >>> but the main point IS about the centralization risks of the "official"= =20 >>> repo... >>> >>> On Friday, October 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell wr= ote: >>> >>>> If you want that and think it would be valuable, feel free to create= =20 >>>> it. No one will stop you and you don't need anyone's permission. >>>> >>>> On Fri, Oct 31, 2025 at 6:20=E2=80=AFPM Juan Aleman =20 >>>> wrote: >>>> >>>>> Hello bitcoin developers, >>>>> >>>>> My name is Juan Alem=C3=A1n, and this is my first post to the mailing= list.=20 >>>>> But I've been involved with Bitcoin since 2017. First only as a hard = money=20 >>>>> investor, but later also as a developer, specially fascinated by this= =20 >>>>> permanent medium. I hope this proposal can be appreciated by all=20 >>>>> perspectives as a pragmatic (maybe unorthodox, but timely) solution t= o move=20 >>>>> forward in agreement. >>>>> >>>>> The changes in v30 defaults got my attention (similar to many of you)= ,=20 >>>>> as they are completely opposite to what has historically been "standa= rd"=20 >>>>> practice. A highly controversial change that surfaces the influence o= ver=20 >>>>> default policy in the network, escalating to the point of a fork=20 >>>>> proposal . >>>>> >>>>> First, it must be reminded that a fork should be unnecessary if=20 >>>>> defaults are simply reverted=20 >>>>> , while still allowing= =20 >>>>> all policy possibilities. >>>>> >>>>> After my second PR =20 >>>>> attempt was (also) closed (and I was blocked from the repo), I realiz= ed=20 >>>>> that the main issue here is social-political, not technical. It's abo= ut the=20 >>>>> powerful influence the "Official Reference Implementation" centralize= d node=20 >>>>> software repository has. >>>>> >>>>> This needs a different kind of solution. I'd like to propose a=20 >>>>> high-level structural change to the "Official Bitcoin Repository":=20 >>>>> 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=20 >>>>> also defining default relay and mining policies, among all other node= =20 >>>>> functionalities, in a single piece of software. This concentration of= =20 >>>>> responsibilities leads to elevating this single repository to a "pede= stal",=20 >>>>> thus a point of centralization, giving a few too much influence. >>>>> >>>>> This kind of influence can be considered "harm" when abrupt default= =20 >>>>> policy changes (like v30's shift toward permissive data carrying) dis= rupt=20 >>>>> "standard" network practices and its users. >>>>> >>>>> However, the v30 release itself may have caused a point of no return,= =20 >>>>> where "globally agreed standardness" is no longer a realistic expecta= tion.=20 >>>>> Bitcoin's hidden limits are being revealed. >>>>> >>>>> *Proposal:* >>>>> >>>>> To address humans' flaws, I suggest reorganizing the repository=20 >>>>> structure to better safeguard against unwarranted political (policy)= =20 >>>>> influence. >>>>> >>>>> *1. Rename and Refocus Core Repo:* >>>>> >>>>> Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This= =20 >>>>> repo would focus mainly on consensus rules, removing arbitrary or=20 >>>>> non-critical policies from its scope. It becomes a neutral base for A= LL=20 >>>>> node implementations, emphasizing on hardening and testing consensus= =20 >>>>> without policy distractions. >>>>> >>>>> *2. Introduce Node Client Repo(s):* >>>>> >>>>> Create a separate repository for the full-featured node client,= =20 >>>>> starting with (github.com/)bitcoin/bitcoin-node as the foundational= =20 >>>>> template. This would effectively serve as the direct replacement for = the=20 >>>>> current bitcoin/bitcoin node software. This repository embeds the=20 >>>>> consensus-focused bitcoin-core (objective), while including "current = core=20 >>>>> devs"-recommended default policies (subjective). Other clients would = use=20 >>>>> this as their foundation, to customize policy and beyond. (Also, ther= e is=20 >>>>> nothing preventing multiple bitcoin-node- existing in parallel,= best=20 >>>>> addressing default-bias concerns.) >>>>> >>>>> >>>>> The initial implementation of this separation might not be elegant,= =20 >>>>> but future releases can progressively refactor based on this new=20 >>>>> reorganization, potentially incorporating more modularity (where=20 >>>>> beneficial). >>>>> >>>>> For a smooth transition that resolves ongoing tensions, the suggested= =20 >>>>> first release of bitcoin/bitcoin-node should revert to pre-v30 defaul= ts.=20 >>>>> Then, a subsequent release could adopt v30 defaults, with the home RE= ADME=20 >>>>> clearly documenting options/alternatives (e.g. "For legacy Money-Firs= t=20 >>>>> policies, use X"). >>>>> >>>>> *(But STILL the simplest solution is just to allow something like thi= s=20 >>>>> . And let's just move = on!=20 >>>>> Open-Data is out of the bag anyway.)* >>>>> >>>>> This proposal attempts to find a compromise where no side feels=20 >>>>> "forced to comply", and represents a more neutral position from the= =20 >>>>> "Official Reference Implementation" repository in this new era. >>>>> >>>>> *Benefits:* >>>>> >>>>> - Bitcoin-Core reaches its epitome, focusing on a hardened=20 >>>>> consensus core that serves all clients, regardless of policy. >>>>> - Reduction of the "official" repo's influence on default policy,= =20 >>>>> better aligning with Bitcoin's decentralization principles. >>>>> >>>>> >>>>> *Drawbacks:* >>>>> >>>>> - Breaks existing infrastructure tied to github.com/bitcoin/bitcoi= n.=20 >>>>> However, bitcoin/bitcoin-node is a 1-to-1 replacement, mitigating = deep=20 >>>>> disruptions (which some will see as a benefit, forcing a conscious= choice=20 >>>>> about what node software to run moving forward). >>>>> - Also, there must be caution of not using the original=20 >>>>> github.com/bitcoin/bitcoin name for anything else, as that would= =20 >>>>> break automatic GitHub url redirects. >>>>> >>>>> >>>>> >>>>> Thank you for your time. This is just an idea I wanted to share for= =20 >>>>> discussion, and I would appreciate any thoughts. >>>>> >>>>> Juan=20 >>>>> >>>>> --=20 >>>>> You received this message because you are subscribed to the Google=20 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-= aca2cfc9da32n%40googlegroups.com=20 >>>>> >>>>> . >>>>> >>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> >> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-53= 5d965f3a74n%40googlegroups.com=20 >>> >>> . >>> >> --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 5b81ebfc-7e9e-4e6b-908a-dc538d032908n%40googlegroups.com. ------=_Part_268363_580887758.1761951546027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan,

Confirming you that libbitcoinkernel is mature enough t= o hack on it.

Completely split out the mempool from the validati= on engine on bitcoinbackbone.org.

```
block-daemon:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin block_relayd
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 cp target/debug/block_relayd block_relayd

addr= -daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin addr_relayd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/addr_relayd addr_relayd
=
tx-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin tx_rela= yd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/tx_relayd tx_relayd

topo-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin top= o_mngrd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/topo_mngrd topo_re= layd

mempool-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo buil= d --bin mempool_mngrd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/memp= ool_mngrd mempool_mngrd

txcontroller-daemon:
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 cargo build --bin tx_controllerd
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 cp target/debug/tx_controllerd tx_controllerd

backbone-cl= i:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -f backbone-cli
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 cargo build --bin backbone-cli
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 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 Mich= el Foucault, and I don't get you.

Best,
Antoine
OTS ha= sh: 3f4d81c217237a38d5f47457d51c9e6990068e47
Le vendredi 31 octobre 2025 =C3=A0 19:14= :30 UTC, Juan Aleman a =C3=A9crit=C2=A0:
Greg I actually agree there should be no &= quot;official" anything. That is why I purposefully always use "q= uotes" around it.

Unfortunately for both of u= s, this is not a reflection of reality. "Official Bitcoin Core" h= as become itself the power grab.

My proposal is ab= out bringing this to the forefront. Most discussions I see revolve around w= ho can win an argument. All these are distractions IMO, the issue here IS w= ith the structure we have "trusted" for so many years is no longe= r viable.

On Friday, October 31, 2025 at 2:48:48=E2=80=AFPM UTC-4 Greg Maxw= ell wrote:
Other people don't do what you want because they believe it = would harm Bitcoin and they have no interest in=C2=A0spending their efforts= trying to harm something they love just to satisfy other people who disagr= ee with them.=C2=A0 Maybe they are wrong, but fortunately you have the free= dom to go your own way.=C2=A0 There is no 'official' anything.=C2= =A0 Continuing=C2=A0to try to coerce=C2=A0others to do what you want when t= hey think it would be wrong and harmful is a bad choice which will make ene= mies out of people who otherwise would be indifferent to your efforts that = they regard as misguided.


On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Juan Aleman <bitco...@juanaleman.com> wrote:
Hello Greg, th= anks for your feedback. I am already starting to do something, but the main poin= t IS about the centralization risks of the "official" repo...
=
On Fr= iday, October 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell wrote:
<= /div>
If you want that and=C2=A0think it would be valuable, feel free to create= it. No one will stop you and you don't need anyone's permission.

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 31, 2025 at 6:20=E2=80=AFP= M Juan Aleman <bitco...@juanaleman.com> wrote= :
Hello bitcoin developers,

My name is Juan Alem=C3= =A1n, and this is my first post to the mailing list. But I've been invo= lved with Bitcoin since 2017. First only as a hard money investor, but late= r also as a developer, specially fascinated by this permanent medium. I hop= e this proposal can be appreciated by all perspectives as a pragmatic (mayb= e 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 d= efault policy in the network, escalating to the point of a fork proposal.

First,= it must be reminded that a fork should be unnecessary if defaults are simp= ly reve= rted, while still allowing all policy possibilities.

After my se= cond PR<= /a> 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 abou= t the powerful influence the "Official Reference Implementation" = centralized node software repository has.

This needs a different kin= d of solution. I'd like to propose a high-level structural change to th= e "Official Bitcoin Repository": Separating consensus code from p= olicy-based node distribution.

Problem Statement:

The = "official" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) maintains cons= ensus code while also defining default relay and mining policies, among all= other node functionalities, in a single piece of software. This concentrat= ion of responsibilities leads to elevating this single repository to a &quo= t;pedestal", thus a point of centralization, giving a few too much inf= luence.

This kind of influence can be considered "harm" wh= en abrupt default policy changes (like v30's shift toward permissive da= ta carrying) disrupt "standard" network practices and its users.<= br>
However, the v30 release itself may have caused a point of no return= , where "globally agreed standardness" is no longer a realistic e= xpectation. Bitcoin's hidden limits are being revealed.

Propo= sal:

To address humans' flaws, I suggest reorganizing the re= pository structure to better safeguard against unwarranted political (polic= y) influence.

1. Rename and Refocus Core Repo:

=C2=A0 = =C2=A0 Rename (github.com/)bit= coin/bitcoin to bitcoin/bitcoin-core. This repo would focus mainly on c= onsensus rules, removing arbitrary or non-critical policies from its scope.= It becomes a neutral base for ALL node implementations, emphasizing on har= dening and testing consensus without policy distractions.

2. Intr= oduce Node Client Repo(s):

=C2=A0 =C2=A0 Create a separate repos= itory for the full-featured node client, starting with (github.com/)bitcoin/bitcoin-node as= the foundational template. This would effectively serve as the direct repl= acement for the current bitcoin/bitcoin node software. This repository embe= ds the consensus-focused bitcoin-core (objective), while including "cu= rrent core devs"-recommended default policies (subjective). Other clie= nts would use this as their foundation, to customize policy and beyond. (Al= so, 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 eleg= ant, but future releases can progressively refactor based on this new reorg= anization, 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. Th= en, a subsequent release could adopt v30 defaults, with the home README cle= arly documenting options/alternatives (e.g. "For legacy Money-First po= licies, use X").

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

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

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

Drawbacks:
  • Breaks existi= ng infrastructure tied to github= .com/bitcoin/bitcoin. However, bitcoin/bitcoin-node is a 1-to-1 replace= ment, mitigating deep disruptions (which some will see as a benefit, forcin= g a conscious choice about what node software to run moving forward).
    • <= li>Also, there must be caution of not using the original github.com/bitcoin/bitcoin name for anything e= lse, 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da3= 2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a7= 4n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/5b81ebfc-7e9e-4e6b-908a-dc538d032908n%40googlegroups.com.
------=_Part_268363_580887758.1761951546027-- ------=_Part_268362_698599600.1761951546027--