From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 12:14:16 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEuZj-0001Xh-Ts for bitcoindev@gnusha.org; Fri, 31 Oct 2025 12:14:16 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-65682d52356sf4872858eaf.0 for ; Fri, 31 Oct 2025 12:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761938049; x=1762542849; 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=6fKaVtEDDPg/D9ZcMBj54/AQx+Ct0xjMeU99HBpUGJM=; b=omiwwWUx8BIZE6DQlUpP+TJdBTisc8D6bc41TQBWte/TAsWKnwSrSmNE+czEld2Or0 YPzFKFPnGlD6joJEZ0QbiRgUcF7UACgiIzQTlkdJT37m4FTwNENLefbslEbMITY/3QSP IHWol8Yh6hL8qCfTky00LpWlDQJz0cKpM98qHHhOLrLvVCwwurUsoiBTNDasC4Zu1Sj/ TBJUnqyIpLYZqukrw9Gs24mfESWrhBSbZJasibOU9CUuy6YULeeJRHvLMvVZo5x8aZdW oNsUYoe6iVBDoS6P6UKb8hhYtWxFuqZ3ClEB0Bcr6RnV9sjmSjMlFihelntIJsVVl4sw zWCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1761938049; x=1762542849; 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=6fKaVtEDDPg/D9ZcMBj54/AQx+Ct0xjMeU99HBpUGJM=; b=kgEss2IB2qLY2xp33kNI6M5zw4Ze/M0y6oaThhbTqJ4iKT4i7Av+xqgT12g8sH3kPz b53w2cN2pSVbQnljeDpzAfUyemVkwonapf58KJ+dnGOfw9kFtUYz4YYpZM6lAZZb+Luq Yds8u32W38VdJ8LveI/cdXO2GEPW4BANOOGe9CQGKlHnnPH8rIttpN0NPMbjgB43toZw RG6aIz3FYqHfTX6ZrH/kb0nfOUdJddEfySAzmiV8Z800nkA2lJgSrP3gnbw+G5qYczJt ztjGdG0CDs1DCoReVkx9HV/FMPDpy4ZAywdDnbN7wd2Z3fwbkI2mLk/ecmRRLB83z7mP Vw9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761938049; x=1762542849; 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=6fKaVtEDDPg/D9ZcMBj54/AQx+Ct0xjMeU99HBpUGJM=; b=l0gqiNe4INRn7JlpwEXmf3lFgjSERTRbIt8N+yMAZL9aoOPyAVksaZfyHVFqwGbVS6 XhYRaBPHjehzLgrUnevOoqPd5Wxv5RyUQ02FftcfXYfluyo3MKtlCV2a0XrcJwEUmriD msejHFrGqbfOF/tA13lUkhMEI5M/Ib2sb5X2wNdewUQpl2rYl05WUk9/xK9Zloe/85oC yFkgD0QwyDxQbp5ylrhQvezxPOYsmodR2LzVf9KbSyKTVpwzc2p8jb4/tYa1b77Cmx06 G+zcPwRnTmrzkepdNEtRi6T0sh/TNQrnmqYX9L5BCTpluHH7Ui+J36E9nrkMIDVxqfl6 MJqw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVQFO3EH79Cc2HHSv7Sm5VBGZ72rATLt/UuZ2G+23pTxfU68jhANuobKx7fOHWA6uD0xVZoqz+gi2R2@gnusha.org X-Gm-Message-State: AOJu0YwtRhUtU4zGAqsLZQqqSxQr6aYqRcIiU2e1EeZF/Zow7oQXh53x kBHxqpfEOzCrbua9OhcZ6s5uSOGmadc+pfBeVUE3JwxBMSBrNAoZ9FEt X-Google-Smtp-Source: AGHT+IGeHUVWbPFw1ArlYPDGiXWT3o3YiweCOdhOj291ZYIiYbOm2623bsKeqpVytLGCeNwNV79HXA== X-Received: by 2002:a05:6808:1b90:b0:442:a3:fc48 with SMTP id 5614622812f47-44f95e3646bmr2210799b6e.5.1761938049444; Fri, 31 Oct 2025 12:14:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YbZnuKBYESYbPlpYpdn/6jhwQqafJrayyUmX4jxVXa7A==" Received: by 2002:a4a:d40a:0:b0:62e:2911:568b with SMTP id 006d021491bc7-6568248ad28ls913039eaf.1.-pod-prod-03-us; Fri, 31 Oct 2025 12:14:05 -0700 (PDT) X-Received: by 2002:a05:6808:3996:b0:44e:2f1b:e4b0 with SMTP id 5614622812f47-44f95fa5e2bmr1812227b6e.51.1761938044991; Fri, 31 Oct 2025 12:14:04 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Fri, 31 Oct 2025 11:51:19 -0700 (PDT) X-Received: by 2002:a53:b4cf:0:b0:63e:33a7:cdd7 with SMTP id 956f58d0204a3-63f92243e4bmr2458908d50.20.1761936678989; Fri, 31 Oct 2025 11:51:18 -0700 (PDT) Date: Fri, 31 Oct 2025 11:51:18 -0700 (PDT) From: Juan Aleman To: Bitcoin Development Mailing List Message-Id: <73a08ea3-b9be-424b-a1cb-beac3206723cn@googlegroups.com> In-Reply-To: <16007942-114D-4183-9CBB-BEEEF70E5F41@mattcorallo.com> References: <16007942-114D-4183-9CBB-BEEEF70E5F41@mattcorallo.com> Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_207082_10883312.1761936678455" 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_207082_10883312.1761936678455 Content-Type: multipart/alternative; boundary="----=_Part_207083_1012839131.1761936678455" ------=_Part_207083_1012839131.1761936678455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Matt, thanks for your response. I searched about libbitcoinkernel and it does look like some effort is=20 being put into the creation of this library. But again, my focus is SPECIFICALLY on the powerful influence of the=20 bitcoin/bitcoin repo itself. If you don't this merits a BIP, what would be= =20 the appropriate avenue to address and potentially do something about=20 reorganizing the repo itself? On Friday, October 31, 2025 at 2:41:30=E2=80=AFPM UTC-4 Matt Corallo wrote: > You should probably dig into the libbitcoinkernel project (and the immens= e=20 > amount of work that has gone into it, as well as the immense amount of wo= rk=20 > that it requires). Also this is not anything that would merit a BIP. > > On Oct 31, 2025, at 14:20, Juan Aleman wrote: > > =EF=BB=BFHello bitcoin developers, > > > > My name is Juan Alem=C3=A1n, and this is my first post to the mailing lis= t. But=20 > 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 to mo= ve=20 > forward in agreement. > > The changes in v30 defaults got my attention (similar to many of you), as= =20 > they are completely opposite to what has historically been "standard"=20 > practice. A highly controversial change that surfaces the influence over= =20 > default policy in the network, escalating to the point of a fork proposal= =20 > . > > First, it must be reminded that a fork should be unnecessary if defaults= =20 > are simply reverted ,=20 > while still allowing all policy possibilities. > > After my second PR =20 > attempt was (also) closed (and I was blocked from the repo), I realized= =20 > that the main issue here is social-political, not technical. It's about t= he=20 > powerful influence the "Official Reference Implementation" centralized no= de=20 > software repository has. > > This needs a different kind of solution. I'd like to propose a high-level= =20 > structural change to the "Official Bitcoin Repository": Separating=20 > 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= =20 > 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 "pedestal= ",=20 > thus a point of centralization, giving a few too much influence. > > This kind of influence can be considered "harm" when abrupt default polic= y=20 > changes (like v30's shift toward permissive data carrying) disrupt=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 expectation= .=20 > Bitcoin's hidden limits are being revealed. > > *Proposal:* > > To address humans' flaws, I suggest reorganizing the repository structure= =20 > to better safeguard against unwarranted political (policy) 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 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, there is= =20 > nothing preventing multiple bitcoin-node- existing in parallel, bes= t=20 > addressing default-bias concerns.) > > > The initial implementation of this separation might not be elegant, but= =20 > 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 defaults.= =20 > Then, a subsequent release could adopt v30 defaults, with the home README= =20 > clearly documenting options/alternatives (e.g. "For legacy Money-First=20 > policies, use X"). > > *(But STILL the simplest solution is just to allow something like this=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 "forced t= o=20 > comply", and represents a more neutral position from the "Official=20 > Reference Implementation" repository in this new era. > > *Benefits:* > > - Bitcoin-Core reaches its epitome, focusing on a hardened consensus= =20 > 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/bitcoin.= =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 cho= ice=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 break= =20 > 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 Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2= cfc9da32n%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/= 73a08ea3-b9be-424b-a1cb-beac3206723cn%40googlegroups.com. ------=_Part_207083_1012839131.1761936678455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Matt, thanks for your response.

I sea= rched about libbitcoinkernel and it does look like some effort is being put= into the creation of this library.

But again, m= y focus is SPECIFICALLY on the powerful influence of the bitcoin/bitcoin re= po itself. If you don't this merits a BIP, what would be the appropriate av= enue to address and potentially do something about reorganizing the repo it= self?

On Friday, October 31, 2025 at 2:41:30=E2=80=AFPM UTC-4 Matt Corall= o wrote:
You should probably d= ig into the libbitcoinkernel project (and the immense amount of work that h= as gone into it, as well as the immense amount of work that it requires). A= lso this is not anything that would merit a BIP.

=
On Oct 31, 2025, at 14:20,= Juan Aleman <bitco...@juanal= eman.com> wrote:

=EF=BB=BFHello bitcoin developers,


My n= ame 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 hard money= investor, but later also as a developer, specially fascinated by this perm= anent medium. I hope this proposal can be appreciated by all perspectives a= s a pragmatic (maybe unorthodox, but timely) solution to move forward in ag= reement.

The changes in v30 defaults got my attention (similar to ma= ny of you), as they are completely opposite to what has historically been &= quot;standard" practice. A highly controversial change that surfaces t= he 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 unnecessary i= f defaults are simply reverted, while still allowing all policy possibilities.<= br>
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, not techni= cal. It's about the powerful influence the "Official Reference Imp= lementation" centralized node software repository has.

This nee= ds a different kind of solution. I'd like to propose a high-level struc= tural change to the "Official Bitcoin Repository": Separating con= sensus code from policy-based node distribution.

Problem Statemen= t:

The "official" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) maintains consensus code while also defining default relay and mining p= olicies, among all other node functionalities, in a single piece of softwar= e. This concentration of responsibilities leads to elevating this single re= pository to a "pedestal", thus a point of centralization, giving = a few too much influence.

This kind of influence can be considered &= quot;harm" when abrupt default policy changes (like v30's shift to= ward permissive data carrying) disrupt "standard" network practic= es and its users.

However, the v30 release itself may have caused a = point of no return, where "globally agreed standardness" is no lo= nger a realistic expectation. Bitcoin's hidden limits are being reveale= d.

Proposal:

To address humans' flaws, I suggest r= eorganizing the repository structure to better safeguard against unwarrante= d political (policy) influence.

1. Rename and Refocus Core Repo:<= /b>

=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-critical polici= es 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):

=C2=A0 =C2=A0 Creat= e a separate repository for the full-featured node client, starting with (<= a href=3D"http://github.com/)bitcoin/bitcoin-node" target=3D"_blank" rel=3D= "nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&q= =3Dhttp://github.com/)bitcoin/bitcoin-node&source=3Dgmail&ust=3D176= 2022605069000&usg=3DAOvVaw2LU8gQqgvzLgedBl4ko4Lf">github.com/)bitcoin/b= itcoin-node as the foundational template. This would effectively serve = as the direct replacement for the current bitcoin/bitcoin node software. Th= is repository embeds the consensus-focused bitcoin-core (objective), while = including "current core devs"-recommended default policies (subje= ctive). Other clients would use this as their foundation, to customize poli= cy 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 (whe= re beneficial).

For a smooth transition that resolves ongoing tensio= ns, the suggested first release of bitcoin/bitcoin-node should revert to pr= e-v30 defaults. Then, a subsequent release could adopt v30 defaults, with t= he home README clearly documenting options/alternatives (e.g. "For leg= acy Money-First policies, use X").

(But STILL the simplest s= olution 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 represen= ts a more neutral position from the "Official Reference Implementation= " repository in this new era.

Benefits:
  • Bitco= in-Core reaches its epitome, focusing on a hardened consensus core that ser= ves all clients, regardless of policy.
  • Reduction of the "offic= ial" repo's influence on default policy, better aligning with Bitc= oin'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 a= s a benefit, forcing a conscious choice about what node software to run mov= ing 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 ju= st an idea I wanted to share for discussion, and I would appreciate any tho= ughts.

    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+...@googlegro= ups.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 bitcoind= ev+unsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/73a08ea3-b9be-424b-a1cb-beac3206723cn%40googlegroups.com.
    ------=_Part_207083_1012839131.1761936678455-- ------=_Part_207082_10883312.1761936678455--