path: root/ed/54287c692fe8963a0e5777b5e5d3b7d74e173f

Delivery-date: Tue, 17 Jun 2025 15:36:53 -0700
Received: from mail-yw1-f185.google.com ([209.85.128.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCFYFP77VQJRB6W3Y7BAMGQEM5WO47Y@googlegroups.com>)
	id 1uRevD-0005P6-CA
	for bitcoindev@gnusha.org; Tue, 17 Jun 2025 15:36:52 -0700
Received: by mail-yw1-f185.google.com with SMTP id 00721157ae682-70e5e6ab756sf88531027b3.2
        for <bitcoindev@gnusha.org>; Tue, 17 Jun 2025 15:36:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750199805; x=1750804605; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=4Bu/x1aOetPm2IF7HqpnJJNyNYrHU9dN2Fv90SSIhN8=;
        b=MkY6MRrzosscBV6Y/JW65RPS30zYXQ3ovr8p+/oyUYrXHYkOfitZM/ypJw20K4TCvs
         oA4nt/CsuYA7Jt0CvkdCUruuntljJKBqauNi6Fkmk6xhnFyQzH84vhxdEYtP/fi0Kjs9
         HU+pO7fe5QRWP2TnRmbQ6EQfNsY9CZenQfFRJV2bdunOtIdENrAHaJqLxtHc1e+RuVAy
         Oqsr8IFnkxQVBvg8HQKFWI5rtD4ZO0MNJ8O9hKTjRRwWpSKd8trWDIvyK89E9nm+Snin
         oHDfV4wcAgmg3w6wDb+0o1Q84gXGT6MsspFXiaAIQ9ETQSHISfqj9LL6Z2GvEnOBed9W
         hnrg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750199805; x=1750804605; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4Bu/x1aOetPm2IF7HqpnJJNyNYrHU9dN2Fv90SSIhN8=;
        b=hIQTbWoRl7BqSuRhYjHaIObsGiqIinAFEA0GTphfxNLiOCAvTME8i7cSGkv0a/GCXi
         lhuhhF2y/cdGfYPrnNOzG/++NqmYwBhxWZAfYCtP/G+DGRR8jfBRK4lb/V3OwjQ0vCyc
         3QrNfV2FpdQzmUYEqF2q3Ow9qNWVX8+xMLoTXBesHACpL/Dv1dCfw6DAPJ4kXCq/Yj3+
         XdIwUJSBMzq04523A06/jrGGleRct3L56Ax5pdhfw/jciymV/fqmojnZVgeVl7UwF+Ck
         b+deDwZLXnqmCcCUvtBdDsUsqTQ428OPbvWydB6TdKbZpUkD5FIH1YMgr1Fm3azpJn/w
         aEyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750199805; x=1750804605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=4Bu/x1aOetPm2IF7HqpnJJNyNYrHU9dN2Fv90SSIhN8=;
        b=K4IyzaU1tLWCQ0/bT4NjKfKjVK9/ik4b+bEjuAnI5OrMuo6AmV6zR1bZ36e6xLAcl3
         GZhqin7V6LELiDOroSYZ0kDJu9bB9JiyYccz5Faj5WpoXyfHGbVYeaApidVjFu3DW1Yq
         hfjyZnHU36f+KiouzWkwCBA7pTLgAkFsQwUuyRavXDbR5qCZlMnh82UFL9RsS4a+pzb0
         rFfs6KKeKG4SDJZIQ5Vx3BFkEpGICEsHdVriTgo5mIimofXdb0ptjNMXQntJDRVPUlBp
         rcdx5fzhmpzyy/ZhVQijGiJj/Zn5cPMg2G/LbaplFDvgk+6EGIkcjYueLvWcBm/IEkJK
         EGAA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCU5rbhjg+G0+LvIyXB49BpvPS3PxtGoACMPI0QUFGu0luhB6x9mp9QIs6o6wuPO1xB2DnfxPHMdKvJN@gnusha.org
X-Gm-Message-State: AOJu0YzqwdKAsvFI/M8M6uZA6bq/UprTflBbsucLlzGIkL2PnWvei7r5
	LTQDz+MrAPYefARh1QYPlcBEPfBRXDq1ScnxRBmIt6WAATGdMZLdsElO
X-Google-Smtp-Source: AGHT+IHk6dcpT2E3Ny2ngjABgYYR7l+AGrb2/H6TUzKHXRZIigv0Mzdj2x+z2Wx7l7I4TQWB20sH8g==
X-Received: by 2002:a05:6902:a06:b0:e81:9939:99f8 with SMTP id 3f1490d57ef6-e822abf732dmr19411746276.17.1750199805273;
        Tue, 17 Jun 2025 15:36:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcySMlkP6IrpdYIpSvMq3z0pFb7ozFVECnk/BcB4ryd3g==
Received: by 2002:a05:6902:6c12:b0:e82:5194:7ab7 with SMTP id
 3f1490d57ef6-e8251947ff2ls2613617276.0.-pod-prod-02-us; Tue, 17 Jun 2025
 15:36:41 -0700 (PDT)
X-Received: by 2002:a05:690c:6084:b0:711:457a:402b with SMTP id 00721157ae682-71175489f90mr231677397b3.32.1750199801574;
        Tue, 17 Jun 2025 15:36:41 -0700 (PDT)
Received: by 2002:a05:690c:3246:b0:710:fccf:6901 with SMTP id 00721157ae682-71162d3ec86ms7b3;
        Tue, 17 Jun 2025 01:30:46 -0700 (PDT)
X-Received: by 2002:a05:690c:7248:b0:70e:86a:ae1e with SMTP id 00721157ae682-71175448c6fmr161674777b3.22.1750149044907;
        Tue, 17 Jun 2025 01:30:44 -0700 (PDT)
Date: Tue, 17 Jun 2025 01:30:44 -0700 (PDT)
From: TheCharlatan <seb.kung@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com>
In-Reply-To: <CABaSBaxYfpKXb_P0y=Va=d8nbKO2H_T6_qGBzs1DvksLES3oSA@mail.gmail.com>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
 <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.com>
 <CABaSBaxYfpKXb_P0y=Va=d8nbKO2H_T6_qGBzs1DvksLES3oSA@mail.gmail.com>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_489426_2059466519.1750149044361"
X-Original-Sender: seb.kung@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_489426_2059466519.1750149044361
Content-Type: multipart/alternative; 
	boundary="----=_Part_489427_253654077.1750149044361"

------=_Part_489427_253654077.1750149044361
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I kind of hate that my first email to the list is commenting on a meta=20
issue. My impression is that the concerns raised here are overblown.

The question around how to handle data embedding and meta protocols through=
=20
policy has been a major discussion point on the repository for more than a=
=20
decade. Even with a clear majority of regular contributors agreeing, a=20
decision on the topic was always going to arouse major controversy. The=20
perceived brigading did not impede the project from making progress on the=
=20
issue. It led to a rare moment of alignment in the form of a common=20
statement, brought more eyes to reviewing the pull requests, and finally=20
led to a resolution of the question. The discussion was also focused on the=
=20
two pull requests, and did not impede progress on the 300+ others. Contrary=
=20
to public perception, I also think moderation of the pull requests in=20
question was ok. I especially like that it was kept open by the moderators=
=20
for people to comment on, since people are clearly still confused on what=
=20
the change actually does. More importantly it also shows that our=20
organization is still the same scrappy, loose collective of individuals=20
with individual approaches and opinions capable of tolerating dissent. If I=
=20
were to choose a client to run my money on, these are all soft qualities=20
I'd look out for.

On the topic of giving people a platform for spreading lies through a=20
public issue tracker and review mechanism, regular posting on social media=
=20
seems way more effective at this. Soliciting public feedback from users=20
during pull request review is very useful. If somebody tries out the new=20
API I am working on, I'd like their feedback to be visible and easily=20
submitted.
On Tuesday, 17 June 2025 at 00:06:58 UTC+2 Bryan Bishop wrote:

> Hi,
>
> On Sat, Jun 14, 2025 at 1:29=E2=80=AFPM Antoine Poinsot <daro...@protonma=
il.com>=20
> wrote:
>
>> I started reading by speculating you were defending the case for=20
>> something akin to a "source-available" Bitcoin Core. [... ]However you a=
re=20
>> not making the case for this, but for a private Bitcoin Core repository=
=20
>> with a public mirror.
>>
>
> I will not claim I am an eloquent writer. In fact, Adam Back rightly=20
> points out that some of my phrasing is deeply dumb: in one paragraph I=20
> started off a chain of ORs of alternatives that began with publishing cut=
=20
> releases instead of every incremental commit. I didn't mean to suggest=20
> Bitcoin Core should only publish cut releases, only that it was an option=
=20
> that could be supported by social coding tools. It was followed by a chai=
n=20
> of "ORs" of alternatives, and overall I could have worded that paragraph=
=20
> better. Oops.
> =20
>
>> The public mirror would have comment threads on pull requests originatin=
g=20
>> from the private repository and the possibility to open issues. It would=
=20
>> essentially enable developer to opt into engaging on public comment thre=
ads=20
>> (for bug reports, contentious pull requests if they see fit, etc..) whil=
e=20
>> always having the possibility to retreat in the private repository to=20
>> focus. This does sound more appealing to me, although it raises question=
=20
>> with regard to its feasibility and the churn it could introduce (could t=
he=20
>> public mirror insert public comments within the synced private thread? o=
r=20
>> would it have to duplicate every single thread?).
>>
>
> All kinds of arrangements are possible, including bi-directional=20
> synchronization, or one-way synchronization and pingbacks with "review"=
=20
> before posting synced content internally, ... or many other options. It's=
=20
> up to the developers using the tools to decide if they find them useful. =
It=20
> could be beneficial for a variety of different private development tools =
to=20
> exist and be tried by different devs. There likely isn't one workflow tha=
t=20
> works best for everyone, instead a bunch of differentiated preferences or=
=20
> ways about getting their work done.
> =20
>
>> You touch on the office culture and the need for a platform that would b=
e=20
>> a better sweet spot between unmoderated public discussions and entirely=
=20
>> private discussions happening in the confines of a Bitcoin developer=20
>> organization's offices. However it's unclear that what drives a lot of=
=20
>> discussions to happen in offices is the occasional disruption of online=
=20
>> fora, rather than just the natural advantages of in-person discussions.
>>
>
> I don't know how to reply to this. I thought I had brought up offices as=
=20
> an example of existing private development efforts that already exist and=
=20
> are already more private than an online members-only social coding tool. =
To=20
> the extent that "private development is bad" is a motivation to not do th=
e=20
> things I have suggested, then I wanted to point to offices as a trend tha=
t=20
> already exists and highlight how members-only open source software=20
> development is a better option for some of us and somewhat disproves=20
> "private development is bad" is a blocking concern that e.g. somehow=20
> prohibits private development. It doesn't.
> =20
>
>> You also state that brigading would be severely reduced and eliminated.=
=20
>> However it seems contrary to having publicly available comment threads? =
It=20
>> would just contain the brigading to the publicly available comment threa=
ds.=20
>> You could make the point that this containment would disincentivize the=
=20
>> brigading in the first place, but it would only be the case if there is =
no=20
>> expectation that the low-quality comments be taken into account in the=
=20
>> decision making.
>>
>
> Great point. I should have said that brigadier intrusions into developer=
=20
> spaces would be reduced or eliminated, not that all bitcoin-related=20
> brigading on the Internet for all time would be eliminated, which is well=
=20
> outside of my powers to enact or promise.
> =20
>
>> I agree with your problem statement. I believe there is a dangerous=20
>> perception that the Bitcoin Core Github repository somehow controls Bitc=
oin=20
>> and is worthy of political pressure. And this is not only the case of th=
e=20
>> filter enjoyers, this misperception is also used for example to justify=
=20
>> legal threats[^0] against developers. It is important to push back again=
st=20
>> this confusion,
>>
>
> I have toyed around with the idea of proposing changes to Bitcoin Core's=
=20
> github repository to minimize the perception of prestige. I don't have a=
=20
> great suggestion at the moment so I haven't posted publicly on this. I'm=
=20
> also not sure if lowering perceived prestige is the right thing to do or =
if=20
> that would be beneficial to bitcoin, Bitcoin Core, users of Bitcoin Core,=
=20
> or its developers. For example, what if Bitcoin Core started merging rand=
om=20
> ads and spam into the README?
> =20
>
>> We just need to face the fact that Bitcoin Core is a centralized project=
.=20
>> It has a central website, releases binaries and updates its software bas=
ed=20
>> on rough technical consensus. Bitcoin is decentralized, Bitcoin Core is =
not.
>>
>
> There are some aspects of Bitcoin Core that are centralized, such as the=
=20
> domain name registration, or the GitHub org, where unambiguously some=20
> specific people have control of a project resource. Many other project=20
> resources including a great number of volunteers freely allocate their ti=
me=20
> and resources to help write and review code, propose changes, or otherwis=
e=20
> move the project forward with minimal coordination and no central control=
=20
> over those people. Arguably a lot of the value of Bitcoin Core is from=20
> those contributors.
>
> To the extent that Bitcoin Core is centralized, then bitcoiners ought to=
=20
> be thoughtful about the ways in which it is centralized (or not) and the=
=20
> design goals should be the result of careful strategy or thinking.=20
> Strengthening the decentralized aspects, or increasing decentralized=20
> aspects, of the Bitcoin Core project may be prudent, depending on the=20
> design goals. Based on other replies in this thread it may be possible to=
=20
> achieve exclusive developer spaces by increasing decentralization for=20
> Bitcoin Core with systems like Radicle or other social coding tools. I=20
> guess depending on how you squint some might call that increasing the=20
> centralization (proliferation of independent but private collaboration=20
> spaces) or others might call it decentralization (anyone can fork/mirror=
=20
> write-privately spaces). And this might even help people avoid incorrectl=
y=20
> seeing Bitcoin Core's centralized aspects as Bitcoin being centralized.
> =20
>
>> Setting expectations that misinformed rants and conspiracy theories will=
=20
>> be considered at all in deciding whether code should be changed is entir=
ely=20
>> self-inflicted and does not need a change in the project structure to=20
>> correct.
>>
>
>
>
> - Bryan
> https://x.com/kanzure
>

--=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/=
58813483-7351-487e-8f7f-82fb18a4c808n%40googlegroups.com.

------=_Part_489427_253654077.1750149044361
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I kind of hate that my first email to the list is commenting on a meta issu=
e. My impression is that the concerns raised here are overblown.<br /><br /=
>The question around how to handle data embedding and meta protocols throug=
h policy has been a major discussion point on the repository for more than =
a decade. Even with a clear majority of regular contributors agreeing, a de=
cision on the topic was always going to arouse major controversy. The perce=
ived brigading did not impede the project from making progress on the issue=
. It led to a rare moment of alignment in the form of a common statement, b=
rought more eyes to reviewing the pull requests, and finally led to a resol=
ution of the question. The discussion was also focused on the two pull requ=
ests, and did not impede progress on the 300+ others. Contrary to public pe=
rception, I also think moderation of the pull requests in question was ok. =
I especially like that it was kept open by the moderators for people to com=
ment on, since people are clearly still confused on what the change actuall=
y does. More importantly it also shows that our organization is still the s=
ame scrappy, loose collective of individuals with individual approaches and=
 opinions capable of tolerating dissent. If I were to choose a client to ru=
n my money on, these are all soft qualities I'd look out for.<br /><br />On=
 the topic of giving people a platform for spreading lies through a public =
issue tracker and review mechanism, regular posting on social media seems w=
ay more effective at this. Soliciting public feedback from users during pul=
l request review is very useful. If somebody tries out the new API I am wor=
king on, I'd like their feedback to be visible and easily submitted.<div cl=
ass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, 17 J=
une 2025 at 00:06:58 UTC+2 Bryan Bishop wrote:<br/></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>Hi,</div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 14,=
 2025 at 1:29=E2=80=AFPM Antoine Poinsot &lt;<a href data-email-masked rel=
=3D"nofollow">daro...@protonmail.com</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif=
;font-size:14px">I started reading by speculating you were defending the ca=
se for something akin to a &quot;source-available&quot; Bitcoin Core. [... =
]However you are not making the case for this, but for a private Bitcoin Co=
re repository with a public mirror.</div></blockquote><div><br></div><div>I=
 will not claim I am an eloquent writer. In fact, Adam Back rightly points =
out that some of my phrasing is deeply dumb: in one paragraph I started off=
 a chain of ORs of alternatives that began with publishing cut releases ins=
tead of every incremental commit. I didn&#39;t mean to suggest Bitcoin Core=
 should only publish cut releases, only that it was an option that could be=
 supported by social coding tools. It was followed by a chain of &quot;ORs&=
quot; of alternatives, and overall I could have worded that paragraph bette=
r. Oops.</div></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D=
"font-family:Arial,sans-serif;font-size:14px"> The public mirror would have=
 comment threads on pull requests originating from the private repository a=
nd the possibility to open issues. It would essentially enable developer to=
 opt into engaging on public comment threads (for bug reports, contentious =
pull requests if they see fit, etc..) while always having the possibility t=
o retreat in the private repository to focus. This does sound more appealin=
g to me, although it raises question with regard to its feasibility and the=
 churn it could introduce (could the public mirror insert public comments w=
ithin the synced private thread? or would it have to duplicate every single=
 thread?).</div></blockquote><div><br></div></div></div><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div>All kinds of arrangements are possible, inclu=
ding bi-directional synchronization, or one-way synchronization and pingbac=
ks with &quot;review&quot; before posting synced content internally, ... or=
 many other options. It&#39;s up to the developers using the tools to decid=
e if they find them useful. It could be beneficial for a variety of differe=
nt private development tools to exist and be tried by different devs. There=
 likely isn&#39;t one workflow that works best for everyone, instead a bunc=
h of differentiated preferences or ways about getting their work done.</div=
></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:=
Arial,sans-serif;font-size:14px">You touch on the office culture and the ne=
ed for a platform that would be a better sweet spot between unmoderated pub=
lic discussions and entirely private discussions happening in the confines =
of a Bitcoin developer organization&#39;s offices. However it&#39;s unclear=
 that what drives a lot of discussions to happen in offices is the occasion=
al disruption of online fora, rather than just the natural advantages of in=
-person discussions.</div></blockquote><div><br></div></div></div><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div>I don&#39;t know how to reply to t=
his. I thought I had brought up offices as an example of existing private d=
evelopment efforts that already exist and are already more private than an =
online members-only social coding tool. To the extent that &quot;private de=
velopment is bad&quot; is a motivation to not do the things I have suggeste=
d, then I wanted to point to offices as a trend that already exists and hig=
hlight how members-only open source software development is a better option=
 for some of us and somewhat disproves &quot;private development is bad&quo=
t; is a blocking concern that e.g. somehow prohibits private development. I=
t doesn&#39;t.</div></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div st=
yle=3D"font-family:Arial,sans-serif;font-size:14px"></div><div style=3D"fon=
t-family:Arial,sans-serif;font-size:14px">You also state that b<span>rigadi=
ng would be severely reduced and eliminated</span>. However it seems contra=
ry to having publicly available comment threads? It would just contain the =
brigading to the publicly available comment threads. You could make the poi=
nt that this containment would disincentivize the brigading in the first pl=
ace, but it would only be the case if there is no expectation that the low-=
quality comments be taken into account in the decision making.</div></block=
quote><div><br></div></div></div><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div>Great point. I should have said that brigadier intrusions into devel=
oper spaces would be reduced or eliminated, not that all bitcoin-related br=
igading on the Internet for all time would be eliminated, which is well out=
side of my powers to enact or promise.</div></div></div><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"=
>I agree with your problem statement. I believe there is a dangerous percep=
tion that the Bitcoin Core Github repository somehow controls Bitcoin and i=
s worthy of political pressure. And this is not only the case of the filter=
 enjoyers, this misperception is also used for example to justify legal thr=
eats[^0] against developers. It is important to push back against this conf=
usion,</div></blockquote><div><br></div></div></div><div dir=3D"ltr"><div c=
lass=3D"gmail_quote"><div>I have toyed around with the idea of proposing ch=
anges to Bitcoin Core&#39;s github repository to minimize the perception of=
 prestige. I don&#39;t have a great suggestion at the moment so I haven&#39=
;t posted publicly on this. I&#39;m also not sure if lowering perceived pre=
stige is the right thing to do or if that would be beneficial to bitcoin, B=
itcoin Core, users of Bitcoin Core, or its developers. For example, what if=
 Bitcoin Core started merging random ads and spam into the README?</div></d=
iv></div><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px">We just need to face the fact that Bitcoin Cor=
e is a centralized project. It has a central website, releases binaries and=
 updates its software based on rough technical consensus. Bitcoin is decent=
ralized, Bitcoin Core is not.</div></blockquote><div><br></div></div></div>=
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>There are some aspects of =
Bitcoin Core that are centralized, such as the domain name registration, or=
 the GitHub org, where unambiguously some specific people have control of a=
 project resource. Many other project resources including a great number of=
 volunteers freely allocate their time and resources to help write and revi=
ew code, propose changes, or otherwise move the project forward with minima=
l coordination and no central control over those people. Arguably a lot of =
the value of Bitcoin Core is from those contributors.<br><br>To the extent =
that Bitcoin Core is centralized, then bitcoiners ought to be thoughtful ab=
out the ways in which it is centralized (or not) and the design goals shoul=
d be the result of careful strategy or thinking. Strengthening the decentra=
lized aspects, or increasing decentralized aspects, of the Bitcoin Core pro=
ject may be prudent, depending on the design goals. Based on other replies =
in this thread it may be possible to achieve exclusive developer spaces by =
increasing decentralization for Bitcoin Core with systems like Radicle or o=
ther social coding tools. I guess depending on how you squint some might ca=
ll that increasing the centralization (proliferation of independent but pri=
vate collaboration spaces) or others might call it decentralization (anyone=
 can fork/mirror write-privately spaces). And this might even help people a=
void incorrectly seeing Bitcoin Core&#39;s centralized aspects as Bitcoin b=
eing centralized.</div></div></div><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px"> Setting expectation=
s that misinformed rants and conspiracy theories will be considered at all =
in deciding whether code should be changed is entirely self-inflicted and d=
oes not need a change in the project structure to correct.</div></blockquot=
e><div><br></div><div><br></div><div><br></div></div></div><div dir=3D"ltr"=
><div class=3D"gmail_quote"></div><div dir=3D"ltr" class=3D"gmail_signature=
"><div dir=3D"ltr">- Bryan<br><a href=3D"https://x.com/kanzure" target=3D"_=
blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Den-GB&amp;q=3Dhttps://x.com/kanzure&amp;source=3Dgmail&amp;ust=3D17502=
31479440000&amp;usg=3DAOvVaw1yl_Ct2bQ3QVzgXeAHsORZ">https://x.com/kanzure</=
a></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/58813483-7351-487e-8f7f-82fb18a4c808n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/58813483-7351-487e-8f7f-82fb18a4c808n%40googlegroups.com</a>.<br />

------=_Part_489427_253654077.1750149044361--

------=_Part_489426_2059466519.1750149044361--