From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 02 Nov 2025 12:58:18 -0800 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 1vFf9U-0002wt-O0 for bitcoindev@gnusha.org; Sun, 02 Nov 2025 12:58:18 -0800 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-654efbca90csf7240717eaf.3 for ; Sun, 02 Nov 2025 12:58:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762117090; cv=pass; d=google.com; s=arc-20240605; b=gvyONw+dvlj7kVSVtMbBYgfzHd49BAmD9hLo9TX0xOn5O2cXazLFAKYl5BeW35kYom YZyGgtYMJAOx2hAQg/J5MbWyOytYlV38Fp82u1OZRb6Mff4VVXu9vR7dZoUQSysyW6HL bSTDQ1p6Y0NSVZiOncnByWn5wAvp/ZP1Hjj/8O36Zz5HcHfkBfdfa9LJM9Qd0gIyBcr0 qFPf+MgutIgZgWSsa5X0TGBrXdgRfeFvz5rKgCGc3CSaHR7fBsXWfxTzx8za+m2vgfvg aSjl91fctPFVZDT8uvM8vV4ZPMYYzxE7XHP+N3q1slG0MbVqLZoKnVg2yKOtsMlcvEyq mtrQ== 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; bh=EeXg3sSkJfBCNOrBxR7UtGipLlTtxeDnbF4g/u+Tn2U=; fh=qjlER9qQQsfz6C5s23c4xDbZPpDKrsLDCAJ2j5Lf2Bw=; b=Pkoe80GektAXzhL+LObwTSelCMiIbefLgN0PqMagKm9by/D3IqPKXMe6fvOte+rFDp CzoQ5kraSTj73jQ+WrmnAY01K1rXdc1oXLs7XTAS4YPPmEiqk+YqxqscVcIcEVcIRT5n PvAO4by9yY1bSgkzd5tVn2Qab3ucNI8Xfy4Iliv5ffiM+zu5MDgerPere8T2ean4bBy4 GLWmjlmuArnmnJ78q98G/yw9Mo+3AIQl681oil8F1ecHGDbXGDB50PcPD1QNAQhyW/XD epMLDOSA/82zc9gKOCktZKVhg2cV+D7FVWsooNH+Qq2/RaDaVuymfBEMQa98V5L3fMQt A0/A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@juanaleman-com.20230601.gappssmtp.com header.s=20230601 header.b=xUtWkOz2; spf=none (google.com: a@juanaleman.com does not designate permitted sender hosts) smtp.mailfrom=a@juanaleman.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762117090; x=1762721890; 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=EeXg3sSkJfBCNOrBxR7UtGipLlTtxeDnbF4g/u+Tn2U=; b=rDpe4TRlf7vyf74SNMSMZHg4OqeBYSmT3Bi34I9w2/CDG0YBLkCyoVdbBKw95Dc1aG m4PtMEQGIk9CJpXx/YTWAAU+BGhENDa57kl67Gfscy2UCdoGwM0mutTPaU1GxN3yScQk 4p9TMiummvKrw88MpA+vvY2/3NXUTysnlJAgGEDT/5JIm9ATTVZ07mLNqs6vZGJtMw+u xxYZMvqw4OiK6Iy7XWtdyB3WLONRpGo6AJ2ApGn2VVCTaoQVGXO+op+wkuiBfHdeRZxX moW1YbmZj0XwoypsznM4vJtMqI+/uh8nVobFxlo9pWfk9YP8ZXbl/I8W/txgB5rYQO2q ppWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762117090; x=1762721890; 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=EeXg3sSkJfBCNOrBxR7UtGipLlTtxeDnbF4g/u+Tn2U=; b=vAixfgXryGGIJOIYtlmcat6rEz7uyvKgoBV2ocIFnCeUrHN3InR22fFDCaICTZIXfn A0qAUZULbnAqT2FnZNUBLs1m/GgNl0LV5et31kmSLhU3GMV7xdeKYbGWPZ4GZwFYWYdT j8a9getpoJ99Rd+NW51ia+m/JYZznbYVA4pSmBOW2Dx1P2mtvRK7PzmeYwumB7d478or vkyfTNxSQBUKDvYh6xLo/q78vJPwSzoj82+kTqTwSLzFiBaC5hKzStNfhG5Eb6Ep99e2 zJjMA8F/2R4LOVQrWKoncw6rI7x94AVpdbEDWvpNLph0LNBL2msa4AsPQFheIV8gIo7k xiLQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXmPZn2/elirp0z9EGeB3VJk08PUGuslQm7Fgqwb/HW+uBaJgX5KehNgP0O1KC3V7TaOyXkWBzcDh8s@gnusha.org X-Gm-Message-State: AOJu0YwY5osWrq5gYPxjuk3CFVJZ9mmRTvN+GDetWzdYC+dcQSF0xZPj DNjpwo5nldzNSxoqoLYKDvlUPLvc8RrCvVe8qCnpc6jsVbq59eoK2oQx X-Google-Smtp-Source: AGHT+IEfLYlrRiebZdRn0YO3ZSEfFk5txMo43KhUj15Q9kFRY7+op2zLrs6m9r42wHzV8A4EP+egJg== X-Received: by 2002:a05:6870:a19b:b0:3a5:81b0:8339 with SMTP id 586e51a60fabf-3dacbfbc7ffmr4844025fac.31.1762117088725; Sun, 02 Nov 2025 12:58:08 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Y5Rzz7NT2lmxNXmqR5ASCrBYmAsnq3yL5+2lTuzCobQQ==" Received: by 2002:a05:6871:8702:20b0:3de:cd92:aba0 with SMTP id 586e51a60fabf-3decd930253ls75513fac.1.-pod-prod-01-us; Sun, 02 Nov 2025 12:58:05 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUBMn0s1Y7lkWndK/h/30IpbosWd3RrMLvBZ14HWpSReAISuwBHeKsYgm5W/ZqcESACoz8J0pUTTDYp@googlegroups.com X-Received: by 2002:a05:6808:f8c:b0:441:8f74:fad with SMTP id 5614622812f47-44f95ff85b2mr4788236b6e.58.1762117085346; Sun, 02 Nov 2025 12:58:05 -0800 (PST) Received: by 2002:a05:620a:10b0:b0:89e:af87:26f0 with SMTP id af79cd13be357-8aa83d82dfcms85a; Sun, 2 Nov 2025 12:44:06 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUoWUS6n/W09sFfwJHjV+4kZQ2QWOvEIlcCFwiju0QcAuRKZDmKklH49+Du83zJZ8+SnLBjyG8+SX5H@googlegroups.com X-Received: by 2002:a05:622a:8314:b0:4ec:f940:4e55 with SMTP id d75a77b69052e-4ed31632050mr111082991cf.47.1762116245296; Sun, 02 Nov 2025 12:44:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762116245; cv=none; d=google.com; s=arc-20240605; b=BMM14wOg/ftS9j+7vY8+lZb9hur4rcb04eEzly3abTOiLdvp8djElp44BZONTHdl8J CROLtPj490amhukKNvOqDI3kXl5f4GP839zcGMjPF5rZs9lXvJdQOK04/i3eyiq5K8lf yzm+0OXFaKU5cuvR3qo0ydqFWFPsPinGzgIFSjOAom6ESArbW75DorcVB2CacWjQ7sax Cwi6SeCyBmWcUADJ9nW/r1Gj6+TaLCSGny+VHvf84Cpw5pKeFLk9SmptRbvfT5zo16E5 YhnxtxhBQr5q2ytzpA6VNVe9EK9SWEPtCIzd3kSyqbhQhkE37+Lm3RKT+QwqIIyk9IBq 1DNw== 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=Rx4w5RkQZ0g7e4Nfhpt44BxbwSH8cN6BOlMuiIa6M8E=; fh=drYuUyw0JQ86N/vb+bn2sOJBhldVqHenKPO61zhcfgE=; b=BZh+ZlVM+PDZIPbaKPoXokHn799y+yyjZROKyRXIEWvs1ws8BbHKHB7DpSLCTyM51/ WSpcqbeO7zAd9D+b5Y8+0G8dRSIYxr3Yo/ROXGvpXt15yMSN/v0vH/vV+wvzXy0eQWYO 2bas4ASStaBpTyK5S+2pvAEirqvEfBEmDc3Sn7XgUHjCzAw/aat9INNie2P2aeAaPtFF scvpIDXgdLrOWCOTYUhcK9ujYyW4qBKugY+dPTst6/2TQAT3A5YVNbTFWa8lIwG+YiWk 1aXEdXfEdokbI/H8kTCRegNiLR3Qo+ryaPWif0nvXg42Mnf1iJvnXkYgjf2vATsn9Rsp GK3w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@juanaleman-com.20230601.gappssmtp.com header.s=20230601 header.b=xUtWkOz2; spf=none (google.com: a@juanaleman.com does not designate permitted sender hosts) smtp.mailfrom=a@juanaleman.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com. [2607:f8b0:4864:20::f2d]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-4ed34ff3a06si1918151cf.2.2025.11.02.12.44.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Nov 2025 12:44:05 -0800 (PST) Received-SPF: none (google.com: a@juanaleman.com does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::f2d; Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-8804650ca32so11745646d6.0 for ; Sun, 02 Nov 2025 12:44:05 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCX5rG7X0AAqyR7Rh+coVMg9QmFXiOUI15o16EpcbDmT3u8Pp6nV5Ajwzi2YVH71AyzKWgfBo7jcuUXR@googlegroups.com X-Gm-Gg: ASbGncsXxQnzD0Vg3NX3xKyoTI4OZaw6Qd1cwnfthdqsGCKSTUxeFdNR8g9CAPrYzHS Kcss/zGs/4gO+uVlp70+Rpv9y21Bx+Sju98H427MtaEYM4pOCT4HM+0siXrFIsoNfIJsvv6ACXN bklJYO7tr1EuXE9nHZpWltB8DxdKApCj8P31j4YBRSGcxWrblouBeNPOOhGKWirMdYRLZEQECZS m2q+Ai2KLxlrl8PADGyhJmFm06cC3I/0EtJS2DrdeJW/AFMl4KGbHGThwxFXFDJ8GwFNCwacv6q 4z5JnNH5UYHlYPX+oTQ7xYeXXUiAjw== X-Received: by 2002:a05:6214:4a81:b0:87c:2213:ed28 with SMTP id 6a1803df08f44-8802f30d1dbmr153448436d6.27.1762116244704; Sun, 02 Nov 2025 12:44:04 -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: Juan Aleman Date: Sun, 2 Nov 2025 16:43:53 -0400 X-Gm-Features: AWmQ_bmvKtyiSr8K4e2udS3d_J6a7UApNbis_eH3wyG9dAFaPQCJZ0jC2ouOyx8 Message-ID: Subject: Re: [bitcoindev] [Pre-BIP Discussion] Bitcoin Node Repository Consensus-Policy Separation To: Antoine Riard Cc: Juan Aleman , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000d19bde0642a2a88a" X-Original-Sender: a@juanaleman.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@juanaleman-com.20230601.gappssmtp.com header.s=20230601 header.b=xUtWkOz2; spf=none (google.com: a@juanaleman.com does not designate permitted sender hosts) smtp.mailfrom=a@juanaleman.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.7 (/) --000000000000d19bde0642a2a88a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Antoine, For a moment I did confuse you, but (at least part of) the response still applies ;) Seriously though, thank you for your elaborated response. I think you actually agree with the structural issue when bitcoin/bitcoin is called Bitcoin Core, but is actually a one-stop client application, the reference implementation of what has been Bitcoin since Satoshi. It creates this =E2=80=9Celite=E2=80=9D. This =E2=80=9Celite=E2=80=9D is no= t a very organic grown species, is trust based. 99% of your marketers and customers don=E2=80=99t verify an= ything. I for sure could, but never did. I delegated that responsibility=E2=80=A6 u= ntil v30 (and I should have been like this since Segwit, but that was ahead of me). But you=E2=80=99re also telling me that you don=E2=80=99t have to change an= ything. And I agree. I=E2=80=99m just sharing what I would do, to end the divide, and don=E2=80= =99t get conquered. Thank you for your feedback. Juan On Sun, Nov 2, 2025 at 4:04=E2=80=AFPM Antoine Riard wrote: > 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 th= at > 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 col= d > 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" > of > large swarm of the community. Quite the contrary, it's more likely to hav= e > 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 wit= h > 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 man= y > of core > contributors. > > Best, > Antoine > OTS hash: 17d321f45c7499543a96fb660d9e18ba6448bb9514d51c77e7868d5bdb125b9= 5 > > 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 th= e >> 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. B= ut >> 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 wh= at >> we can, and move on. >> >> I anticipate this whole situation has been very educational for many, an= d >> it is actually GOOD to have the option to use multiple OP_RETURNs instea= d >> of burn outputs. But a 1000x increase of non-transactional arbitrary dat= a >> by default, is undeniably abusive and risky. Which we are experiencing t= he >> consequences of... Let's stop the escalation! >> >> On Friday, October 31, 2025 at 8:09:25=E2=80=AFPM UTC-4 Antoine Riard wr= ote: >> >>> 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 wit= h >>> 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=A9cr= it : >>> >>>> 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 yea= rs is >>>> no longer viable. >>>> >>>> On Friday, October 31, 2025 at 2:48:48=E2=80=AFPM UTC-4 Greg Maxwell w= rote: >>>> >>>>> Other people don't do what you want because they believe it would har= m >>>>> Bitcoin and they have no interest in spending their efforts trying to= harm >>>>> something they love just to satisfy other people who disagree with th= em. >>>>> 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 o= thers >>>>> 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 "officia= l" >>>>>> 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 creat= e >>>>>>> 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 mail= ing >>>>>>>> list. But I've been involved with Bitcoin since 2017. First only a= s a hard >>>>>>>> money investor, but later also as a developer, specially fascinate= d by this >>>>>>>> permanent medium. I hope this proposal can be appreciated by all >>>>>>>> perspectives as a pragmatic (maybe unorthodox, but timely) solutio= n 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 bee= n >>>>>>>> "standard" practice. A highly controversial change that surfaces t= he >>>>>>>> influence over default policy in the network, escalating to the po= int 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 rea= lized >>>>>>>> that the main issue here is social-political, not technical. It's = about the >>>>>>>> powerful influence the "Official Reference Implementation" central= ized 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 n= ode >>>>>>>> functionalities, in a single piece of software. This concentration= of >>>>>>>> responsibilities leads to elevating this single repository to a "p= edestal", >>>>>>>> thus a point of centralization, giving a few too much influence. >>>>>>>> >>>>>>>> This kind of influence can be considered "harm" when abrupt defaul= t >>>>>>>> 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 standardness" is no longer a realis= tic >>>>>>>> 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 (polic= y) >>>>>>>> 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 arbitrar= y or >>>>>>>> non-critical policies from its scope. It becomes a neutral base fo= r ALL >>>>>>>> node implementations, emphasizing on hardening and testing consens= us >>>>>>>> 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 re= pository >>>>>>>> embeds the consensus-focused bitcoin-core (objective), while inclu= ding >>>>>>>> "current core devs"-recommended default policies (subjective). Oth= er >>>>>>>> clients would use this as their foundation, to customize policy an= d beyond. >>>>>>>> (Also, there is nothing preventing multiple bitcoin-node- ex= isting in >>>>>>>> parallel, best addressing default-bias concerns.) >>>>>>>> >>>>>>>> >>>>>>>> The initial implementation of this separation might not be elegant= , >>>>>>>> but future releases can progressively refactor based on this new >>>>>>>> reorganization, potentially incorporating more modularity (where >>>>>>>> beneficial). >>>>>>>> >>>>>>>> For a smooth transition that resolves ongoing tensions, the >>>>>>>> suggested first release of bitcoin/bitcoin-node should revert to p= re-v30 >>>>>>>> defaults. Then, a subsequent release could adopt v30 defaults, wit= h the >>>>>>>> home README clearly documenting options/alternatives (e.g. "For le= gacy >>>>>>>> Money-First policies, use X"). >>>>>>>> >>>>>>>> *(But STILL the simplest solution is just to allow something like >>>>>>>> this . And let's ju= st 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 th= e >>>>>>>> "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 princip= les. >>>>>>>> >>>>>>>> >>>>>>>> *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 wil= l 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 fo= r >>>>>>>> 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-b9= 15-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 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-736= a0f19a915n%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/= CADNMaA4vWnDMoPOc%2B7tUOnYap%2BPLxnj2HS0rMz0Ecd11OQwxJQ%40mail.gmail.com. --000000000000d19bde0642a2a88a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Antoine,

For a moment I did confuse you, but (at least part of) the respon= se still applies ;)

Seri= ously though, thank you for your elaborated response. I think you actually = agree with the structural issue when bitcoin/bitcoin is called Bitcoin Core= , but is actually a one-stop client application, the reference implementati= on of what has been Bitcoin since Satoshi.

It creates this =E2=80=9Celite=E2=80=9D. This =E2=80=9Ce= lite=E2=80=9D is not a very organic grown species, is trust based. 99% of y= our marketers and customers don=E2=80=99t verify anything. I for sure=C2=A0= could, but never did. I delegated that responsibility=E2=80=A6 until v30 (a= nd I should have been like this since Segwit, but that was ahead of me).

But you=E2=80=99re also te= lling me that you don=E2=80=99t have to change anything. And I agree.
=

I=E2=80=99m just sharing what= I would do, to end the divide, and don=E2=80=99t get conquered.

Thank you for your feedback.
=

Juan

On Sun, Nov 2, 2025 at 4:04=E2=80=AFPM Antoine Riard <antoine.riard@gmail.com> wrote:
=

Hi Juan,

Not sure= if you're confusing me with the other Antoine or not,
but still her= e my honest answer to your post.

The power is within the hands of th= e 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 impro= ve it,
make it the evangelism for free at their local meetup or on socia= l
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 d= o think the lastest months where we have seen an alternative
client sudd= enly being adopted by large swarm of full-node operators is
quite tellin= g. While core has been deemed being in a situation of quasi-
monopoly fo= r years and that situation would be de facto immutable, the
story of the= last months points towards another reality.

So there is no real &qu= ot;repository authority" as you're describing, or if
there is o= ne it's rather because season after season, we see the same
cycle re= peating. Some groups of users or developers wish to have their
consensus= ideas or policy mechanisms adopted in bitcoin (core), there is
a ground= ed pushback from another faction of users and developers and then
the fi= rst dimissed group goes to re-patch their ideas on top of a core
fork an= d finally engage in a "my way or the fork highway" kind of escala= tion.

In my view, the root of the problem is not that "Core&quo= t; is "corrupted" or
"compromised". It's a human= institution, so of course there are things that
can be improved, and th= ings are constantly improved. The real problem is that
most of the time,= the dissatisfied of the Core process don't have the cold
determinat= ion to go for real in developing their own alternative bitcoin
clients,= with its own set of features, its own culture of development and
in pat= iently 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" of
large swarm = of the community. Quite the contrary, it's more likely to have the
o= pposite effect in the low-time preference minds. Basic of "product man= agement",
if you have hundreds of users that are okay to choose a l= ower quality software
because of default settings, that's great news= . You have already a niche, now
professionalize a bit the project and ke= ep growing from it.

I really hope that one of the positive outcome t= hat 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 comm= unity of contributors and go to live more a
life of its own. And if Gnoc= chi is not a delicious enough software in the taste
of some, the good ne= ws is that libbitcoinkernel probably slashes by few order of
magnitude t= he complexity of building a full-node. More freedom to make your own
kit= chen and cook your own recipes.

Frankly, what you're proposing w= ith the repository label renaming, it's just cosmetic.
Bitcoin core = won't loose its shamanic-like "authority" just because some r= epository
would have changed its name. But because, there would be an ec= osystem with multiple
high-quality well-maintained clients to pick up fr= om, 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 implem= entation for a while resulting in unequivocal improvements.

But on t= he 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 m= any of core
contributors.

Best,
Antoine
OTS hash: 17d321f45= c7499543a96fb660d9e18ba6448bb9514d51c77e7868d5bdb125b95


Le=C2=A0sam. 1 nov. 2025 =C3=A0=C2=A016:58, Juan Aleman &l= t;bitcoindev= @juanaleman.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">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 si= tuation, but for me, it's quite uncomfortable to be in deep conflicts w= ith 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 lib= bitcoinkernel could eventually be integral in this new consensus-focused re= po 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 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)
    • <= /ul>
    Or we can just revert defaults.

    Let's be adults. Do= you really want to continue fighting? There's this thing called the go= lden rule, and Core broke it. Accept it, let's fix what we can, and mov= e on.

    I anticipate this whole situation has been very educational fo= r many, and it is actually GOOD to have the option to use multiple OP_RETUR= Ns instead of burn outputs. But a 1000x increase of non-transactional arbit= rary data by default, is undeniably abusive and risky. Which we are experie= ncing the consequences of... Let's stop the escalation!

    On Friday, Octobe= r 31, 2025 at 8:09:25=E2=80=AFPM UTC-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 there should be no "official&q= uot; anything. That is why I purposefully always use "quotes" aro= und it.

    Unfortunately for both of us, this is not = a reflection of reality. "Official Bitcoin Core" has become itsel= f the power grab.

    My proposal is about bringing th= is to the forefront. Most discussions I see revolve around who can win an a= rgument. All these are distractions IMO, the issue here IS with the structu= re we have "trusted" for so many years is no longer viable.
    =
    On Fr= iday, October 31, 2025 at 2:48:48=E2=80=AFPM UTC-4 Greg Maxwell wrote:
    <= /div>
    Other people don't do what = you want because they believe it would harm Bitcoin and they have no intere= st in=C2=A0spending their efforts trying to harm something they love just t= o satisfy other people who disagree with them.=C2=A0 Maybe they are wrong, = but fortunately you have the freedom to go your own way.=C2=A0 There is no = 'official' anything.=C2=A0 Continuing=C2=A0to try to coerce=C2=A0ot= 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 in= different to your efforts that they regard as misguided.


    On Fri, Oct 31, 2025 at 6:41=E2=80=AFPM = Juan Aleman <bitco...@juanaleman.com> wrote:<= br>
    Hello Greg, than= ks 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, Octob= er 31, 2025 at 2:24:36=E2=80=AFPM UTC-4 Greg Maxwell wrote:
    If you want that and=C2=A0think it would b= e 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 is Juan Alem=C3= =A1n, and this is my first post to the mailing list. But I've been invo= lved with Bitcoin since 2017. First only as a hard money investor, but late= r also as a developer, specially fascinated by this permanent medium. I hop= e this proposal can be appreciated by all perspectives as a pragmatic (mayb= e 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 the influence over d= efault policy in the network, escalating to the point of a fo= rk proposal.

    First, it must be reminded that a fork should be un= necessary if defaults are simply reverted, while stil= l allowing all policy possibilities.

    After my second PR attempt was (also) closed (and I was blocked from the repo), I re= alized that the main issue here is social-political, not technical. It'= s about the powerful influence the "Official Reference Implementation&= quot; centralized node software repository has.

    This needs a differe= nt 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://git= hub.com/bitcoin/bitcoin) maintains consensus code while also defining d= efault 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 o= f centralization, giving a few too much influence.

    This kind of infl= uence can be considered "harm" when abrupt default policy changes= (like v30's shift toward permissive data carrying) disrupt "stand= ard" network practices and its users.

    However, the v30 release = itself may have caused a point of no return, where "globally agreed st= andardness" is no longer a realistic expectation. Bitcoin's hidden= limits are being revealed.

    Proposal:

    To address human= s' flaws, I suggest reorganizing the repository structure to better saf= eguard against unwarranted political (policy) influence.

    1. Renam= e and Refocus Core Repo:

    =C2=A0 =C2=A0 Rename (github.com= /)bitcoin/bitcoin to bitcoin/bitcoin-core. This repo would focus mainly= on consensus rules, removing arbitrary or non-critical policies from its s= cope. It becomes a neutral base for ALL node implementations, emphasizing o= n hardening and testing consensus without policy distractions.

    2.= Introduce Node Client Repo(s):

    =C2=A0 =C2=A0 Create a separate = repository for the full-featured node client, starting with (gi= thub.com/)bitcoin/bitcoin-node as the foundational template. This would= effectively serve as the direct replacement for the current bitcoin/bitcoi= n node software. This repository embeds the consensus-focused bitcoin-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-<type> existing in parallel, best addressing default-= bias concerns.)


    The initial implementation= of this separation might not be elegant, but future releases can progressi= vely refactor based on this new reorganization, potentially incorporating m= ore modularity (where beneficial).

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

    (But S= TILL 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 feel= s "forced to comply", and represents a more neutral position from= the "Official Reference Implementation" repository in this new e= ra.

    Benefits:
    • Bitcoin-Core reaches its epitome, fo= cusing 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 prin= ciples.

    Drawbacks:
    • Breaks existing infrastru= cture tied to github.com/bitcoin/bitcoin. However, bitcoin/bitcoi= n-node is a 1-to-1 replacement, mitigating deep disruptions (which some wil= l 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 o= riginal github.com/bitcoin/bitcoin name for anything else, as tha= t would break automatic GitHub url redirects.

    =
    Thank you for your time. This is just an idea I wanted to share f= or 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+...@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.com/= d/msgid/bitcoindev/CADNMaA4vWnDMoPOc%2B7tUOnYap%2BPLxnj2HS0rMz0Ecd11OQwxJQ%= 40mail.gmail.com.
--000000000000d19bde0642a2a88a--