From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 01 Nov 2025 09:58:58 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vFEwL-0008Ft-0y for bitcoindev@gnusha.org; Sat, 01 Nov 2025 09:58:58 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6569f275184sf369375eaf.0 for ; Sat, 01 Nov 2025 09:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762016331; x=1762621131; 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=x1RSeZB3VDuF5i2ERWmWYud3y0j7Yk1mWtdmo3Tm3LE=; b=kNv7jKUIyAYtY86ZbBg4ZaArvszy/Lohk0VPVouclkiRD1fO3y19ZIVzTZTkqjkeKo +ANt5UyD3qGmAKeW0mizo/ulFo5L2wKRxXcXSjUztyf+kMVCzEl67xNhjkKjtaaP2ZJw salClEsFW87jYIL4upd/1+3K+0qnFa20UjNsWALow7T3Az3lp16U9OvueFVmV7o+AaIm HygUjla9WKO7V8gc62U4CakMoKNUBWRXc9INxC0hWjt6FY1kq0yYGFYjT6kWU6bpT6jy TLqKytTqnWQR04XGBXeMOson4tAHaQHcODZx8jB8yvkO5YAVl0mMdQUvrfezbLUsy9Qg Ia9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1762016331; x=1762621131; 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=x1RSeZB3VDuF5i2ERWmWYud3y0j7Yk1mWtdmo3Tm3LE=; b=1364UHV3QsDL6wImZUGST72iR5IL06vk2Burggbs5lFufRJ9IKMIx9/jptS3f4kdK3 3XfEKxzRJdRErWDAPifVkpDErOykwIyHH5A++7WQEZEun+doeFcZ/mDyRpzoQ5pnVsha bdq4a1Q8TOKAruI+w+CLskq6kl8sHzJs0JL8cuX308gwmBF181bQbVFMzhX8gtPwdJYp NS1HHVtv3MoTHBKF6/KXwfmD6SHlc2zA32ARDLvi3panpN0z8MRSaRsc+ypJu3KBr/xR fWCX0/FZvqJwAYBDTB159QIPBJM0B+3wAJpg2HVu7q03tPYjlN/J3B4YnHNA93LxolAT 6nEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762016331; x=1762621131; 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=x1RSeZB3VDuF5i2ERWmWYud3y0j7Yk1mWtdmo3Tm3LE=; b=vHn/IeY1Px7ksvwrjPEbRsN8QxG32oxw+TTwtOjCj4rOIRvBBckfYGP5SAKYd1wgSj w9uYbrW4tzdwDJ80Pfmh6DbpFDTIfL2hmG+8j/XZ6DkOHc2wfL0UqANHoOfMpHvMc24U J+mdxCjsU2m7mAwxRXceC5o0MlJi5dmjxiFeKcJ34umksEDHETfDgib1t1EeTzlk2W0+ mJdyTfc4JgVJy2+4BEPo43ifcwtZ8QsDP/jB5JO7mNDZvtPg4Rj7DyDPw9QlSKYjNUX1 XyBbmJb8dFL6kNXF/oUgCsebKy809PFZYEkdKMgX44mcWbGtaR++h676zTSVxD3yugIv 6H4w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVb3Tn3XOm9okKs1RAePlAiXJnsmrCMiZor5y9opkN/Oy/Ed9ZNJ6PzEV8hwkhADZ7k6Gp9oS2naWEk@gnusha.org X-Gm-Message-State: AOJu0YxN3wj0b+dD6lCfnKdURuGfXduXXTpuqGwC9CREPhVQQ+A95mj6 HonVMgJt76LVYlXJecmbRs0RgxkT0b0IS40UtCyBTCr2WFZxZ61USZIT X-Google-Smtp-Source: AGHT+IFdOYMo8XFFfBdqzXFeDs1ib7rZKz/pTkOfn3C+XCwaynDgF47mC0XUyEB4CT3AXBLv1uOSow== X-Received: by 2002:a05:6870:b626:b0:3c9:77fb:dc3b with SMTP id 586e51a60fabf-3d8a5d009bdmr5295487fac.18.1762016330607; Sat, 01 Nov 2025 09:58:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Zftw4rNiRCLg7iV+648o+C8GJcrQG8sKUFdDNaJNyXvA==" Received: by 2002:a05:6871:4b04:b0:3da:e851:9752 with SMTP id 586e51a60fabf-3dae851a14bls1029474fac.1.-pod-prod-04-us; Sat, 01 Nov 2025 09:58:46 -0700 (PDT) X-Received: by 2002:a05:6808:c198:b0:442:82:3efe with SMTP id 5614622812f47-44f95df6fe5mr3255597b6e.14.1762016326854; Sat, 01 Nov 2025 09:58:46 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Sat, 1 Nov 2025 08:59:34 -0700 (PDT) X-Received: by 2002:a05:690c:7307:b0:786:5962:bb90 with SMTP id 00721157ae682-7865962bf50mr31265817b3.31.1762012774073; Sat, 01 Nov 2025 08:59:34 -0700 (PDT) Date: Sat, 1 Nov 2025 08:59:33 -0700 (PDT) From: Juan Aleman To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com> References: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com> Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_306072_580288060.1762012773720" X-Original-Sender: bitcoindev@juanaleman.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.7 (/) ------=_Part_306072_580288060.1762012773720 Content-Type: multipart/alternative; boundary="----=_Part_306073_1791718293.1762012773720" ------=_Part_306073_1791718293.1762012773720 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Antoine, Nice to meet you. The main issue here is with the bitcoin/bitcoin repo=20 itself. A single authority with too much influence, now escalating to the= =20 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=20 quite uncomfortable to be in deep conflicts with peers, and even friends.= =20 But "CoreDevs" seem way too invested to remain unbiased, clearly missing=20 the forest for the trees. Glad to learn that bitcoin/bitcoin-core already has some headway, seems=20 like libbitcoinkernel could eventually be integral in this new=20 consensus-focused repo I'm proposing bitcoin/bitcoin be repurposed to. But= =20 for a v1, we can K.I.S.S.: - bitcoin/bitcoin-node continues as an exact duplicate of the current=20 bitcoin/bitcoin (heading into using the NEW core, eventually) - bitcoin/bitcoin is renamed to bitcoin/bitcoin-core, and can start=20 fat-trimming (heading into libbitcoinkernel integration, apparently) Or we can just revert =20 defaults. Let's be adults. Do you really want to continue fighting? There's this=20 thing called the golden rule, and Core broke it. Accept it, let's fix what= =20 we can, and move on. I anticipate this whole situation has been very educational for many, and= =20 it is actually GOOD to have the option to use multiple OP_RETURNs instead= =20 of burn outputs. But a 1000x increase of non-transactional arbitrary data= =20 by default, is undeniably abusive and risky. Which we are experiencing the= =20 consequences of... Let's stop the escalation! On Friday, October 31, 2025 at 8:09:25=E2=80=AFPM 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=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=20 > Foucault, 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 wh= y=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 I= MO,=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 wro= te: >> >>> 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 h= arm=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 o= wn=20 >>> way. There is no 'official' anything. Continuing to try to coerce oth= ers=20 >>> to do what you want when they think it would be wrong and harmful is a = bad=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 w= rote: >>>> >>>>> 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 mailin= g=20 >>>>>> list. But I've been involved with Bitcoin since 2017. First only as = a hard=20 >>>>>> money 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 = to move=20 >>>>>> forward in agreement. >>>>>> >>>>>> The changes in v30 defaults got my attention (similar to many of=20 >>>>>> you), as they are completely opposite to what has historically been= =20 >>>>>> "standard" practice. A highly controversial change that surfaces the= =20 >>>>>> influence over default policy in the network, escalating to the poin= t 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=20 >>>>>> allowing all policy possibilities. >>>>>> >>>>>> After my second PR = =20 >>>>>> attempt was (also) closed (and I was blocked from the repo), I reali= zed=20 >>>>>> that the main issue here is social-political, not technical. It's ab= out the=20 >>>>>> powerful influence the "Official Reference Implementation" centraliz= ed 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 nod= e=20 >>>>>> functionalities, in a single piece of software. This concentration o= f=20 >>>>>> responsibilities leads to elevating this single repository to a "ped= estal",=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) di= srupt=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 expect= ation.=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.=20 >>>>>> This repo would focus mainly on consensus rules, removing arbitrary = or=20 >>>>>> non-critical policies from its scope. It becomes a neutral base for = ALL=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, the= re 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 suggeste= d=20 >>>>>> first release of bitcoin/bitcoin-node should revert to pre-v30 defau= lts.=20 >>>>>> Then, a subsequent release could adopt v30 defaults, with the home R= EADME=20 >>>>>> clearly documenting options/alternatives (e.g. "For legacy Money-Fir= st=20 >>>>>> policies, use X"). >>>>>> >>>>>> *(But STILL the simplest solution is just to allow something like=20 >>>>>> this . And let's just= move=20 >>>>>> on! 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=20 >>>>>> github.com/bitcoin/bitcoin. However, bitcoin/bitcoin-node is a=20 >>>>>> 1-to-1 replacement, mitigating deep disruptions (which some will = see as a=20 >>>>>> benefit, forcing a conscious choice about what node software to r= un moving=20 >>>>>> 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,=20 >>>>>> send 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-5= 35d965f3a74n%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/= f60a2f77-ab31-4bde-ad5b-736a0f19a915n%40googlegroups.com. ------=_Part_306073_1791718293.1762012773720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Antoine,

Nice to meet you. The main issue here is with the= bitcoin/bitcoin repo itself. A single authority with too much influence, n= ow 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, a= nd even friends. But "CoreDevs" seem way too invested to remain unbiased, c= learly missing the forest for the trees.

Glad to learn that bitc= oin/bitcoin-core already has some headway, seems like libbitcoinkernel coul= d eventually be integral in this new consensus-focused repo I'm proposing b= itcoin/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 bitco= in/bitcoin (heading into using the NEW core, eventually)
  • bitcoin/bi= tcoin is renamed to bitcoin/bitcoin-core, and can start fat-trimming (headi= ng into libbitcoinkernel integration, apparently)

Or we can = just revert d= efaults.

Let's be adults. Do you really want to continue fightin= g? 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 sit= uation 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 abus= ive and risky. Which we are experiencing the consequences of... Let's stop = the escalation!

On Friday, October 31, 2025 at 8:09:25=E2=80=AFPM UTC-4 A= ntoine Riard wrote:
Hi Juan,

Confirming you that libbitcoinkernel is mature enoug= h to hack on it.

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

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

addr-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin ad= dr_relayd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/addr_relayd addr_r= elayd

tx-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin tx= _relayd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/tx_relayd tx_relayd<= br>
topo-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin topo_m= ngrd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/topo_mngrd topo_relayd<= br>
mempool-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin mem= pool_mngrd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/mempool_mngrd mem= pool_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-cli:
=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 ba= ckbone-cli

```

Now I can be the Staline of my own relay polic= y, and I'm very happy with that.

Define "power" seriou= sly, I read almost the integrality of Michel Foucault, and I don't get = you.

Best,
Antoine
OTS hash: 3f4d81c217237a38d5f47457d51c9e699= 0068e47
Le= vendredi 31 octobre 2025 =C3=A0 19:14:30 UTC, Juan Aleman a =C3=A9crit=C2= =A0:
Greg I actua= lly agree there should be no "official" anything. That is why I p= urposefully 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 disc= ussions I see revolve around who can win an argument. All these are distrac= tions 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=E2=80=AFPM 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=C2=A0spending their efforts trying to harm something they love just to s= atisfy other people who disagree with them.=C2=A0 Maybe they are wrong, but= fortunately you have the freedom to go your own way.=C2=A0 There is no = 9;official' anything.=C2=A0 Continuing=C2=A0to try to coerce=C2=A0other= s to do what you want when they think it would be wrong and harmful is a ba= d choice which will make enemies out of people who otherwise would be indif= ferent to your efforts that they regard as misguided.

<= /div>
On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Jua= n Aleman <bitco...@juanaleman.com> wrote:
=
Hello Greg, thanks for your feedback. I am already starting t= o do some= thing, but the main point IS about the centralization risks of the &quo= t;official" repo...

On Friday, October 31, 2025 at 2:24:36=E2=80=AFPM UT= C-4 Greg Maxwell wrote:
If you want that and=C2=A0think it would be v= aluable, feel free to create it. No one will stop you and you don't nee= d anyone's permission.

=
On Fri, Oc= t 31, 2025 at 6:20=E2=80=AFPM 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 involved with Bitcoin since 2017. First only as a h= ard money investor, but later also as a developer, specially fascinated by = this permanent medium. I hope this proposal can be appreciated by all persp= ectives as a pragmatic (maybe unorthodox, but timely) solution to move forw= ard in agreement.

The changes in v30 defaults got my attention (simi= lar to many of you), as they are completely opposite to what has historical= ly been "standard" practice. A highly controversial change that s= urfaces the influence over default policy in the network, escalating to the= point of a fork= proposal.

First, it must be reminded that a fork should be unne= cessary if defaults are simply reverted, while still allowing all policy possib= ilities.

After my second PR attempt was (also) closed (and I was blocked= from the repo), I realized that the main issue here is social-political, n= ot technical. It's about the powerful influence the "Official Refe= rence Implementation" centralized node software repository has.
This needs a different kind of solution. I'd like to propose a high-le= vel structural change to the "Official Bitcoin Repository": Separ= ating consensus code from policy-based node distribution.

Problem= Statement:

The "official" Bitcoin Core node repositor= y (https://github.com/bitcoi= n/bitcoin) maintains consensus code while also defining default relay a= nd mining policies, among all other node functionalities, in a single piece= of software. This concentration of responsibilities leads to elevating thi= s single repository to a "pedestal", thus a point of centralizati= on, giving a few too much influence.

This kind of influence can be c= onsidered "harm" when abrupt default policy changes (like v30'= ;s shift toward permissive data carrying) disrupt "standard" netw= ork practices and its users.

However, the v30 release itself may hav= e caused a point of no return, where "globally agreed standardness&quo= t; is no longer a realistic expectation. Bitcoin's hidden limits are be= ing 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:

=C2=A0 =C2=A0 Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This= repo would focus mainly on consensus rules, removing arbitrary or non-crit= ical policies from its scope. It becomes a neutral base for ALL node implem= entations, emphasizing on hardening and testing consensus without policy di= stractions.

2. Introduce Node Client Repo(s):

=C2=A0 = =C2=A0 Create a separate repository for the full-featured node client, star= ting with (github.co= m/)bitcoin/bitcoin-node as the foundational template. This would effect= ively serve as the direct replacement for the current bitcoin/bitcoin node = software. This repository embeds the consensus-focused bitcoin-core (object= ive), while including "current core devs"-recommended default pol= icies (subjective). Other clients would use this as their foundation, to cu= stomize policy and beyond. (Also, there is nothing preventing multiple bitc= oin-node-<type> existing in parallel, best addressing default-bias co= ncerns.)


The initial implementation of thi= s separation might not be elegant, but future releases can progressively re= factor based on this new reorganization, potentially incorporating more mod= ularity (where beneficial).

For a smooth transition that resolves on= going tensions, the suggested first release of bitcoin/bitcoin-node should = revert to pre-v30 defaults. Then, a subsequent release could adopt v30 defa= ults, with the home README clearly documenting options/alternatives (e.g. &= quot;For legacy Money-First policies, use X").

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

This proposal attemp= ts to find a compromise where no side feels "forced to comply", a= nd represents a more neutral position from the "Official Reference Imp= lementation" repository in this new era.

Benefits:
  • Bitcoin-Core reaches its epitome, focusing on a hardened consensus co= re that serves all clients, regardless of policy.
  • Reduction of the = "official" repo's influence on default policy, better alignin= g with Bitcoin's decentralization principles.

    • Drawbacks= :
    • Breaks existing infrastructure tied to github.com/bitcoin/bitcoin. However, bitcoin/bi= tcoin-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 t= he original github.com/bitcoin/b= itcoin 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 appreci= ate 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/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%40googlegroups.com.
    ------=_Part_306073_1791718293.1762012773720-- ------=_Part_306072_580288060.1762012773720--