From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 31 Oct 2025 11:24:43 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEtnm-0000sp-8f for bitcoindev@gnusha.org; Fri, 31 Oct 2025 11:24:43 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3b15f0027d8sf1368031fac.1 for ; Fri, 31 Oct 2025 11:24:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761935076; cv=pass; d=google.com; s=arc-20240605; b=NEsoBX9AKbuaUTsmmAJ40trE8A5V9CxpAhDHspyKE+OftR+iPQYt2YA/niIj519/3v N26bCkamWoWtfUX72dHxj0usAomUY+VP8P8LR2m+WJJgJfkjPbobAlMl3zZenfdjaDGV 4sYb5L0XgVJbnHuggDAt9nQwyG5ZbgpjRzFWHoFmqgC0x6rCCQ1UoRDsieFJH/mu6ze0 vDs3tO7/VT9xI7AxP/T2AOFQmF3EeXOrtUVuEZq/btYDMpw/1nZvG7+E2iCNbvThO+oc 14W8Vlu6K97pGLSHNOjFyJnC9BYZ7ByQB3Px7MyceA1EXBoVltNvbcZASh7R4E9YA0RF NQGQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=aUey1U7duhIDYIZuxfytzNFEfpg4RvwYbgbNvVf+Vs8=; fh=/NhbfXUn4uC7e9LV5Vs2hPw0YzH4V93nrV8zFSAVcdQ=; b=ZYL6z8Wir5DG0a14lqrrdShr00NmmWeRD7XrR+1IXm2JNrfgxLOzr5jfZEK9MUEO4R nWKCfaJLIh3MCId/Kg+Mho6qm1r2WV8fTVyuDaLwv4tU8J1AYjUR1hWhg67kMJ3B07Fc EHaL53UMqouWvktWsUmOck4bA9kLxWsIhCZoWHwnd3GnMpH80051rpq3FiKy2zpBlJtp Af3VvMfW/RQ/BUrz2rdhL4zFV7gmjuWPVmk8wSYjLOo/3DDQbVtECfXH3GNKSipaCMp9 93BKYBsVKbAad4SaK4r4Qa+dLQzvqrOCur1hbP47SmcY/Rw+FKQMDPCNa/ywDlHYislA tCsQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=C4aL93ZZ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761935076; x=1762539876; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=aUey1U7duhIDYIZuxfytzNFEfpg4RvwYbgbNvVf+Vs8=; b=rxmUEfMW4sdLIRRm8O4NAF3NYgNHzmFjV0Z/LH3xtOn5B+lxnyRY9MzXctiTQEQlDO LjRZu+wBHYpFitiiY64uNevZ3Y1fQpXgTah0rmmJA9sCCP+hm9me3xwPurKmi3epGpwb nRU6x1aItM32Z2TiMOpnrbVKb+WxUUsCn0RjCjrN/IZllzv+0VxxV+98G37CIf6HppOA yXMxS6fp8kf7x9ObpvSG2jMV80Kt1liTM6XLiY45oTH5HImInI4+dgtO7CovS1rufULr IqJ0GODQIqpYIL4u8dbR/wxsRqx2782pdLhQjUq9p7UdsTQC/0n+yNNY8Mtp4QO89IYY McmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761935076; x=1762539876; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aUey1U7duhIDYIZuxfytzNFEfpg4RvwYbgbNvVf+Vs8=; b=Fmi8YiWouas052OhamHxDJGTIzSCInIEVx0TCMMjYIhR03dMa1ivbcQ+YRr2hkLVM0 Ln3FidV5zUxmuhaZPOvvdiR9RlL8H1hagIcfTrfyAGZwQ6kYzQ0ygYO4W+YbKWGJpQkw rFSE/08PvGShGhSJCi/Ulsh3V8RyX5vq7F2YQXy19PCTSYaHyxGsS6UoRbdz08z1Ogv1 BiNQo5E9mg5AycYzJpQE4b+9fus3ko1Ga8mrX2+3R9Xkx41ECv8baLpUFU+DBaJiXbA/ pfBiHrg0KohXZ1Vt67XRktXlbh97H3qUE8o4poQb16IT8Bb3uzQewIf7LYtZOC2mIusm 6EJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761935076; x=1762539876; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=aUey1U7duhIDYIZuxfytzNFEfpg4RvwYbgbNvVf+Vs8=; b=AlJGbPDnPVQ7+/UVaHkisj+D7fwWS8eKi3zH4vfTCn+NsMnjvKbKc28aSVbrJA1IMw 2DKHCWqCv05nsJtEMBtRsQnVGQ38zJzqCM2UOmOCIRO0ha3XcXbW45/K3XbZsrI5Km8J F3YoLoc2/2VTdFIvhaH56FHi9BNg/xksd3rrhpAJxOFbJjj/aoPU5mh9SrevgjHCcsWu DtYl/2G5mllpbYvhRNDKr37PdCoNezxqdGczu/Fl4O9xKN6JBm7UxBFVt/JNk1mM2DBB 7RHvkV9jzHFtJo60UTxSBnqMMTWgm0ULEjFa2lXpfh7AHDKyUbmc2qGVe2/lGa3ofyCc jt+Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUYiP2k5fmu11gphQhgSRuENKEPDXg7q7pE/zlE2eCKreJ+/y2jd5ZbTObJ78BeK6jdVy6Cgvarp9WG@gnusha.org X-Gm-Message-State: AOJu0YyKnCd7rWjiN2sp1xwuvf0zbmTRlRILBJk0ar+dqcKj6c51LlQ6 mQjbxThMt/6A7APH/H7pVzBGq1kQrZ5Ey+MQWEbX5IfVuIqlWMmy4Bgu X-Google-Smtp-Source: AGHT+IEncVSf5UUpAyFfw+mQ2rbCYki+wo7PIk2FeqBA1IISMhJtUp5g7sNG25nGDc8IETowKsslVg== X-Received: by 2002:a05:6870:e40c:b0:307:9de2:b3bd with SMTP id 586e51a60fabf-3dacc1c3a5fmr2475867fac.32.1761935075870; Fri, 31 Oct 2025 11:24:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a4R4YH0XHJx4kGURuV12kxGQ/NrHtnJdERFaMAR8TI/w==" Received: by 2002:a05:6870:e194:b0:383:97ca:d48c with SMTP id 586e51a60fabf-3d8b5bb1f81ls886884fac.0.-pod-prod-04-us; Fri, 31 Oct 2025 11:24:30 -0700 (PDT) X-Received: by 2002:a05:6808:c16e:b0:43f:2b18:1608 with SMTP id 5614622812f47-44f95df905amr2119110b6e.2.1761935070473; Fri, 31 Oct 2025 11:24:30 -0700 (PDT) Received: by 2002:a05:690c:8692:20b0:720:768:1935 with SMTP id 00721157ae682-78649aaec6cms7b3; Fri, 31 Oct 2025 11:22:08 -0700 (PDT) X-Received: by 2002:a05:690e:2502:10b0:63e:896:9980 with SMTP id 956f58d0204a3-63f9229e736mr2824140d50.23.1761934928133; Fri, 31 Oct 2025 11:22:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761934928; cv=none; d=google.com; s=arc-20240605; b=W3B3qRp7hbp9upe8YLnUlbbS7ZePdNyhTUEqhsKawq1+46FuG/B+ituV+e1iOaPy5r ikwr+TN/QwcYy8PDXralNr5Bzt1Gfb+mbvFbjWyMRslmpCF7qreHVFkGY1oZkV2BVI/T Hk84XsW/dpYVQlh9f7urKX2jn428GeyaYBHaqHiMESzjxaZnPR0yNs55I+s+0Aqfo8iV yyk6XOKmd0V4+SXYrqaDMQqpHa/9wvXaWH7AgnrRLzAOQpuHOwhea0sY6gKKEcYRPiUR B1DbRzph1NLBm9PC6ChBUunwon8yWubIeMOzUaQiBz2M7vQom/7rUpAriJNHSYJ9VaJj ZcSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=KPshRG6W8GvexN1R/bevQ2BROaBM3YIozAsJcmM9Rfk=; fh=qsYSgMvLzs5DwvTd+GzSXpQvMudW/ZJAccQqJKeMJnY=; b=ASAO1F7iWrdkT2mDnIdhy1sPel+7wQdDHXQ18xLO+XkDo7/T13mPaXQnk0DjS0rgFK zL3QxYCTL7VJw6gHiKTCXGUELLOE2MLDhsU5qityTfOAyMmEJ5UmaaYTPdsgJHMB8sJ7 4xvqCo3Byq1+nzYtzsk53dScAKNoyKMpiisVroSfao5D5LoMSVOvPIbm8dp/8N7Kzkkq ASohLrj7l0Cbo/djhXB6lZBGRQ4MhJcign4BD/u8hhUKnFQhQJk3IvYoLOBNn+O7fiiI rFGVRI1+r8EUplhem8SDdU/O8NR4WOTkxWbIYa7TdmsawYC5CFqfmZZEKIfpmX559V+t e7dw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=C4aL93ZZ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com. [2607:f8b0:4864:20::631]) by gmr-mx.google.com with ESMTPS id 956f58d0204a3-63f96758fa1si178937d50.1.2025.10.31.11.22.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Oct 2025 11:22:08 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) client-ip=2607:f8b0:4864:20::631; Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-29525e6d98bso10885425ad.1 for ; Fri, 31 Oct 2025 11:22:08 -0700 (PDT) X-Gm-Gg: ASbGncueZrFXESdSeHxHRdLInm8ceHogt4/VBvoKE7uEHTg3+7mATOF+HsLxlD37/34 jFnc5HCsrevKFUSJvK3zLlz27w37FNjcE6RIwRsOtiYeAFkxTXVxhNrQatOS+XtJAAoYmriVRix hqrGMj+vOvJrxN7TDtwduHdW/mTLQg+KR4ruJ19NJaN87Ev6/psVVex+8aFXn7qLMo4FjQJ9WkX EpRDm7SRBNtMUicN8U2GmeH2+TIpGVkJ41R9/A84NOD5uT/wn9BBAcGC9JBmgZkULJFTxTk4yHU lf4goL5xlbwgNDYECYrx+tz+UtVt1tBeE4wrP8kYh7n9Ij/bCuU= X-Received: by 2002:a17:902:7482:b0:240:9dd8:219b with SMTP id d9443c01a7336-2951a5c178bmr47412825ad.49.1761934926917; Fri, 31 Oct 2025 11:22:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Maxwell Date: Fri, 31 Oct 2025 18:21:54 +0000 X-Gm-Features: AWmQ_bkUEwQirhTHT2sHwyqrc51tLaCAVJ9ecYOV3ejnRhrB9zps_vSurmq9ev8 Message-ID: Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation To: Juan Aleman Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006fb2e50642787167" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=C4aL93ZZ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000006fb2e50642787167 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Juan Aleman wrote: > Hello bitcoin developers, > > My name is Juan Alem=C3=A1n, and this is my first post to the mailing lis= t. 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 mo= ve > 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 > . > > First, it must be reminded that a fork should be unnecessary if defaults > are simply reverted , > while still allowing all policy 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-political, not technical. It's about t= he > powerful influence the "Official Reference Implementation" centralized no= de > 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 polic= y > 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- existing in parallel, bes= t > 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 > . 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 t= o > 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 cho= ice > 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-aca2= cfc9da32n%40googlegroups.com > > . > --=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/= CAAS2fgTNs%2B04X_pVLx%2BEXUUMk7bzTG2-qGHDTZ5NwxaMDkjp6g%40mail.gmail.com. --0000000000006fb2e50642787167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.

On Fri, Oct 31, 2025 at 6:20= =E2=80=AFPM Juan Aleman <bi= tcoindev@juanaleman.com> wrote:
Hello bitcoin developers,

My name is Juan Ale= m=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 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&q= uot; practice. A highly controversial change that surfaces the influence ov= er default 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 simply reverted, while still allowing all policy possibil= ities.

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 "Offici= al 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 re= pository (= https://github.com/bitcoin/bitcoin) maintains consensus code while also= defining default relay and mining policies, among all other node functiona= lities, in a single piece of software. This concentration of responsibiliti= es leads to elevating this single repository to a "pedestal", thu= s a point of centralization, giving a few too much influence.

This k= ind of influence can be considered "harm" when abrupt default pol= icy changes (like v30's shift toward permissive data carrying) disrupt = "standard" network practices and its users.

However, the v= 30 release itself may have caused a point of no return, where "globall= y agreed standardness" is no longer a realistic expectation. Bitcoin&#= 39;s hidden limits are being revealed.

Proposal:

To ad= dress 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/)bitc= oin/bitcoin to bitcoin/bitcoin-core. This repo would focus mainly on co= nsensus rules, removing arbitrary or non-critical policies from its scope. = It becomes a neutral base for ALL node implementations, emphasizing on hard= ening and testing consensus without policy distractions.

2. Intro= duce Node Client Repo(s):

=C2=A0 =C2=A0 Create a separate reposi= tory for the full-featured node client, starting with (github.com/)bitcoin/bitco= in-node as the foundational template. This would effectively serve as t= he direct replacement for the current bitcoin/bitcoin node software. This r= epository embeds the consensus-focused bitcoin-core (objective), while incl= uding "current core devs"-recommended default policies (subjectiv= e). Other clients would use this as their foundation, to customize policy a= nd beyond. (Also, there is nothing preventing multiple bitcoin-node-<typ= e> existing in parallel, best addressing default-bias concerns.)


The initial implementation of this separation mig= ht not be elegant, but future releases can progressively refactor based on = this new reorganization, potentially incorporating more modularity (where b= eneficial).

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

(But STILL the simplest solut= ion 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 f= ind a compromise where no side feels "forced to comply", and repr= esents a more neutral position from the "Official Reference Implementa= tion" repository in this new era.

Benefits:
  • B= itcoin-Core reaches its epitome, focusing on a hardened consensus core that= serves all clients, regardless of policy.
  • Reduction of the "o= fficial" repo's influence on default policy, better aligning with = Bitcoin's decentralization principles.

Drawbacks:
  • Breaks existing infrastructure tied to github.com/bitcoin/bitcoin. Howev= er, bitcoin/bitcoin-node is a 1-to-1 replacement, mitigating deep disruptio= ns (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 th= at 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegrou= ps.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/bitcoindev/CAAS2fgTNs%2B04X_pVLx%2BEXUUMk7bzTG2-qGHDTZ5NwxaMDkjp6g%= 40mail.gmail.com.
--0000000000006fb2e50642787167--