From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 11:20:13 -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 1vEtjQ-0000my-Ip for bitcoindev@gnusha.org; Fri, 31 Oct 2025 11:20:13 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-654e25cdeeasf871408eaf.1 for ; Fri, 31 Oct 2025 11:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761934806; x=1762539606; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=gW0GsCkuXRJCLDwM16so6ZMXCw6mpUu9QcMvsTloXr0=; b=VAlBSa6Gw/WQaSGPG5zS/Aa+dqq0eSJFSy4nx4PLNojvziFT4axUGaFOZQaYnfd+7F VZ9c9zLroIV1RtqAB9uMWzXaffAvu3l9x9w0UTKrrAarTL5cbrGRVz7IdINrLoPCcWew nnnarw2zSor2IcpTVgdTKxZhP/ejvDGp1uBXmfXzjJ3ufqhKsPnwCykgHOWIy2k/i/6I XQ/CnplWvY53OpHJgB5iiv2CUxawndMrsR6fGs02NhtNJjjKW9wWedgyw75haSvlz254 HruNuWdTgBEyFZPnGyYPnM+5SjsS1kYQGRLMJPRLEAchsYHTzk5tQ42X2lN8yLCkKVYF +t5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1761934806; x=1762539606; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=gW0GsCkuXRJCLDwM16so6ZMXCw6mpUu9QcMvsTloXr0=; b=qi25JJhmsYFby4ighRIMsbPwEaOuth/Ya9u2DpKV+X/fCtE9kCiDeNvKvJg9FItBTM LkMfuZyrej92xyOKdjgogBA5Jkyo/HmEeqoBSeqnloJecLG2d1WV9eWx6dWksjop6luM vpe4bGvXNm+UiPtUnquYLAv/dnwXKuWfT3hrTW/PG0i4jbGPN7OYnhy2b9D0FGtdvwWu vibjZOWBaNmDRpuK2KgcI+nbOSkHzszlYxkqMGiDptXjDjaXvyeoZ9zXmFFezzCZEXVS z95yk+Fjo5uMRstrEPN4o6oFCaTp7YNH+CWF0zQiaMGlhVANk5IinJiHppbwFkD2Qkyv hfOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761934806; x=1762539606; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=gW0GsCkuXRJCLDwM16so6ZMXCw6mpUu9QcMvsTloXr0=; b=H10gOe3YEnrz26Yd+8MRLfS9Ai3MsgTO91Bts+i6DIW6vL5rcHGwz9p75Gwu1jg9BG 0lVdAV4ZYR1i4PBBwHngo4ha7nXyzFGa1XE9M0zU3aBCUVuGZoj3gGY24zRFmy68n4p8 zqEPVmd9iNetZJd7RKIVxfSGSNUVX/RsQ+lS8uXZ0ucMoXX82k3w78tmku+7G33Or0f6 IIm3b7AYSPXl+c56+YJwm+CLvVGvbgMrjJnJiV4qT1b2bZVnHYS6NQ3ydLWrdZTd63Sw xNdHmBzU3ZV2KpPS1EQJOE6Ixf4pHbS1SzMJ9cYCvmZ73oTGwsn9QDPQcPmYPP6MkaF/ UTlw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCU2MVX7yh9VXIoAGelqQNY9G5Dt4rDd7e6kh+jAwph8bRCeIxXiZhEyvWz6HZFIMKl/NwaTLcyoEfoq@gnusha.org X-Gm-Message-State: AOJu0YzebUR66rtEBCDUfHJAwl1MQitjIK7IsOy16mxyL+Dae+ZzdRJ/ 5mQLeuhCS12BLphG+IVJGFXM2RcKZe+H6tgkNKRgBcjTxFCGcO0sqhfA X-Google-Smtp-Source: AGHT+IEgDX5XryJ7ENnHIhuazf92OMyRoKDssnlSI5vBKtGfYHieErLN043z9jeWzRo260OOF2ot4w== X-Received: by 2002:a05:6870:e996:b0:3d3:5abf:e09e with SMTP id 586e51a60fabf-3daccbed5aamr2301206fac.44.1761934806118; Fri, 31 Oct 2025 11:20:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a9sqFJh4h92JZZPHFFs9iJGw4tXbCg5dLb4OSFfBekHg==" Received: by 2002:a05:6871:54d:b0:3d1:fb8f:5574 with SMTP id 586e51a60fabf-3d8bbbf6786ls1023381fac.2.-pod-prod-02-us; Fri, 31 Oct 2025 11:20:00 -0700 (PDT) X-Received: by 2002:a05:6808:3510:b0:43f:9c1d:ae93 with SMTP id 5614622812f47-44f95e6ea87mr2068327b6e.6.1761934800715; Fri, 31 Oct 2025 11:20:00 -0700 (PDT) Received: by 2002:a05:690c:dc1:b0:785:e55d:2dfd with SMTP id 00721157ae682-78649982b58ms7b3; Fri, 31 Oct 2025 10:54:44 -0700 (PDT) X-Received: by 2002:a05:690e:124d:b0:63f:a0ac:67bd with SMTP id 956f58d0204a3-63fa0ac6892mr278533d50.60.1761933283792; Fri, 31 Oct 2025 10:54:43 -0700 (PDT) Date: Fri, 31 Oct 2025 10:54:43 -0700 (PDT) From: Juan Aleman To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_233242_537590540.1761933283460" 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_233242_537590540.1761933283460 Content-Type: multipart/alternative; boundary="----=_Part_233243_515452189.1761933283460" ------=_Part_233243_515452189.1761933283460 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello bitcoin developers, My name is Juan Alem=C3=A1n, and this is my first post to the mailing list.= 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 move= =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 , while= =20 still allowing all policy possibilities. After my second PR attempt= =20 was (also) closed (and I was blocked from the repo), I realized that the=20 main issue here is social-political, not technical. It's about the powerful= =20 influence the "Official Reference Implementation" centralized node software= =20 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 policy= =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, where= =20 "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 repo= =20 would focus mainly on consensus rules, removing arbitrary or non-critical= =20 policies from its scope. It becomes a neutral base for ALL node=20 implementations, emphasizing on hardening and testing consensus without=20 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, best= =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 first= =20 release of bitcoin/bitcoin-node should revert to pre-v30 defaults. Then, a= =20 subsequent release could adopt v30 defaults, with the home README clearly= =20 documenting options/alternatives (e.g. "For legacy Money-First policies,=20 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 to= =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, better= =20 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 choic= e=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 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/= d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com. ------=_Part_233243_515452189.1761933283460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 s= ince 2017. First only as a hard money investor, but later also as a develop= er, specially fascinated by this permanent medium. I hope this proposal can= be appreciated by all perspectives as a pragmatic (maybe unorthodox, but t= imely) 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 contr= oversial change that surfaces the influence over default policy in the netw= ork, escalating to the point of a fork proposal.

First, it must be reminded that = a fork should be unnecessary if defaults are simply reverted, while still allowing all p= olicy possibilities.

After my second PR attempt was (also) closed (and I was = blocked from the repo), I realized that the main issue here is social-polit= ical, not technical. It's about the powerful influence the "Official Refere= nce Implementation" centralized node software repository has.

Th= is needs a different kind of solution. I'd like to propose a high-level str= uctural change to the "Official Bitcoin Repository": Separating consensus c= ode from policy-based node distribution.

Problem Statement:

The "official" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) main= tains 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 inf= luence.

This kind of influence can be considered "harm" when abr= upt default policy changes (like v30's shift toward permissive data carryin= g) disrupt "standard" network practices and its users.

However, = the v30 release itself may have caused a point of no return, where "globall= y agreed standardness" is no longer a realistic expectation. Bitcoin's hidd= en limits are being revealed.

Proposal:

To add= ress humans' flaws, I suggest reorganizing the repository structure to bett= er safeguard against unwarranted political (policy) influence.

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

=C2=A0 =C2=A0 Rename (git= hub.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This repo would focus mai= nly on consensus rules, removing arbitrary or non-critical policies from it= s scope. It becomes a neutral base for ALL node implementations, emphasizin= g on hardening and testing consensus without policy distractions.

2. Introduce Node Client Repo(s):

=C2=A0 =C2=A0 Create = a separate repository for the full-featured node client, starting with (git= hub.com/)bitcoin/bitcoin-node as the foundational template. This would effe= ctively serve as the direct replacement for the current bitcoin/bitcoin nod= e software. This repository embeds the consensus-focused bitcoin-core (obje= ctive), while including "current core devs"-recommended default policies (s= ubjective). 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 refa= ctor based on this new reorganization, potentially incorporating more modul= arity (where beneficial).

For a smooth transition that resolves = ongoing tensions, the suggested first release of bitcoin/bitcoin-node shoul= d revert to pre-v30 defaults. Then, a subsequent release could adopt v30 de= faults, with the home README clearly documenting options/alternatives (e.g.= "For legacy Money-First policies, use X").

(But STILL the si= mplest 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 ne= utral position from the "Official Reference Implementation" repository in t= his 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 princip= les.

Drawbacks:
  • Breaks existing infrastr= ucture 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 movin= g forward).
  • Also, there must be caution of not using the original g= ithub.com/bitcoin/bitcoin name for anything else, as that would break autom= atic 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com.
------=_Part_233243_515452189.1761933283460-- ------=_Part_233242_537590540.1761933283460--