From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <58813483-7351-487e-8f7f-82fb18a4c808n@googlegroups.com> In-Reply-To: References: <4iW61M7NCP-gPHoQZKi8ZrSa2U6oSjziG5JbZt3HKC_Ook_Nwm1PchKguOXZ235xaDlhg35nY8Zn7g1siy3IADHvSHyCcgTHrJorMKcDzZg=@protonmail.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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 =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.

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.

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.
On Tuesday, 17 J= une 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...@protonmail.com> wrote:
I started reading by speculating you were defending the ca= se for something akin to a "source-available" Bitcoin Core. [... = ]However you are not making the case for this, but for a private Bitcoin Co= re repository with a public mirror.

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'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 "ORs&= quot; of alternatives, and overall I could have worded that paragraph bette= r. Oops.
= =C2=A0
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?).

All kinds of arrangements are possible, inclu= ding bi-directional synchronization, or one-way synchronization and pingbac= ks with "review" before posting synced content internally, ... or= many other options. It'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't one workflow that works best for everyone, instead a bunc= h of differentiated preferences or ways about getting their work done.
=C2=A0
<= 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">
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's offices. However it'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.

I don'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 "private de= velopment is bad" 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 "private development is bad&quo= t; is a blocking concern that e.g. somehow prohibits private development. I= t doesn't.
=C2=A0
You also state that brigadi= ng would be severely reduced and eliminated. 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.

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.
=C2=A0
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,

I have toyed around with the idea of proposing ch= anges to Bitcoin Core's github repository to minimize the perception of= prestige. I don't have a great suggestion at the moment so I haven'= ;t posted publicly on this. I'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?
=C2=A0
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.

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

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's centralized aspects as Bitcoin b= eing centralized.
=C2=A0
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.



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