From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 01 Nov 2025 11:03:08 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.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 1vFFwQ-0000jN-P4 for bitcoindev@gnusha.org; Sat, 01 Nov 2025 11:03:08 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-651c94351e5sf5309588eaf.1 for ; Sat, 01 Nov 2025 11:03:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1762020181; cv=pass; d=google.com; s=arc-20240605; b=Z0RbCdYhaJEh17TpPP5nsMFo+UtGCPJlEx+h84NqyHIZOhtfBHtGti2zfNsbo1KBwF xGkfz2xFnlOeGFB5sxE/pqx/yRjILs3UrtY6zmWH8Brw24cASZw/jsB9S2t/VCNPTApe aLHIdtJ1lt/7dfUUOaz+7yWHaNbE0U0am0UvnprdTz+azFfRvY4WI6bbDmgeAcv/Of/h fbzq8i4TrHZFhvNOGuJWCYtTJyRaQ3/sz24rppGIZJfhKxzoRocTZDbzjTstlOABZyeQ ESocXS3+QLzggiZ52WIh9U1mCrpAgCRopv0HyjYPKFZ+Y2we9hk0NWEitfdQ5QRyDXu7 gp/A== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=1DdxfWQMubYblefBE/o/9NXR9h+Emp6D2L5Ef5iiwcI=; fh=wlt/WhuK5pUvwo0YrbborRS5ZPLuOZl0OeCosR3NxfM=; b=gZ3KS4xZRcsslHfg0w0sH3l/FJydMBF4pRJfasStAT179/GrD02FD2XEp47Z6EA8CL JC7ebAaVXDQ6nCI8m1nZGASlVQZB1aiJod59yW5YOtcQsx8ExiW+ocrT/stzLfETDSb0 7PZ+PCTJVgIExWKFsoeCgykW4jj0eN0HV7A/FvjIWnQ4HbZiYtxBv+sdlb6O/3QjEhvP taZ/IRtyJH2EB5CogUSlZgPe77lNemd2nYGtuX0dxT927fG8+GiK9LgXJsWf6tuY+Qqb MMUzbNlw0h64yxqwwYw/AuE80ZL91zPQ4P/JIsCU8v7YE45kW5jJY8AAQo9Kx7GcJD5K WQJA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=liYbTlle; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762020181; x=1762624981; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=1DdxfWQMubYblefBE/o/9NXR9h+Emp6D2L5Ef5iiwcI=; b=SOItAo0nq65uMMeh0cUMCi9+RWcjJhqh/zW3UuUDUR9pe5CUIFOPz1u2ea+cazCcH9 vnmvEM/AqQs3CCUygwz+WA1PSIdnL30a2iO8p6+RgxyG6t135QSnIoBA7hzn8aUTU4x1 m5wCrqmYp/OkSzHlaOQ47l0ADsMX6ZkF38PxFbor7PMlka6d4ZdCt+Te6oei+7f+AYdX ujZoJdLzT6ozDhdQhiZ7kxqaE9DRvLx8MyKfpKBQDTGu9Q+cGeC++rjjr1CC+vTrMYqc YVC5bZbe8UqePS9T0R8YvRd03sNlGKnSTscDO8vwbAwZN8oPdH+jVnE8o4XpMyQNyt56 3c8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762020181; x=1762624981; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1DdxfWQMubYblefBE/o/9NXR9h+Emp6D2L5Ef5iiwcI=; b=VB2o+WViqIRGMzQvfmSbwQtbg8lHzvqrfIEzNn2F3wckr7nMMwGW27goHRUk0FNCMF 30xytknPGqdy5iJfANaaNIyOn2UEwekr15a9VeZie0yeM89bOtqo/Ei0gxhXBVMv7xrJ oLOyGBVQclDrZTAgfXY+LIUHMnPfl8557v6A11Dr4vqw3GFwgDOyq81FB1xJ5x9x57lw iXiVzN0X4HlfTHXPFgY1SjYFvpQSu0wx7XWe3j9P5OHgsANu5/HPD+Mo9WmszzXkmQ75 BgPq56n3i67qmsiMQ3VJf5jSVv5mfisqhnqDPoHjxtAj9Mjz0hnnWRXW9oXDtHnIdW9/ y7pA== X-Forwarded-Encrypted: i=2; AJvYcCWHgHqRKY0qzlL79pliNj1oFFbWQDdZ9NbMdc36TttuwDJIvy6keVEwhJO0TcsdcCicxLB3+G+qn2q3@gnusha.org X-Gm-Message-State: AOJu0Yy74//e5b6D8nW81ec8K/ieseWivHXwvvmNXdxwv3GIc4D4267R 8p3we0cmFoW4u1KLrQ7ED67fa54VHnVoPUDYvzb95AYOoDuppwKKPeot X-Google-Smtp-Source: AGHT+IEEprSxorckkeCOveX1fc0lHgn5rgmxBWyFfI9OJCf5geEgm73KXA39xmdckPZGXk2D9p5tDw== X-Received: by 2002:a4a:ee1a:0:b0:654:f77a:1a5c with SMTP id 006d021491bc7-6568a6c864emr3426148eaf.3.1762020180630; Sat, 01 Nov 2025 11:03:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YVIYXCeBt1p3JG4qdJpIvixFSRh6NSCAJo8dk9lzN5pQ==" Received: by 2002:a4a:a746:0:b0:656:77c7:8eb7 with SMTP id 006d021491bc7-656824972ebls1794057eaf.1.-pod-prod-01-us; Sat, 01 Nov 2025 11:02:56 -0700 (PDT) X-Received: by 2002:a05:6808:16a0:b0:43b:6639:7307 with SMTP id 5614622812f47-44f95e93b44mr3147636b6e.23.1762020176035; Sat, 01 Nov 2025 11:02:56 -0700 (PDT) Received: by 2002:a05:600c:20e:b0:471:cf5:89b with SMTP id 5b1f17b1804b1-4773244e105ms5e9; Sat, 1 Nov 2025 10:54:09 -0700 (PDT) X-Received: by 2002:a05:6000:18a3:b0:428:3cd7:a340 with SMTP id ffacd0b85a97d-429bd69914fmr6398097f8f.35.1762019647077; Sat, 01 Nov 2025 10:54:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1762019647; cv=none; d=google.com; s=arc-20240605; b=Sgl2In2eV9IHP2btsSmU1A5glv5aOIZGNjGTtqzwF1Wz9Ew10Sx53RP7jKPFWeOpsK qru1seHt/ZoA1d3hVi6bm7214UbjtbVrzChzRDmH/8rPNExkKpFITz9ANvHF8Souhsj3 bOTtQpBIWoktu7L/Mp4EUA0z7FCrMj1eMIZ/iGMwFn7tIR4Wd4vl4Vj+BXAt3ARM1PE/ yi+two6Hnd9/bkAuBo8kaCcb1A4jRNpd5mt/8KnuEY0wBj4Ff9P3c+4L5ZxnvwKvmPfC 9roMeW6u/pFsuDwqacTODPIUDtakjmBu3ZScErn3YX8B3bPniffYF6Mp1Wdik55Ym6qU h36A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=Ytk5Tpz4RWuhNe01NOHcvnw8jRL4J1IDVM29f0Y7nYc=; fh=qsYSgMvLzs5DwvTd+GzSXpQvMudW/ZJAccQqJKeMJnY=; b=ZUn0Wrv2Mrot3wTPW+NOWUtnzRMTWto0gxc6KcYMjcP9Lx0zlR0sj1+Jh8IVGIqAlH zHCYi7LFkRry60ZYeqFDM8up9ZVLepENQac1bCWog3AWJU+iav7EjquRrgaZqcFeYsFw wRBhDKKiDzSHM4TitDFO39cAmspriVT+so9KZc4BmSdNWn6qq7HXcUCnhHgM2+P2LakF v+LK894ii+xPsnd6oIZDKUYH8Yrh2dpEcPpg4RFDciHdmj/HihrnnhGV3Bxj6xM38chQ UpBOxlwq8+zNm0qvdFx+4lDsu8TjqGibGk0E8bRH3YkR5ftisSR4AXterfmDynLl6RiI AFCA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=liYbTlle; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-429c94184c0si35744f8f.3.2025.11.01.10.54.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Nov 2025 10:54:07 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28; Date: Sat, 01 Nov 2025 17:54:01 +0000 To: Juan Aleman From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation Message-ID: In-Reply-To: References: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: c42ba032890673a9444e6fce72bbe3298d72bd54 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_DyIUh4FtDDGMq9JAOouwYkvHgIjmsgnDSwfeiBwFjBA" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=liYbTlle; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) --b1=_DyIUh4FtDDGMq9JAOouwYkvHgIjmsgnDSwfeiBwFjBA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juan, Bitcoin Core only sets default for those users who choose to run it. You may disagree with Bitcoin Core users' choice of software, but your fail= ure to persuade them to run something else does not entitle you to force au= thors of the software they run to make undesirable changes by fantasizing a= bout their public workplace. You know who ultimately controls the bitcoin/bitcoin repo? Microsoft. Bitco= in would be completely uninteresting if this had any bearing on the definit= ion of the system. The bitcoin-dev mailing list is an appropriate venue to share your work on = an alternative approach to developing a Bitcoin client. It is not one for s= pamming all subscribers to this list with a demagogic attempt at redefining= the voluntary nature of Bitcoin. Antoine Poinsot On Saturday, November 1st, 2025 at 12:58 PM, Juan Aleman wrote: > Hello Antoine, > > Nice to meet you. The main issue here is with the bitcoin/bitcoin repo it= self. A single authority with too much influence, now escalating to the poi= nt 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 qu= ite uncomfortable to be in deep conflicts with peers, and even friends. But= "CoreDevs" seem way too invested to remain unbiased, clearly missing the f= orest for the trees. > > Glad to learn that bitcoin/bitcoin-core already has some headway, seems l= ike libbitcoinkernel could eventually be integral in this new consensus-foc= used repo I'm proposing bitcoin/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 bit= coin/bitcoin (heading into using the NEW core, eventually) > - bitcoin/bitcoin is renamed to bitcoin/bitcoin-core, and can start fat-t= rimming (heading into libbitcoinkernel integration, apparently) > > Or we can just [revert](https://github.com/bitcoin/bitcoin/pull/33682) de= faults. > > Let's be adults. Do you really want to continue fighting? There's this th= ing called the golden rule, and Core broke it. Accept it, let's fix what we= can, and move on. > > I anticipate this whole situation 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 b= y default, is undeniably abusive and risky. Which we are experiencing the c= onsequences of... Let's stop the escalation! > > On Friday, October 31, 2025 at 8:09:25=E2=80=AFPM UTC-4 Antoine Riard wro= te: > >> Hi Juan, >> >> Confirming you that libbitcoinkernel is mature enough to hack on it. >> >> Completely split out the mempool from the validation engine on bitcoinba= ckbone.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= that. >> >> Define "power" seriously, I read almost the integrality of Michel Foucau= lt, 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=A9cri= t : >> >>> Greg I actually agree there should be no "official" anything. That is w= hy I purposefully always use "quotes" around it. >>> >>> Unfortunately for both of us, this is not a reflection of reality. "Off= icial Bitcoin Core" has become itself the power grab. >>> >>> My proposal is about bringing this to the forefront. Most discussions I= see revolve around who can win an argument. All these are distractions 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 wr= ote: >>> >>>> Other people don't do what you want because they believe it would harm= Bitcoin and they have no interest in spending their efforts trying to harm= something they love just to satisfy other people who disagree with them. M= aybe they are wrong, but fortunately you have the freedom to go your own wa= y. There is no 'official' anything. Continuing to try to coerce others to d= o what you want when they think it would be wrong and harmful is a bad choi= ce which will make enemies 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 wrote: >>>> >>>>> Hello Greg, thanks for your feedback. I am already starting to do [so= mething](https://github.com/jotapea/bitcoin/commit/97d61c4b8eb0c044b06e1a8d= 5f280b17a6d7b5aa), but the main point IS about the centralization risks of = the "official" repo... >>>>> >>>>> On Friday, October 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell = wrote: >>>>> >>>>>> 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 maili= ng list. But I've been involved with Bitcoin since 2017. First only as a ha= rd money investor, but later also as a developer, specially fascinated by t= his permanent medium. I hope this proposal can be appreciated by all perspe= ctives as a pragmatic (maybe unorthodox, but timely) solution to move forwa= rd in agreement. >>>>>>> >>>>>>> The changes in v30 defaults got my attention (similar to many of yo= u), 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]= (https://github.com/bitcoin/bips/pull/2017). >>>>>>> >>>>>>> First, it must be reminded that a fork should be unnecessary if def= aults are simply [reverted](https://github.com/bitcoin/bitcoin/pull/33682),= while still allowing all policy possibilities. >>>>>>> >>>>>>> After my second [PR](https://github.com/bitcoin/bitcoin/pull/33690)= attempt was (also) closed (and I was blocked from the repo), I realized th= at the main issue here is social-political, not technical. It's about the p= owerful influence the "Official 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 c= onsensus code from policy-based node distribution. >>>>>>> >>>>>>> Problem Statement: >>>>>>> >>>>>>> The "official" Bitcoin Core node repository (https://github.com/bit= coin/bitcoin) maintains consensus code while also defining default relay an= d 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= policy 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 retur= n, where "globally agreed standardness" is no longer a realistic expectatio= n. Bitcoin's hidden limits are being revealed. >>>>>>> >>>>>>> Proposal: >>>>>>> >>>>>>> To address humans' flaws, I suggest reorganizing the repository str= ucture to better safeguard against unwarranted political (policy) influence= . >>>>>>> >>>>>>> 1. Rename and Refocus Core Repo: >>>>>>> >>>>>>> Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This r= epo would focus mainly on consensus rules, removing arbitrary or non-critic= al policies from its scope. It becomes a neutral base for ALL node implemen= tations, emphasizing on hardening and testing consensus without policy dist= ractions. >>>>>>> >>>>>>> 2. Introduce Node Client Repo(s): >>>>>>> >>>>>>> Create a separate repository for the full-featured node client, sta= rting with (github.com/)bitcoin/bitcoin-node as the foundational template. = This would effectively serve as the direct replacement for the current bitc= oin/bitcoin node software. This repository embeds the consensus-focused bit= coin-core (objective), while including "current core devs"-recommended defa= ult policies (subjective). Other clients would use this as their foundation= , to customize policy and beyond. (Also, there is nothing preventing multip= le bitcoin-node- existing in parallel, best addressing default-bias c= oncerns.) >>>>>>> >>>>>>> The initial implementation of this separation might not be elegant,= but future releases can progressively refactor based on this new reorganiz= ation, potentially incorporating more modularity (where beneficial). >>>>>>> >>>>>>> For a smooth transition that resolves ongoing tensions, the suggest= ed 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 poli= cies, use X"). >>>>>>> >>>>>>> (But STILL the simplest solution is just to allow something like [t= his](https://github.com/bitcoin/bitcoin/pull/33682). 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 "fo= rced to 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 consensu= s core that serves all clients, regardless of policy. >>>>>>> - Reduction of the "official" repo's influence on default policy, b= etter 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 di= sruptions (which some will see as a benefit, forcing a conscious choice abo= ut 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 GitHu= b 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, s= end an email to bitcoindev+...@googlegroups.com. >>>>>>> To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/d397e2e1-3d5b-473a-b915-aca2cfc9da32n%40googlegroups.com. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. >>>> >>>>> To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com. > > -- > 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/bitcoinde= v/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%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/= fofKj6a1afiS_xE53RaeN6ipreL9rkpHda8IV2ihSIJKP2Y4vn3nyjYB0ogyq9H0AOJbkSc9AHl= OlcQHMBdCOXOc5d3Qd62836mtWW0w8cc%3D%40protonmail.com. --b1=_DyIUh4FtDDGMq9JAOouwYkvHgIjmsgnDSwfeiBwFjBA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Juan,=

Bitcoin Core only sets default for those users w= ho choose to run it.

You may disagree with Bitcoin Core users' choice of software, but your=20 failure to persuade them to run something else does not entitle you to=20 force authors of the software they run to make undesirable changes by=20 fantasizing about their public workplace.

You know who ultimately controls the bitcoin/bitcoin repo? Microsoft.=20 Bitcoin would be completely uninteresting if this had any bearing on the definition of the system.

The bitcoin-dev mailing list is an=20 appropriate venue to share your work on an alternative approach to=20 developing a Bitcoin client. It is not one for spamming all subscribers=20 to this list with a demagogic attempt at redefining the voluntary nature of Bitcoin.

Antoine Poinsot
=20
=20
=20

<= div class=3D"protonmail_quote"> On Saturday, November 1st, 2025 at 12:58 PM, Juan Aleman <bitcoi= ndev@juanaleman.com> wrote:
Hello Antoine,

Nice to meet you. The main issue here is = with the bitcoin/bitcoin repo itself. A single authority with too much infl= uence, now escalating to the point of a fork over defaults.

The powe= r 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 bitcoin/= bitcoin-core already has some headway, seems like libbitcoinkernel could ev= entually be integral in this new consensus-focused repo I'm proposing bitco= in/bitcoin be repurposed to. But for a v1, we can K.I.S.S.:
  • bitc= oin/bitcoin-node continues as an exact duplicate of the current bitcoin/bit= coin (heading into using the NEW core, eventually)
  • bitcoin/bitcoin = is renamed to bitcoin/bitcoin-core, and can start fat-trimming (heading int= o libbitcoinkernel integration, apparently)

Or we can just revert defaults.

Let's be adu= lts. Do you really want to continue fighting? 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 situation has been very educational for= many, and it is actually GOOD to have the option to use multiple OP_RETURN= s instead of burn outputs. But a 1000x increase of non-transactional arbitr= ary data by default, is undeniably abusive and risky. Which we are experien= cing the 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 tha= t libbitcoinkernel is mature enough to hack on it.

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

```
block-daemon: cargo build --bin block_relayd
cp target/debug/block_re= layd block_relayd

addr-daemon:
cargo build --bin addr_rel= ayd
cp target/debug/addr_relayd addr_relayd

tx-daemon: cargo build --bin tx_relayd
cp target/debug/tx_relayd t= x_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 b= ackbone-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 that.

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

Best,
Antoine
OTS has= h: 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" anyth= ing. That is why I purposefully always use "quotes" around it.
Unfortunately for both of us, this is not a reflection of real= ity. "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 ma= ny 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 spending t= heir efforts trying to harm something they love just to satisfy other peopl= e who disagree with them. Maybe they are wrong, but fortunately you have t= he freedom to go your own way. There is no 'official' anything. Continuin= g to try to coerce others to do what you want when they think it would be w= rong and harmful is a bad choice which will make enemies out of people who = otherwise would be indifferent to your efforts that they regard as misguide= d.


On Fri, Oct 31, 202= 5 at 6:41=E2=80=AFPM Juan Aleman <bitco...@juanalema= n.com> wrote:
Hello Greg, thanks for your feedback.= I am already starting to do something, but the main point I= S about the centralization risks of the "official" repo...

On Friday, October= 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell wrote:
If you want= that and think it would be valuable, feel free to create it. No one will s= top you and you don't need anyone's permission.

On Fri, Oct 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 fir= st 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, speci= ally fascinated by this permanent medium. I hope this proposal can be appre= ciated by all perspectives as a pragmatic (maybe unorthodox, but timely) so= lution 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 chan= ge that surfaces the influence over default policy in the network, escalati= ng to the point of a fork proposal.

First, it must be remind= ed that a fork should be unnecessary if defaults are simply rev= erted, while still allowing all policy possibilities.

After my s= econd PR attempt was (also) closed (and I was blocked from = the repo), I realized that the main issue here is social-political, not tec= hnical. It's about the powerful influence the "Official Reference Implement= ation" centralized node software repository has.

This needs a differ= ent kind of solution. I'd like to propose a high-level structural change to= the "Official Bitcoin Repository": Separating consensus code from policy-b= ased node distribution.

Problem Statement:

The "offici= al" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) maintains c= onsensus code while also defining default relay and mining policies, among = all other node functionalities, in a single piece of software. This concent= ration 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= policy 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 standa= rdness" is no longer a realistic expectation. Bitcoin's hidden limits are b= eing revealed.

Proposal:

To address humans' flaws, I s= uggest reorganizing the repository structure to better safeguard against un= warranted political (policy) influence.

1. Rename and Refocus Cor= e Repo:

Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-cor= e. This repo would focus mainly on consensus rules, removing arbitrary or n= on-critical policies from its scope. It becomes a neutral base for ALL node= implementations, emphasizing on hardening and testing consensus without po= licy 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. T= his would effectively serve as the direct replacement for the current bitco= in/bitcoin node software. This repository embeds the consensus-focused bitc= oin-core (objective), while including "current core devs"-recommended defau= lt policies (subjective). Other clients would use this as their foundation,= to customize policy and beyond. (Also, there is nothing preventing multipl= e bitcoin-node-<type> existing in parallel, best addressing default-b= ias concerns.)


The initial implementation = of this separation might not be elegant, but future releases can progressiv= ely refactor based on this new reorganization, potentially incorporating mo= re modularity (where beneficial).

For a smooth transition that resol= ves ongoing tensions, the suggested first release of bitcoin/bitcoin-node s= hould revert to pre-v30 defaults. Then, a subsequent release could adopt v3= 0 defaults, 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 pr= oposal attempts to find a compromise where no side feels "forced to comply"= , and represents a more neutral position from the "Official Reference Imple= mentation" 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 "offici= al" repo's influence on default policy, better aligning with Bitcoin's dece= ntralization principles.

Drawbacks:
  • Breaks e= xisting 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 choice about what node software to r= un moving forward).
  • Also, there must be caution of not using the or= iginal githu= b.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 "= 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-aca2cfc9da32n%40googlegroups.com.

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3a74n%40googlegroups.com.

--
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= .

--
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/= fofKj6a1afiS_xE53RaeN6ipreL9rkpHda8IV2ihSIJKP2Y4vn3nyjYB0ogyq9H0AOJbkSc9AHl= OlcQHMBdCOXOc5d3Qd62836mtWW0w8cc%3D%40protonmail.com.
--b1=_DyIUh4FtDDGMq9JAOouwYkvHgIjmsgnDSwfeiBwFjBA--