From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 02 Nov 2025 12:12:03 -0800 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vFeQj-0002QM-Sd for bitcoindev@gnusha.org; Sun, 02 Nov 2025 12:12:03 -0800 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7c52e11ee79sf1460036a34.0 for ; Sun, 02 Nov 2025 12:12:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762114316; cv=pass; d=google.com; s=arc-20240605; b=BSnhKKq8+rMHZZrwQvfNpxT8wTtBpz5Mb/lxqhuUy1EUnxTJic6IPZP39O8MqjBR9y +R73FMFbrozwVhaSTCG2khIcOSOrMdxsWOh7lA/WONG6cRTsct1JF6lfsRk701yhJTxi Fh8wJmu0gArBmLK8Y29sgw7AvrM3uuYJH2M/sMq+g5aLT36m0KqH0l8rS9Cjs+39gai/ TrRGT37KGeR12MHngQ8qvmzDPuuXiSSE75Vu8anwxgoigsjGOW3cyhdFIMMXfTzLaDp8 vFZhxIzs4gDgNzvU3HSZJbwuRqz7GzXSQhUaHmm5yVffJUL0x3tF+ZAhcCefo84vYmdJ NkwA== 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=h8+XCXXo3ocCf3dBf/EXNMH9sHzd+Mtgze7F4eZLL7Y=; fh=UkYkxpE6rtvNxTyp38Ol0J3NzXfyAVfEtlpWONglSV8=; b=aG3C6B0t21pmKgBobOfPhlFb46plERsWMcwQGW1rnvXkeJ+Shg7WDO/r2t12ucbnLH tnCP0Pnf3USLUqD1XASue4CD3aRP+SD+Nqte+Ql+UAnp3z/LlD+b4a3yAhIWc2jRYtVE 0JiGtrWznqx8Y9LDFczefO+Ka0793e0TBC4z4zQPb4IAAdZtZd2U8Gx+E/K8WvyhigUP h+RnJ9zReEbcZ+18ghZVJ8UFiEcDHm4gyhUy9GSk1+wvv1uyTzvDruBzG3+wx5/somXA IsTYnzfmkv8uIpDXTOD80A4+EcZz8wO1jMC0R0z3Tk3iMPZjY891Qi2evQdnKMwzxsd8 23Zg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=SvOD1X7F; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=antoine.riard@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=1762114316; x=1762719116; 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=h8+XCXXo3ocCf3dBf/EXNMH9sHzd+Mtgze7F4eZLL7Y=; b=eDaJI1MTFKEKQB2YF946oxW5mkRpock3cof2RbyMA1SV6WxnGqBRgpQ2Fbmk0EKg3b m5AyUDk09cjEkATmltsRjEcDKVHlGb99b4cQFTB/u7lbE4RqOvtv51DlHL2E9HOWpAX7 Idr5QmyrIiTWJLAZZTOzXWgvfP7ETU3ea0wnFN+2dzh/B/Fn0tE7vf6SkLcbvVH4hYol qgeXUG0z2uDM0Yf8qVjVUwFxmCjd42xcDNoT0RFtv46eJCZcWg95KoG/VR51mMmsjHxb +Hns+bidmoE0Z67/W6P+ZjUjn3tEP97kLntYfhpyGuSYN2350McqT1s+9YGrDLpbEVEd 6IaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762114316; x=1762719116; 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=h8+XCXXo3ocCf3dBf/EXNMH9sHzd+Mtgze7F4eZLL7Y=; b=cLo7l4GAIs+p5Qbod9dvRazPcLOSFXLqqzXQhvqvYA6JUuXnh0ZmDs3fox3+uV1K8U nF7B3ElRgi1m0Bo6A6Fw+z3K4FcN0CPLUYiYWi9ZTpZdiTSg8h5u7YFXYnlFXqMT7GUY BT12j0l2GIaOe26Mndoe1yZqXg5rhfYxp1w6g9spMHme+F3aMmnhSBafOIBlPILGKsJo JUd5LzyqgP0Q8VB+QQTbwJnM1L4uhY9oktYdygZZFXft6PIxa6pUuRCPBE5h2patd35d Q70nsd7nFcLBAp0Iv0XiGP1nG+fjFs5hertz0bhbgYkgBtWAE3dvZkpHGylhpR/127Vg X65A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762114316; x=1762719116; 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=h8+XCXXo3ocCf3dBf/EXNMH9sHzd+Mtgze7F4eZLL7Y=; b=guYCg36mqWd5J+T16Yrh6s+OUrhOon7X+jNI9lOUVGYYUUyfeQJBdHYzyz5bqCpegk lcVA1Dd4elV6IT0BqICIDx+7SeiaFJJyrzuIp1gK7AM7/J7xx7Fjy03zuFKtGAJlEpy2 RKCUrj9S2IVP4z2ts0W6TeLMoOOMjirUmAx6eggJIS4fzH64CrJrx/VFee0yk6DeQ72w l6CWREbbOKcHTyEaXqQrdIif32/39JHCc4+aPCzCNjFN6ezCRFvnER8L9U4o16e9crWR ubgaSsxc15ZHVchNxHWP6+GZn/tG0xonaFVpMp7y9GYpzfL48jGlb6UR3SADsIkbL59U B7jA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWgWt/Xy2lKW3viHxPUC2QQPPTATH584EVNmjz+e/UnAnW9RBvjG/OWU27z/cpcvaIoIrSJEOuzEN57@gnusha.org X-Gm-Message-State: AOJu0YxU2PYKmtnQMDcaVMYhiajaf/XxAAAZIIRz3HPYpEA3puuwS8Iw x1mXBfi+q41qb8RdSDYj7SaE6O0UvsXw+CCuW9+j1vsHfgFphY50YOj0 X-Google-Smtp-Source: AGHT+IF1QWrHn5mTMhsAK5aBFT4GwcaDor76ed2FoYM3z53YNUCUnmwG7mlsMM2nX0hD7jv8W05dcw== X-Received: by 2002:a05:6870:96a8:b0:3d2:9cea:797b with SMTP id 586e51a60fabf-3dacccf3bc9mr2858328fac.7.1762114315515; Sun, 02 Nov 2025 12:11:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YUyNl3fe7Zc+RPJO4WqahKamOyVE9OWz1Nj4d3VxZCNw==" Received: by 2002:a05:6871:3488:b0:374:de90:136b with SMTP id 586e51a60fabf-3d73c10c518ls754156fac.2.-pod-prod-00-us-canary; Sun, 02 Nov 2025 12:11:50 -0800 (PST) X-Received: by 2002:a05:6808:4444:b0:441:8f74:efe with SMTP id 5614622812f47-44f9539d19emr4734845b6e.27.1762114310588; Sun, 02 Nov 2025 12:11:50 -0800 (PST) Received: by 2002:a05:620a:a91b:b0:892:e292:65ef with SMTP id af79cd13be357-8abc103b056ms85a; Sun, 2 Nov 2025 12:04:57 -0800 (PST) X-Received: by 2002:a05:6122:10d8:b0:559:5dbe:fe14 with SMTP id 71dfb90a1353d-5595dbf0495mr585694e0c.7.1762113896589; Sun, 02 Nov 2025 12:04:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762113896; cv=none; d=google.com; s=arc-20240605; b=GCvXN08rmJK7dGgrgz466C5UyerPxubgbLXU76C+PrHt9mEsmrgoYMQqZTvRdzLD+G I6PbRQpk4U/EjDFj9b/WgU0OT6ih8LgRy61aW8zJsxqMtjfhSFPPAmsFCOWgfV6q3qP5 sYJgrTzMzGZv4yv0HxryzlKM7Mb3pbcclrqEjNJLol41kCKqRjH62s6Sn6NNNoClPayV zQXBaagh5orP7rw66KKyRFSXHmQ0wCpSwDPgc9vz1xiTTN1vaONZrf03sogd/xPuew9Y C4Ox/+WvBNwurCPUgutqGPXxKA8ABRdzUVEk8QSbLYBrFRI6OyxdXFpoDvzXzenhVnBT v1/g== 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=WQvfCvTnWgEM9cFPn7sK0lXdXnpH9HfSpxS/DSq+DFQ=; fh=qsYSgMvLzs5DwvTd+GzSXpQvMudW/ZJAccQqJKeMJnY=; b=SMV0pwzm63Xk467dKVO2HITRFvyQQriTeZAyVFxa5Bq7fTSP9LQPbxA8WVH+VlXU9X 7ze0Br5+jOQbhUBNCS/iG231e5ry7XvtjHQO+bJTNELs0ZNY2TyxoN8BedvaSrefB8M2 8popsR4i1nD4UB0K6a8KEUPJt9R8GbfATkTzmj4fNC5QEux/FOtKVVs5wjhc9hiNjTnD pfeCseGIT71XjCrDGKGQ86x+ZPriiVMmlSMQGdhH6DnSkC3AakE04WHP2EUyRvB+zCIL tfcI/H3MLGwzvmA/+na2SL2DBlSfkEB/PDL0rwkxz4GYRRzjBZ0CK38AABfQ6FDPPo8W SUnQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=SvOD1X7F; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com. [2607:f8b0:4864:20::62b]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-5595737d483si243885e0c.0.2025.11.02.12.04.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Nov 2025 12:04:56 -0800 (PST) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) client-ip=2607:f8b0:4864:20::62b; Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2955805b7acso7717585ad.1 for ; Sun, 02 Nov 2025 12:04:56 -0800 (PST) X-Gm-Gg: ASbGncsWOfZywETHpWlTF8sCsUu7/UXzwjhfUj7CEPj8EA/bb2tsfi0rql6lZDq0RKk Rc1YH3u+xphErySQAiSgrkc2R+B04T2F9LzwscfQwk6Tt37G48sU8x0MA/I9m6/xHCDmwKpOUDc FlL+Ml2lMpag2FKBxrqtXq7yv/0CA6FTqZViZ9Er+0LsA9ZpIRLj/Qv1qybCLWYcI9cglu1t4Fp v/XS2n+B3NeqDDIKW1D0ZmM0IamCUOpszgfET8pcebNJTK5YbRlGk8nqgYOwZLc5mepJh+Q X-Received: by 2002:a17:902:f684:b0:294:fc13:7e8c with SMTP id d9443c01a7336-29518a878aemr163205665ad.13.1762113895030; Sun, 02 Nov 2025 12:04:55 -0800 (PST) MIME-Version: 1.0 References: <55b43fac-0794-45cb-86d7-535d965f3a74n@googlegroups.com> <9d9073fe-1e1f-4325-bee9-1fbd6cca81f7n@googlegroups.com> <5b81ebfc-7e9e-4e6b-908a-dc538d032908n@googlegroups.com> In-Reply-To: From: Antoine Riard Date: Sun, 2 Nov 2025 20:04:43 +0000 X-Gm-Features: AWmQ_bl7C3M7Zjgbn9U1AEdZtc05c56YSVRKki4121Lds0iqSkGjJwQ7fVjTt24 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="000000000000c463e50642a21c7b" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=SvOD1X7F; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=antoine.riard@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 (/) --000000000000c463e50642a21c7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan, Not sure if you're confusing me with the other Antoine or not, but still here my honest answer to your post. The power is within the hands of the multitude of users. The users are the ones who freely picked up a full-node software, use it to support their bitcoin endeavors, recommend it to their friends, bring back technical feedback to the devs to improve it, make it the evangelism for free at their local meetup or on social network and ultimately who are free to allocate capital and ressources to further the development of a full-node software. If you think that bitcoin core isn't adverse to the desiderata of the users, I do think the lastest months where we have seen an alternative client suddenly being adopted by large swarm of full-node operators is quite telling. While core has been deemed being in a situation of quasi- monopoly for years and that situation would be de facto immutable, the story of the last months points towards another reality. So there is no real "repository authority" as you're describing, or if there is one it's rather because season after season, we see the same cycle repeating. Some groups of users or developers wish to have their consensus ideas or policy mechanisms adopted in bitcoin (core), there is a grounded pushback from another faction of users and developers and then the first dimissed group goes to re-patch their ideas on top of a core fork and finally engage in a "my way or the fork highway" kind of escalation. In my view, the root of the problem is not that "Core" is "corrupted" or "compromised". It's a human institution, so of course there are things that can be improved, and things are constantly improved. The real problem is that most of the time, the dissatisfied of the Core process don't have the cold determination to go for real in developing their own alternative bitcoin clients, with its own set of features, its own culture of development and in patiently growing its user base. Apologies if I say something obvious, but it's not by threatening to soft-fork that a full-node project is going to earn the credibility and the "trust" o= f large swarm of the community. Quite the contrary, it's more likely to have the opposite effect in the low-time preference minds. Basic of "product management", if you have hundreds of users that are okay to choose a lower quality software because of default settings, that's great news. You have already a niche, now professionalize a bit the project and keep growing from it. I really hope that one of the positive outcome that will emerge from the last months of circus will be that finally that Bitcoin Gnocchi starts to be a real project, that it grows its own community of contributors and go to live more a life of its own. And if Gnocchi is not a delicious enough software in the taste of some, the good news is that libbitcoinkernel probably slashes by few order of magnitude the complexity of building a full-node. More freedom to make your own kitchen and cook your own recipes. Frankly, what you're proposing with the repository label renaming, it's just cosmetic. Bitcoin core won't loose its shamanic-like "authority" just because some repository would have changed its name. But because, there would be an ecosystem with multiple high-quality well-maintained clients to pick up from, and network-wide change would have to be the fruit of a high-flying technical debate, or at least to be experimented on its own by an implementation for a while resulting in unequivocal improvements. But on the stability of the network and not slipping into fork adventurism, bitcoin core is right here and one can be sure I share plainly the opinion of many of core contributors. Best, Antoine OTS hash: 17d321f45c7499543a96fb660d9e18ba6448bb9514d51c77e7868d5bdb125b95 Le sam. 1 nov. 2025 =C3=A0 16:58, Juan Aleman a =C3=A9crit : > Hello Antoine, > > Nice to meet you. The main issue here is with the bitcoin/bitcoin repo > itself. A single authority with too much influence, now 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, and even friends. > But "CoreDevs" seem way too invested to remain unbiased, clearly missing > the forest for the trees. > > Glad to learn that bitcoin/bitcoin-core already has some headway, seems > like libbitcoinkernel could eventually be integral in this new > consensus-focused repo I'm proposing bitcoin/bitcoin be repurposed to. Bu= t > for a v1, we can K.I.S.S.: > > - bitcoin/bitcoin-node continues as an exact duplicate of the current > bitcoin/bitcoin (heading into using the NEW core, eventually) > - bitcoin/bitcoin is renamed to bitcoin/bitcoin-core, and can start > fat-trimming (heading into libbitcoinkernel integration, apparently) > > > Or we can just revert > defaults. > > Let's be adults. Do you really want to continue fighting? There's this > thing called the golden rule, and Core broke it. Accept it, let's fix wha= t > 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 > by default, is undeniably abusive and risky. Which we are experiencing th= e > consequences 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 >> 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 >> that. >> >> Define "power" seriously, I read almost the integrality of Michel >> 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=A9cri= t : >> >>> Greg I actually agree there should be no "official" anything. That is >>> why I purposefully 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 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 year= s 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 the= m. >>>> Maybe they are wrong, but fortunately you have the freedom to go your = own >>>> way. There is no 'official' anything. Continuing to try to coerce ot= hers >>>> to do what you want when they think it would be wrong 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 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 >>>>> something >>>>> , >>>>> 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 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" practice. A highly controversial change that surfaces th= e >>>>>>> influence over default policy in the network, escalating to the poi= nt 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 real= ized >>>>>>> that the main issue here is social-political, not technical. It's a= bout the >>>>>>> powerful influence the "Official Reference Implementation" centrali= zed 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 repository ( >>>>>>> https://github.com/bitcoin/bitcoin) maintains consensus code while >>>>>>> also defining default relay and mining policies, among all other no= de >>>>>>> functionalities, in a single piece of software. This concentration = of >>>>>>> responsibilities leads to elevating this single repository to a "pe= destal", >>>>>>> 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) d= isrupt >>>>>>> "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 realist= ic >>>>>>> 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 consensu= s >>>>>>> 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 fo= r the >>>>>>> current bitcoin/bitcoin node software. This repository embeds the >>>>>>> consensus-focused bitcoin-core (objective), while including "curren= t core >>>>>>> devs"-recommended default policies (subjective). Other clients woul= d use >>>>>>> this as their foundation, to customize policy and beyond. (Also, th= ere is >>>>>>> nothing preventing multiple bitcoin-node- existing in paralle= l, 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 (where >>>>>>> beneficial). >>>>>>> >>>>>>> For a smooth transition that resolves ongoing tensions, the >>>>>>> suggested first release of bitcoin/bitcoin-node should revert to pr= e-v30 >>>>>>> defaults. Then, a subsequent release could adopt v30 defaults, with= the >>>>>>> home README clearly documenting options/alternatives (e.g. "For leg= acy >>>>>>> Money-First policies, use X"). >>>>>>> >>>>>>> *(But STILL the simplest solution is just to allow something like >>>>>>> this . And let's jus= t 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 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 principl= es. >>>>>>> >>>>>>> >>>>>>> *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 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 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+...@googlegroups.com. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b91= 5-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, sen= d >>>>> an email 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 a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/hb39zFTnYLc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/f60a2f77-ab31-4bde-ad5b-736a= 0f19a915n%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/= CALZpt%2BE%2BepbPTH%2Bv3UOw-dS6UfXhPysmmx-b5Aj7zkND_uuj9A%40mail.gmail.com. --000000000000c463e50642a21c7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Juan,

Not sure if you're co= nfusing me with the other Antoine or not,
but still here my honest answe= r to your post.

The power is within the hands of the multitude of us= ers.

The users are the ones who freely picked up a full-node softwar= e,
use it to support their bitcoin endeavors, recommend it to their
f= riends, bring back technical feedback to the devs to improve it,
make it= the evangelism for free at their local meetup or on social
network and = ultimately who are free to allocate capital and ressources
to further th= e development of a full-node software.

If you think that bitcoin cor= e isn't adverse to the desiderata of the
users, I do think the laste= st months where we have seen an alternative
client suddenly being adopte= d by large swarm of full-node operators is
quite telling. While core has= been deemed being in a situation of quasi-
monopoly for years and that = situation would be de facto immutable, the
story of the last months poin= ts towards another reality.

So there is no real "repository aut= hority" as you're describing, or if
there is one it's rathe= r because season after season, we see the same
cycle repeating. Some gro= ups of users or developers wish to have their
consensus ideas or policy = mechanisms adopted in bitcoin (core), there is
a grounded pushback from = another faction of users and developers and then
the first dimissed grou= p goes to re-patch their ideas on top of a core
fork and finally engage = in a "my way or the fork highway" kind of escalation.

In m= y view, the root of the problem is not that "Core" is "corru= pted" or
"compromised". It's a human institution, so = of course there are things that
can be improved, and things are constant= ly improved. The real problem is that
most of the time, the dissatisfied= of the Core process don't have the cold
determination to go for rea= l in developing their own alternative bitcoin
clients, with its own set= of features, its own culture of development and
in patiently growing it= s user base.

Apologies if I say something obvious, but it's not = by threatening to soft-fork
that a full-node project is going to earn th= e credibility and the "trust" of
large swarm of the community.= Quite the contrary, it's more likely to have the
opposite effect in= the low-time preference minds. Basic of "product management",if you have hundreds of users that are okay to choose a lower quality soft= ware
because of default settings, that's great news. You have alread= y a niche, now
professionalize a bit the project and keep growing from i= t.

I really hope that one of the positive outcome that will emerge f= rom the last
months of circus will be that finally that Bitcoin Gnocchi = starts to be a real
project, that it grows its own community of contribu= tors and go to live more a
life of its own. And if Gnocchi is not a deli= cious enough software in the taste
of some, the good news is that libbit= coinkernel probably slashes by few order of
magnitude the complexity of = building a full-node. More freedom to make your own
kitchen and cook you= r own recipes.

Frankly, what you're proposing with the repositor= y label renaming, it's just cosmetic.
Bitcoin core won't loose i= ts shamanic-like "authority" just because some repository
woul= d have changed its name. But because, there would be an ecosystem with mult= iple
high-quality well-maintained clients to pick up from, and network-w= ide change would
have to be the fruit of a high-flying technical debate,= or at least to be experimented
on its own by an implementation for a wh= ile resulting in unequivocal improvements.

But on the stability of t= he network and not slipping into fork adventurism, bitcoin
core is right= here and one can be sure I share plainly the opinion of many of core
co= ntributors.

Best,
Antoine
OTS hash: 17d321f45c7499543a96fb660d= 9e18ba6448bb9514d51c77e7868d5bdb125b95


Le=C2=A0sam= . 1 nov. 2025 =C3=A0=C2=A016:58, Juan Aleman <bitcoindev@juanaleman.com> a =C3=A9crit=C2=A0:
Hello Antoine,
=
Nice to meet you. The main issue here is with the bitcoin/bitcoin repo = itself. A single authority with too much influence, now escalating to the p= oint of a fork over defaults.

The power of defaults.

I don= 9;t know how you feel about this whole situation, but for me, it's quit= e uncomfortable to be in deep conflicts with peers, and even friends. But &= quot;CoreDevs" seem way too invested to remain unbiased, clearly missi= ng the forest for the trees.

Glad to learn that bitcoin/bitcoin-core= already has some headway, seems like libbitcoinkernel could eventually be = integral in this new consensus-focused repo I'm proposing bitcoin/bitco= in be repurposed to. But for a v1, we can K.I.S.S.:
  • bitcoin/bitc= oin-node continues as an exact duplicate of the current bitcoin/bitcoin (he= ading into using the NEW core, eventually)
  • bitcoin/bitcoin is renam= ed to bitcoin/bitcoin-core, and can start fat-trimming (heading into libbit= coinkernel integration, apparently)

Or we can just revert= defaults.

Let's be adults. Do you really want to continue fight= ing? There's this thing called the golden rule, and Core broke it. Acce= pt it, let's fix what we can, and move on.

I anticipate this who= le 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 by default, is undeniabl= y abusive and risky. Which we are experiencing the consequences of... Let&#= 39;s stop the escalation!

On Friday, October 31, 2025 at 8:09:25=E2=80=AFPM U= TC-4 Antoine Riard wrote:
Hi Juan,

Confirming you that libbitcoinkernel is mature e= nough to hack on it.

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

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

addr-daemon:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin addr_relayd
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 cp target/debug/addr_relayd addr_relayd

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

topo-daemon:=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin topo_mngrd
=C2=A0 =C2=A0= =C2=A0 =C2=A0 cp target/debug/topo_mngrd topo_relayd

mempool-daemon= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin mempool_mngrd
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 cp target/debug/mempool_mngrd mempool_mngrd

txc= ontroller-daemon:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cargo build --bin tx_contr= ollerd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cp target/debug/tx_controllerd tx_con= trollerd

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 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 hash: 3f4d81c217237a38d5f47457d51c9e6990068e47
Le vendredi 31 octo= bre 2025 =C3=A0 19:14:30 UTC, Juan Aleman a =C3=A9crit=C2=A0:
Greg I actually agree th= ere should be no "official" anything. That is why I purposefully = always use "quotes" around it.

Unfortuna= tely for both of us, this is not a reflection of reality. "Official Bi= tcoin Core" has become itself the power grab.

My proposal is about bringing this to the forefront. Most discussions I se= e revolve around who can win an argument. All these are distractions IMO, t= he 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=AF= PM 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 satisf= y other people who disagree with them.=C2=A0 Maybe they are wrong, but fort= unately you have the freedom to go your own way.=C2=A0 There is no 'off= icial' anything.=C2=A0 Continuing=C2=A0to try to coerce=C2=A0others to = do what you want when they think it would be wrong and harmful is a bad cho= ice which will make enemies out of people who otherwise would be indifferen= t to your efforts that they regard as misguided.

=
On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM Juan Ale= man <bitco...@juanaleman.com> wrote:
Hello Greg, thanks for your feedback. I am already starting to d= o something, but= the main point IS about the centralization risks of the "official&quo= t; repo...

On Friday, October 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwe= ll wrote:
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 <bitco...@juanaleman.com= > wrote:
Hello bitcoin developers,

My name i= s Juan Alem=C3=A1n, and this is my first post to the mailing list. But I= 9;ve been involved with Bitcoin since 2017. First only as a hard money inve= stor, but later also as a developer, specially fascinated by this permanent= medium. I hope this proposal can be appreciated by all perspectives as a p= ragmatic (maybe unorthodox, but timely) solution to move forward in agreeme= nt.

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 in= fluence over default policy in the network, escalating to the point of a fork proposal.

First, it must be reminded that a for= k should be unnecessary if defaults are simply reverted, while still allowing all policy possibilities.

After my second <= a href=3D"https://github.com/bitcoin/bitcoin/pull/33690" rel=3D"nofollow" t= arget=3D"_blank">PR attempt was (also) closed (and I was blocked from t= he repo), I realized that the main issue here is social-political, not tech= nical. It's about the powerful influence the "Official Reference I= mplementation" centralized node software repository has.

This n= eeds a different kind of solution. I'd like to propose a high-level str= uctural change to the "Official Bitcoin Repository": Separating c= onsensus code from policy-based node distribution.

Problem Statem= ent:

The "official" Bitcoin Core node repository (https://github.com/bitcoin/bitcoin) maintains consensus code while a= lso defining default relay and mining policies, among all other node functi= onalities, in a single piece of software. This concentration of responsibil= ities leads to elevating this single repository to a "pedestal", = thus a point of centralization, giving a few too much influence.

Thi= s kind of influence can be considered "harm" when abrupt default = policy changes (like v30's shift toward permissive data carrying) disru= pt "standard" network practices and its users.

However, th= e v30 release itself may have caused a point of no return, where "glob= ally agreed standardness" is no longer a realistic expectation. Bitcoi= n'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.
<= br>1. Rename and Refocus Core Repo:

=C2=A0 =C2=A0 Rename (github.com/)bitcoin/bitcoin to bitcoin/bitcoin-core. This repo woul= d focus mainly on consensus rules, removing arbitrary or non-critical polic= ies 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 Crea= te a separate repository for the full-featured node client, starting with (= github.com/)bitcoin/bitcoin-node as the foundational templa= te. 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"-re= commended default policies (subjective). Other clients would use this as th= eir foundation, to customize policy and beyond. (Also, there is nothing pre= venting multiple bitcoin-node-<type> existing in parallel, best addre= ssing 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 i= ncorporating more modularity (where beneficial).

For a smooth transi= tion 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 t= he bag anyway.)

This proposal attempts to find a compromise wher= e no side feels "forced to comply", and represents a more neutral= position from the "Official Reference Implementation" repository= in this new era.

Benefits:
  • Bitcoin-Core reaches i= ts epitome, focusing on a hardened consensus core that serves all clients, = regardless of policy.
  • Reduction of the "official" repo= 9;s influence on default policy, better aligning with Bitcoin's decentr= alization principles.

Drawbacks:
  • Breaks exis= ting 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 nod= e software to run moving forward).
  • Also, there must be caution of n= ot using the original github.com/bitcoin/bitcoin name for anythin= g else, as that would break automatic GitHub url redirects.
<= br>

Thank you for your time. This is just an idea I wan= ted to share for discussion, and I would appreciate any thoughts.

Ju= an

--
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 htt= ps://groups.google.com/d/msgid/bitcoindev/d397e2e1-3d5b-473a-b915-aca2cfc9d= a32n%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 htt= ps://groups.google.com/d/msgid/bitcoindev/55b43fac-0794-45cb-86d7-535d965f3= a74n%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://group= s.google.com/d/topic/bitcoindev/hb39zFTnYLc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/f60a2f77-ab31-4bde-ad5b-736a0f19a915n%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.co= m/d/msgid/bitcoindev/CALZpt%2BE%2BepbPTH%2Bv3UOw-dS6UfXhPysmmx-b5Aj7zkND_uu= j9A%40mail.gmail.com.
--000000000000c463e50642a21c7b--