path: root/ee/6ec65f7ef93050352a7e1f79ae3e8a5ef112ec

Delivery-date: Mon, 16 Jun 2025 09:56:49 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDI23FE35EIBBREZYHBAMGQE33QI23Y@googlegroups.com>)
	id 1uRD8Y-0008PL-QA
	for bitcoindev@gnusha.org; Mon, 16 Jun 2025 09:56:49 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e819aa98d59sf5736296276.2
        for <bitcoindev@gnusha.org>; Mon, 16 Jun 2025 09:56:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750093001; x=1750697801; 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=GXjsQCZdBetYCYmzaCF+MB7vRgcLzE5hOe828w5oz0I=;
        b=jz3wHaHIROrkWwHR0cNvcw/Qoz/0Xs6ncAsJEtyHquM3G6FMh+e9KRLAeQGLNcBFOo
         RecyszAjX94Te3TyP8S3zVmVzKxuXNaTMSFfgz6/qdOeskyJUfYjqgvby5MGLQI+z19f
         1fwQNVqLQv1EA4VlJdk8D2X2YJmbkC2KIVwF+tPN8rWS4LSCj9P7vsrlcZOhXVBt4RQ7
         bCNG76cG1bhHVvbc3915z9PWHBLC0ooLiLup9svL3FNGjuyFWkqlhosHpAqjHkvIpXyc
         HkGbhBZ+F0zolrQUWBPh4Pxr81Qq69+OReMShG4vmcvg3FFOMeUyABwViAlGXV7xvgxl
         znNQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750093001; x=1750697801; 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=GXjsQCZdBetYCYmzaCF+MB7vRgcLzE5hOe828w5oz0I=;
        b=S4fUkzLmfgQCfc83XaDPDG4FCxMnGOXJCrjr8/k9zvhqhathaWlYKzncsuyqYAaKQp
         XhRZGUTZnBi5RCS7BfrSmB+zXbvO3QNAKy5kL4rBMKNU4NcKAY1IhWL7Rw8t/EZx6lwX
         gwB55KQ1FIWBs261yQ7roFRKMcUJB4VZ4IzPFO3HtK0QArwyIFFinaknzUJAbI1A0x1g
         imVSPTO9V1lYK/Md64lFWxF/wuJevUvWb3Bk/UneEAWq2C2Q7iKWW1D+tXyMSJadhlWn
         DwxJekrz/rekA9QpwQOHe6uwlY6ZjoeuNEmptKcOcXyGKMGEqMxJBNaq2AxOEd3HvvHf
         +VVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750093001; x=1750697801;
        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=GXjsQCZdBetYCYmzaCF+MB7vRgcLzE5hOe828w5oz0I=;
        b=DrBAB4rwnBHvm6dWefDrWDtkSo6MnpCuVO24Gcpb+QCB6GCJk2+K8fkwc0X2Nhe7xH
         347sYom4W8u4dFa+2PKA0w94M+tGneMBc/2PSr7RznWPKYnzZJtQnv7yeshkO6FQ3LQo
         vdn7c6WRfYrhvhttOwda3FYaSHS4ST3jgd88D+cOe2BtJsJ3q1TUn6iH+5NyRqDG+ElF
         d8bcIQ7Mzm0I8AON9G2Y4wyKcW0vrtJVxXINKDx0j6oRbP9oVevJBiw+DgrKlPeRSKr4
         EutMlTUTo/Iuzg3T+O/T3y/DuO1j/CUXe2XaafvAaXDTrUq1hK+eCIM+6IZQKmWFuaHP
         OQyQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXdd42kVZKj2QFugw0vo8hsGJAHVr91iGmu2+wUpwATkspRXCENF+vciAIVkPQUpCPxzh6qtAP8/2+4@gnusha.org
X-Gm-Message-State: AOJu0YyJtwfp3xDLbbzPVglexV4XMRyd/ew98L60pPjBURpSkUsvSSig
	u0U/swKhfVgyeJ5vAn/Ip8igvneZEDC0vhsD7LFdi0D8y+9uArwROwsE
X-Google-Smtp-Source: AGHT+IH14V7azya298R6+wm6rhrd52UL9s2v93hTmdOMIKGHZDdorB4blDQodCZgDMN1DmZ2f1JILg==
X-Received: by 2002:a05:6902:2113:b0:e81:f2c1:6292 with SMTP id 3f1490d57ef6-e822acc6e44mr14291231276.18.1750093000787;
        Mon, 16 Jun 2025 09:56:40 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfthsdtx1m2p05vYoNFw2lQSZyQEdRTgSBS1w416OWULA==
Received: by 2002:a25:26ce:0:b0:e82:21c7:67f7 with SMTP id 3f1490d57ef6-e8221c76938ls2639675276.0.-pod-prod-07-us;
 Mon, 16 Jun 2025 09:56:36 -0700 (PDT)
X-Received: by 2002:a05:690c:9a07:b0:709:176d:2b5 with SMTP id 00721157ae682-7117537b336mr152122777b3.2.1750092996387;
        Mon, 16 Jun 2025 09:56:36 -0700 (PDT)
Received: by 2002:a05:690c:3149:b0:711:63b1:720 with SMTP id 00721157ae682-71163b129c5ms7b3;
        Mon, 16 Jun 2025 09:53:40 -0700 (PDT)
X-Received: by 2002:a05:690c:7481:b0:70e:b08:7209 with SMTP id 00721157ae682-7117539407bmr141098707b3.10.1750092818992;
        Mon, 16 Jun 2025 09:53:38 -0700 (PDT)
Date: Mon, 16 Jun 2025 09:53:38 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <447c065f-aa73-463c-aa1c-60340850d24an@googlegroups.com>
In-Reply-To: <4ad72033-dac1-4a4d-a432-1cc525f92e6dn@googlegroups.com>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
 <aE7xTUoUrPkNtDql@mail.wpsoftware.net>
 <4ad72033-dac1-4a4d-a432-1cc525f92e6dn@googlegroups.com>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_480128_1596192211.1750092818631"
X-Original-Sender: ekaggata@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_480128_1596192211.1750092818631
Content-Type: multipart/alternative; 
	boundary="----=_Part_480129_1043521683.1750092818631"

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

Bryan,

If I'm honest, I realize that my commentary here was flawed in at least two=
=20
ways:

> However, my intuition is that manual, vigorous disciplined moderation=20
like that is difficult to execute especially across many people

1/ as you correctly picked up on here, an "extremely rigorous moderation=20
policy on PRs" as i was advocating sounds nice, but in what world can that=
=20
actually be done? the difficulty of turning that abstract idea into reality=
=20
might be related to point 2/ :

re:
 > Nobody can stop such discussion forums from being created anywhere on=20
the Internet.

2/ with regard to a separate forum, mailing list (perhaps like this one)=20
etc. I again may have glossed over the most difficult real point: what=20
represents a consequential conclusion to a discussion, even if such a forum=
=20
were perfectly set up? The energy around github is IMO mostly from the=20
natural (partly correct?) interpretation that github is mostly where the=20
final decision gets made on inclusion of features into bitcoin-the-software=
=20
*AND* bitcoin-the-protocol, even if obviously the latter, if we're talking=
=20
consensus is a really non-trivial deal and in no way is it just a matter of=
=20
counting ACKs on a PR. The unpleasantly difficult-to-answer question of how=
=20
(and where) decisions get made is what's causing this.

> I don't see my original goal as "avoid conflict". It was about creating=
=20
an online space exclusively for bitcoin developers that want to work=20
together on bitcoin development. I posit that even with such an exclusive=
=20
space, and even if it had higher adoption than the current private=20
development efforts, that there would still be various online fora with=20
various people of all kinds (angry, confused, informed, etc), or even=20
cool-headed non-confused people that developers simply don't have time or=
=20
interest to individually read-- or maybe they would; who knows! But it's=20
separate from having a place for bitcoin development.

Good point. What I'm trying to get at is that if you just cleanly separate=
=20
the two things, with no conscious, or perhaps even existent, communication=
=20
from one (the fora) in to the other (the dev process), then nobody will=20
care about the former (as today probably nobody cares about opinions on=20
*many* bitcoin fora), which means nobody strongly motivated, will use them.=
=20
I think it'll depend on some sense of decisions not being exclusively made=
=20
on github or via private discussion, into the repository. I'm not sure your=
=20
idea of a private repo is wrong, I see where you come from, but I fear it=
=20
will exacerbate a pre-existing growing perception of "Bitcoin Core" as a=20
distinct entity with its own policy approach (and even politics, though=20
that is a false perception). Can I express for the 100th time my severe=20
regret that the name "Bitcoin Core" for the Satoshi client was adopted?=20
(Side note: does anyone actually think it was good that it got renamed to=
=20
"Bitcoin Core" because I haven't met any such person, lol).

I don't have any easy solutions to "how the decisions get made", of course,=
=20
which is the root cause of the problem, and inflammatory communications are=
=20
related mainly to that (even worse, I am leery of people trying to fully=20
solve it!). If making the environment tolerable and workable for people=20
doing the actual engineering work is possible without completely solving=20
that, then that is a very valid goal. But enough windbaggery from me, I=20
should leave the discussion from here on to people with some actual skin in=
=20
the game!

Cheers, AdamISZ/waxwing

On Monday, June 16, 2025 at 12:28:16=E2=80=AFPM UTC-3 waxwing/ AdamISZ wrot=
e:

> My personal opinion is that the best solution is to create a very strong=
=20
> ruleset on disallowing any non-technical contribution on github, and=20
> applying that rule rigorously no matter whether the content *feels*=20
> acceptable or not, and no matter how well respected the contributor is an=
d=20
> might rightfully be given some slack. This would be for PRs; for Issues, =
I=20
> don't know how much of a similar problem you have, but templates aren't b=
ad=20
> I guess.
>
> Such extreme discipline is only needed in that repo, virtually no other=
=20
> repo needs it.
>
> I also do realize this could end up a bit of a weak-sauce suggestion=20
> compared to others in this thread (I quite like Andrew's suggestion but,=
=20
> not sure it's exactly the right one).
>
> This would have to be accompanied by a very strong cohesion around what=
=20
> *is* the correct forum for technically-adjacent bitcoin policy discussion=
=20
> (as just one example, advocating for or against soft forks goes in this=
=20
> bucket), and also tonally to *encourage* such discussion; that=20
> encouragement would have to be broadcast from the github repo itself,=20
> certainly in messages to people whose discussion contribution is blocked.=
=20
> Obviously it would have to be noted elsewhere too like the main=20
> distribution website for the software.
>
> Unfortunately I don't think this mailing list *quite* fits the job, thoug=
h=20
> it's close ... on the other hand, where else? If this list is manually=20
> moderated (as I believe it is), do we have a bitcoin-"policy" mailing lis=
t=20
> or other channel?
>
> I think the biggest problems arise when you insist that there is *no*=20
> place for what you see as "brigading", "sock puppetry" etc. I have seen=
=20
> several times in the past (most notably around the blocksize wars) where=
=20
> many highly respected engineers dismissed all opposing opinions as sock=
=20
> puppetry. This is not realistic, nor is it healthy. If you stuff all=20
> contrary opinions (uneducated or not!) into a garbage bin that you label=
=20
> "politics" (imagine the phrase "go and discuss it on bitcoin-politics" wi=
th=20
> the tacit assumption that no one serious is ever going to read that=20
> dumpster fire), it invites the exact conflict you're trying to avoid. I=
=20
> suggest "bitcoin policy" as a general title for such things, because=20
> bitcoin does indeed have "policies" in the general sense (not just the=20
> technical meaning of "policy" in bitcoin-the-software but also consensus=
=20
> itself is a flavor of policy). If it doesn't end up being a place that=20
> serious people talk seriously, then of course it will have failed in the=
=20
> intention.
>
> Cheers,
> AdamISZ/waxwing
>
> On Sunday, June 15, 2025 at 1:30:24=E2=80=AFPM UTC-3 Andrew Poelstra wrot=
e:
>
>> I have a few thoughts about this -- bearing in mind that I am a drive-by=
=20
>> contributor to Core, at best, and don't have much personal opinion other=
=20
>> than maybe "I wish it were easier to get stuff in".=20
>>
>> 1. I think that Antoine is correct that "it's easier and more natural"=
=20
>> is a bigger motivation for "office work" than is the fear of brigade.=20
>> So one thing is that any change to public processes shouldn't make it=20
>> _harder_ for people to collaborate online, since that could push=20
>> people more to in-person fora and we'd just have the worst of both=20
>> worlds. Or at least, anyone making such a change should have a lot of=20
>> confidence that the increased friendliness to earnest contributors=20
>> would outweigh the extra friction.=20
>>
>> 2. On the other hand, fear of brigades _does_ clearly have a nonzero=20
>> chilling effect. I certainly think about it when publicly communicating=
=20
>> near the project, and I commonly bring it up when doing things in=20
>> rust-bitcoin (i.e. "fortunately, we're not Core, so we can just do=20
>> [some change that would constrain wallet workflows, or which could=20
>> make ordinals particularly hard, or particularly easy, or whatever]"=20
>> and not have to worry about fallout.)=20
>>
>> So at the very least, it's a factor that discourages some external=20
>> developers from being bigger contributors to the project.=20
>>
>> 3. And of course, it's not just obvious brigades -- when one or two=20
>> nontechnical people show up with strong political views about=20
>> something which really is not a political change (or at least,=20
>> doesn't have the political effect they believe it does, because of=20
>> their own misunderstanding), it's still discouraging and sometimes=20
>> stressful. And this happens all the time around mempool policy,=20
>> even if PRs with 100+ comments that get locked are fairly rare.=20
>>
>> 4. However, after (ironically) discussing this email off-list with a=20
>> bunch of people, I think that these problems stem from a fairly small=20
>> cultural issue: that the Github repo appears to be a totally open=20
>> forum where anyone is welcome to participate, even in code review=20
>> threads, because technically anybody _can_ participate with no=20
>> obvious sense that they're leaving X and entering somebody's=20
>> workplace.=20
>>
>> And _this_, IMHO, might be solvable by something extremely simple. It=20
>> might be sufficient to just move from Github to Gitlab or Codeberg or=20
>> something where far fewer people have accounts. It would probably be=20
>> sufficient to just find a platform where you have to register on the=20
>> Core repo somehow then wait 24 hours before you can post, with the=20
>> implication that if you're not there to contribute technically, you=20
>> might lose your access. (This is true on Github but the only=20
>> mechanism is that you can be banned from the org, something that=20
>> feels heavy and scary for maintainers to use -- I really hate doing=20
>> this to non-bots on rust-bitcoin and I don't even have to worry that=20
>> they'll go on twitter to scream censorship and that I'm taking over=20
>> Bitcoin or whatever -- and is also more-or-less invisible to users=20
>> until it happens to them, so it's not an effective deterrent.)=20
>>
>> It would certainly be effective to put a strong technical barrier,=20
>> e.g. you have to produce a custom mining share to join, or a strong=20
>> social barrier, e.g. you need personal invitations from two people.=20
>>
>> But I think such tech barriers would be unnecessary and the social=20
>> barriers wouldn't be worth the cries of censorship and centralization=20
>> that they'd inevitably (and somewhat reasonably) cause.=20
>>
>> 5. I don't see much of benefit to making the repo *unreadable* to=20
>> outsiders. It sorta prevents linking on Twitter but if we expect=20
>> there to be mirrors, people can just link to the mirrors.=20
>>
>>
>> Again, it's not my project and I don't mean to advocate for anything in=
=20
>> particular. Just trying to organize thinking on the topic a bit.=20
>>
>>
>> --=20
>> Andrew Poelstra=20
>> Director, Blockstream Research=20
>> Email: apoelstra at wpsoftware.net=20
>> Web: https://www.wpsoftware.net/andrew=20
>>
>> The sun is always shining in space=20
>> -Justin Lewis-Webster=20
>>
>>

--=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/=
447c065f-aa73-463c-aa1c-60340850d24an%40googlegroups.com.

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

<div>Bryan,</div><div><br /></div><div>If I'm honest, I realize that my com=
mentary here was flawed in at least=20
two ways:</div><div><br /></div><div>&gt; However, my intuition is that man=
ual, vigorous disciplined=20
moderation like that is difficult to execute especially across many=20
people</div><div><br /></div><div>1/ as you correctly picked up on here, an=
 "extremely rigorous moderation
 policy on PRs" as i was advocating sounds nice, but in what world can=20
that actually be done? the difficulty of turning that abstract idea into
 reality might be related to point 2/ :</div><div><br /></div><div>re:</div=
><div>=C2=A0&gt; Nobody can stop such discussion forums from being created =
anywhere=20
on the Internet.</div><div><br /></div><div>2/ with regard to a separate fo=
rum, mailing list (perhaps like this one)
 etc. I again may have glossed over the most difficult real point: what=20
represents a consequential conclusion to a discussion, even if such a=20
forum were perfectly set up? The energy around github is IMO mostly from
 the natural (partly correct?) interpretation that github is mostly=20
where the final decision gets made on inclusion of features into=20
bitcoin-the-software *AND* bitcoin-the-protocol, even if obviously the=20
latter, if we're talking consensus is a really non-trivial deal and in=20
no way is it just a matter of counting ACKs on a PR. The unpleasantly=20
difficult-to-answer question of how (and where) decisions get made is=20
what's causing this.</div><div><br /></div><div>&gt; I don't see my origina=
l goal as "avoid conflict". It was about=20
creating an online space exclusively for bitcoin developers that want to
 work together on bitcoin development. I posit that even with such an=20
exclusive space, and even if it had higher adoption than the current=20
private development efforts, that there would still be various online=20
fora with various people of all kinds (angry, confused, informed, etc),=20
or even cool-headed non-confused people that developers simply don't=20
have time or interest to individually read-- or maybe they would; who=20
knows! But it's separate from having a place for bitcoin development.</div>=
<div><br /></div><div>Good point. What I'm trying to get at is that if you =
just cleanly=20
separate the two things, with no conscious, or perhaps even existent,=20
communication from one (the fora) in to the other (the dev process),=20
then nobody will care about the former (as today probably nobody cares=20
about opinions on *many* bitcoin fora), which means nobody strongly=20
motivated, will use them. I think it'll depend on some sense of=20
decisions not being exclusively made on github or via private=20
discussion, into the repository. I'm not sure your idea of a private=20
repo is wrong, I see where you come from, but I fear it will exacerbate a
 pre-existing growing perception of "Bitcoin Core" as a distinct entity=20
with its own policy approach (and even politics, though that is a false=20
perception). Can I express for the 100th time my severe regret that the=20
name "Bitcoin Core" for the Satoshi client was adopted? (Side note: does
 anyone actually think it was good that it got renamed to "Bitcoin Core"
 because I haven't met any such person, lol).</div><div><br /></div><div>I =
don't have any easy solutions to "how the decisions get made", of=20
course, which is the root cause of the problem, and inflammatory=20
communications are related mainly to that (even worse, I am leery of=20
people trying to fully solve it!). If making the environment tolerable=20
and workable for people doing the actual engineering work is possible=20
without completely solving that, then that is a very valid goal.

But enough windbaggery from me, I should leave the discussion from here=20
on to people with some actual skin in the game!</div><div><br /></div><div>=
Cheers,
AdamISZ/waxwing</div><br /><div class=3D"gmail_quote"><div dir=3D"auto" cla=
ss=3D"gmail_attr">On Monday, June 16, 2025 at 12:28:16=E2=80=AFPM UTC-3 wax=
wing/ AdamISZ wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;"><div>My personal opinion is that the best solution is to create a v=
ery strong ruleset on disallowing any non-technical contribution on github,=
 and applying that rule rigorously no matter whether the content *feels* ac=
ceptable or not, and no matter how well respected the contributor is and mi=
ght rightfully be given some slack. This would be for PRs; for Issues, I do=
n&#39;t know how much of a similar problem you have, but templates aren&#39=
;t bad I guess.</div><div><br></div><div>Such extreme discipline is only ne=
eded in that repo, virtually no other repo needs it.</div><div><br></div><d=
iv>I also do realize this could end up a bit of a weak-sauce suggestion com=
pared to others in this thread (I quite like Andrew&#39;s suggestion but, n=
ot sure it&#39;s exactly the right one).</div><div><br></div><div>This woul=
d have to be accompanied by a very strong cohesion around what *is* the cor=
rect forum for technically-adjacent bitcoin policy discussion (as just one =
example, advocating for or against soft forks goes in this bucket), and als=
o tonally to *encourage* such discussion; that encouragement would have to =
be broadcast from the github repo itself, certainly in messages to people w=
hose discussion contribution is blocked. Obviously it would have to be note=
d elsewhere too like the main distribution website for the software.</div><=
div><br></div><div>Unfortunately I don&#39;t think this mailing list *quite=
* fits the job, though it&#39;s close ... on the other hand, where else? If=
 this list is manually moderated (as I believe it is), do we have a bitcoin=
-&quot;policy&quot; mailing list or other channel?</div><div><br></div><div=
>I think the biggest problems arise when you insist that there is *no* plac=
e for what you see as &quot;brigading&quot;, &quot;sock puppetry&quot; etc.=
 I have seen several times in the past (most notably around the blocksize w=
ars) where many highly respected engineers dismissed all opposing opinions =
as sock puppetry. This is not realistic, nor is it healthy. If you stuff al=
l contrary opinions (uneducated or not!) into a garbage bin that you label =
&quot;politics&quot; (imagine the phrase &quot;go and discuss it on bitcoin=
-politics&quot; with the tacit assumption that no one serious is ever going=
 to read that dumpster fire), it invites the exact conflict you&#39;re tryi=
ng to avoid. I suggest &quot;bitcoin policy&quot; as a general title for su=
ch things, because bitcoin does indeed have &quot;policies&quot; in the gen=
eral sense (not just the technical meaning of &quot;policy&quot; in bitcoin=
-the-software but also consensus itself is a flavor of policy). If it doesn=
&#39;t end up being a place that serious people talk seriously, then of cou=
rse it will have failed in the intention.</div><div><br></div><div>Cheers,<=
br>AdamISZ/waxwing</div><br><div class=3D"gmail_quote"><div dir=3D"auto" cl=
ass=3D"gmail_attr">On Sunday, June 15, 2025 at 1:30:24=E2=80=AFPM UTC-3 And=
rew Poelstra wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I =
have a few thoughts about this -- bearing in mind that I am a drive-by
<br>contributor to Core, at best, and don&#39;t have much personal opinion =
other
<br>than maybe &quot;I wish it were easier to get stuff in&quot;.
<br>
<br>1. I think that Antoine is correct that &quot;it&#39;s easier and more =
natural&quot;
<br>   is a bigger motivation for &quot;office work&quot; than is the fear =
of brigade.
<br>   So one thing is that any change to public processes shouldn&#39;t ma=
ke it
<br>   _harder_ for people to collaborate online, since that could push
<br>   people more to in-person fora and we&#39;d just have the worst of bo=
th
<br>   worlds. Or at least, anyone making such a change should have a lot o=
f
<br>   confidence that the increased friendliness to earnest contributors
<br>   would outweigh the extra friction.
<br>
<br>2. On the other hand, fear of brigades _does_ clearly have a nonzero
<br>   chilling effect. I certainly think about it when publicly communicat=
ing
<br>   near the project, and I commonly bring it up when doing things in
<br>   rust-bitcoin (i.e. &quot;fortunately, we&#39;re not Core, so we can =
just do
<br>   [some change that would constrain wallet workflows, or which could
<br>   make ordinals particularly hard, or particularly easy, or whatever]&=
quot;
<br>   and not have to worry about fallout.)
<br>
<br>   So at the very least, it&#39;s a factor that discourages some extern=
al
<br>   developers from being bigger contributors to the project.
<br>
<br>3. And of course, it&#39;s not just obvious brigades -- when one or two
<br>   nontechnical people show up with strong political views about
<br>   something which really is not a political change (or at least,
<br>   doesn&#39;t have the political effect they believe it does, because =
of
<br>   their own misunderstanding), it&#39;s still discouraging and sometim=
es
<br>   stressful. And this happens all the time around mempool policy,
<br>   even if PRs with 100+ comments that get locked are fairly rare.
<br>
<br>4. However, after (ironically) discussing this email off-list with a
<br>   bunch of people, I think that these problems stem from a fairly smal=
l
<br>   cultural issue: that the Github repo appears to be a totally open
<br>   forum where anyone is welcome to participate, even in code review
<br>   threads, because technically anybody _can_ participate with no
<br>   obvious sense that they&#39;re leaving X and entering somebody&#39;s
<br>   workplace.
<br>
<br>   And _this_, IMHO, might be solvable by something extremely simple. I=
t
<br>   might be sufficient to just move from Github to Gitlab or Codeberg o=
r
<br>   something where far fewer people have accounts. It would probably be
<br>   sufficient to just find a platform where you have to register on the
<br>   Core repo somehow then wait 24 hours before you can post, with the
<br>   implication that if you&#39;re not there to contribute technically, =
you
<br>   might lose your access. (This is true on Github but the only
<br>   mechanism is that you can be banned from the org, something that
<br>   feels heavy and scary for maintainers to use -- I really hate doing
<br>   this to non-bots on rust-bitcoin and I don&#39;t even have to worry =
that
<br>   they&#39;ll go on twitter to scream censorship and that I&#39;m taki=
ng over
<br>   Bitcoin or whatever -- and is also more-or-less invisible to users
<br>   until it happens to them, so it&#39;s not an effective deterrent.)
<br>
<br>   It would certainly be effective to put a strong technical barrier,
<br>   e.g. you have to produce a custom mining share to join, or a strong
<br>   social barrier, e.g. you need personal invitations from two people.
<br>
<br>   But I think such tech barriers would be unnecessary and the social
<br>   barriers wouldn&#39;t be worth the cries of censorship and centraliz=
ation
<br>   that they&#39;d inevitably (and somewhat reasonably) cause.
<br>
<br>5. I don&#39;t see much of benefit to making the repo *unreadable* to
<br>   outsiders. It sorta prevents linking on Twitter but if we expect
<br>   there to be mirrors, people can just link to the mirrors.
<br>
<br>
<br>Again, it&#39;s not my project and I don&#39;t mean to advocate for any=
thing in
<br>particular. Just trying to organize thinking on the topic a bit.
<br>
<br>
<br>--=20
<br>Andrew Poelstra
<br>Director, Blockstream Research
<br>Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"nofollow" =
target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3De=
n&amp;q=3Dhttp://wpsoftware.net&amp;source=3Dgmail&amp;ust=3D17501790814970=
00&amp;usg=3DAOvVaw2RQMtnv3W_4s-O4R0pG1al">wpsoftware.net</a>
<br>Web:   <a href=3D"https://www.wpsoftware.net/andrew" rel=3D"nofollow" t=
arget=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den=
&amp;q=3Dhttps://www.wpsoftware.net/andrew&amp;source=3Dgmail&amp;ust=3D175=
0179081497000&amp;usg=3DAOvVaw1Bv6zMhIOBUkrJZX_pED3s">https://www.wpsoftwar=
e.net/andrew</a>
<br>
<br>The sun is always shining in space
<br>    -Justin Lewis-Webster
<br>
<br></blockquote></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/447c065f-aa73-463c-aa1c-60340850d24an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/447c065f-aa73-463c-aa1c-60340850d24an%40googlegroups.com</a>.<br />

------=_Part_480129_1043521683.1750092818631--

------=_Part_480128_1596192211.1750092818631--