path: root/21/4bb0ac7bcb4b948a4139e824173287245553bb

Delivery-date: Mon, 16 Jun 2025 08:28:23 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDI23FE35EIBBDHQYDBAMGQERQRX4YI@googlegroups.com>)
	id 1uRBl0-00059H-7T
	for bitcoindev@gnusha.org; Mon, 16 Jun 2025 08:28:23 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e639763e43dsf6263861276.0
        for <bitcoindev@gnusha.org>; Mon, 16 Jun 2025 08:28:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750087696; x=1750692496; 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=h/NZMrkwFVEoj4flhlTYwbejV181ng6/FecPiixd6Lk=;
        b=hNNUSo8ovBQVBBkHaTv7KosvbyC6O2A92uCwAlzVYWxQx+vo7cAD954sjCDjEAq0cM
         /7R8uBX1DEZPtmN3FeiiMg0vugEhu3NnqMr5TZONq0+W5Cmc8z5e7PJQnZm5yXF0AuDQ
         dTh3CxeZO7ZEBdWexKyY8S5oea1djkYPRl6X2YHEDwW/3v/9oWR9/sFqAPettCIi8gXP
         topXjyZtd+smdNjm8nD/5Pn2Z9+PrQv02+I/llHgW2D+VXKukkg5Nk/t6RsbI+BIzUfC
         5PgirLSuUSwWs4Toio3AgFqe5Pvd/5tJsOK+BBRI7DebPZL8If2GO6JhEhfD+C8IP18b
         yIPA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750087696; x=1750692496; 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=h/NZMrkwFVEoj4flhlTYwbejV181ng6/FecPiixd6Lk=;
        b=fW7DRwR5idn5/GgmDGx9pxgjUh7wOSauCY28P6qBeZz95RWnM/2R2HeGLoqvwx3Usy
         NZ7TgYr5wBIP11fSYW+QoT7/WzZ6qG5dEjOXLL0l5mUy1ZvDJsRH7W/1oa8Tajse6yHp
         8nnG2rFSlgqUl830Z3BvYIMyH2cApbmk4eE4uCH3ZidRHxF/SDcBGyBAypUT/p34M6zf
         jHrTZVK+rovtfvBGYTlcPkqk5WDeRZNJ+b3MXSzGFy1pTaTDHIgOoSym0VXSa0up+3QD
         3eCbjikXVm2tFolB/3zkU4OcHLi4FM1ou3PrbYlqfUyQ/oUHdYGVhPe015PNwnEMm1w3
         oVfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750087696; x=1750692496;
        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=h/NZMrkwFVEoj4flhlTYwbejV181ng6/FecPiixd6Lk=;
        b=XRM73a4etkKzwhZalh4Ly5EdDHIH/ChxBOTSiOrEJXfZec5u7B8qK2HtFltm6bQiy6
         4CBSkV3S782pzkD+x/T10BxmsLiZ6fNJTn+0CoW34iqb8F58iU+qFPd9sd4uYjk3yMtz
         vsxoP9+o/YfQJ2ZwxoEsvnvdLGBzU7w3nx9T4k8thFKsSYdTR4mEJlftmXJRoPGZIHpz
         cOkjT7bd680FB3zFSqwmLKb25+0hLsET4mf+kfVlHWqhBd4x9hGn93N1WQKHaPHlLx1d
         5wOOZ2xPAQlMm1KfsmoyTogU3smq/vPfMJrgQ5bs0eXuzThv6baIB2D/L2d9ALp+mKqp
         FBuA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCU30emPV0pSnPHl0W/BuNM4ryN4NEFPyRgi8h2gIcXzl5pqzjXgmEcE/qbdQ7LYP/JT49rtGlenJVXb@gnusha.org
X-Gm-Message-State: AOJu0YwNbXq1EuFLKqDFMNPe0w59BVMr20eMJdoJ9EnyiwaIzTZr0isS
	w2rQCqMGkcirm9+Z6D8bB3CgBW7+fM6Hx0yZuSWWgZ20yPgCf7ZypHEr
X-Google-Smtp-Source: AGHT+IE9qbrh3RbULDXamNXzxnn4lv3vyq6sTHOeP99gMMmir0fD9r+qMQ6XumQGu/0vwzfiOSP4Dw==
X-Received: by 2002:a05:6902:1884:b0:e82:1c41:fc61 with SMTP id 3f1490d57ef6-e822acab4fdmr12451665276.5.1750087696200;
        Mon, 16 Jun 2025 08:28:16 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdlJcjjxzGr+fTQOZZIxHwgtSl57VGLCqWxqQqYPR37iQ==
Received: by 2002:a25:d847:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e820dac7c5als4720220276.2.-pod-prod-00-us;
 Mon, 16 Jun 2025 08:28:12 -0700 (PDT)
X-Received: by 2002:a05:690c:a0a4:10b0:70e:2804:9930 with SMTP id 00721157ae682-7117236ad51mr99788937b3.10.1750087691813;
        Mon, 16 Jun 2025 08:28:11 -0700 (PDT)
Received: by 2002:a05:690c:3246:b0:710:fccf:6901 with SMTP id 00721157ae682-71162d3ec86ms7b3;
        Mon, 16 Jun 2025 08:14:46 -0700 (PDT)
X-Received: by 2002:a05:690c:660c:b0:70e:39e:91c2 with SMTP id 00721157ae682-7117236c5a6mr156698967b3.11.1750086885276;
        Mon, 16 Jun 2025 08:14:45 -0700 (PDT)
Date: Mon, 16 Jun 2025 08:14:44 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <4ad72033-dac1-4a4d-a432-1cc525f92e6dn@googlegroups.com>
In-Reply-To: <aE7xTUoUrPkNtDql@mail.wpsoftware.net>
References: <CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com>
 <aE7xTUoUrPkNtDql@mail.wpsoftware.net>
Subject: Re: [bitcoindev] The case for privatizing Bitcoin Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_470318_706782074.1750086884650"
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_470318_706782074.1750086884650
Content-Type: multipart/alternative; 
	boundary="----=_Part_470319_1293404734.1750086884650"

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

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 and=
=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 bad=
=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, though=
=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 list=
=20
or other channel?

I think the biggest problems arise when you insist that there is *no* place=
=20
for what you see as "brigading", "sock puppetry" etc. I have seen several=
=20
times in the past (most notably around the blocksize wars) where many=20
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" with=
=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 wrote:

> I have a few thoughts about this -- bearing in mind that I am a drive-by
> contributor to Core, at best, and don't have much personal opinion other
> than maybe "I wish it were easier to get stuff in".
>
> 1. I think that Antoine is correct that "it's easier and more natural"
> is a bigger motivation for "office work" than is the fear of brigade.
> So one thing is that any change to public processes shouldn't make it
> _harder_ for people to collaborate online, since that could push
> people more to in-person fora and we'd just have the worst of both
> worlds. Or at least, anyone making such a change should have a lot of
> confidence that the increased friendliness to earnest contributors
> would outweigh the extra friction.
>
> 2. On the other hand, fear of brigades _does_ clearly have a nonzero
> chilling effect. I certainly think about it when publicly communicating
> near the project, and I commonly bring it up when doing things in
> rust-bitcoin (i.e. "fortunately, we're not Core, so we can just do
> [some change that would constrain wallet workflows, or which could
> make ordinals particularly hard, or particularly easy, or whatever]"
> and not have to worry about fallout.)
>
> So at the very least, it's a factor that discourages some external
> developers from being bigger contributors to the project.
>
> 3. And of course, it's not just obvious brigades -- when one or two
> nontechnical people show up with strong political views about
> something which really is not a political change (or at least,
> doesn't have the political effect they believe it does, because of
> their own misunderstanding), it's still discouraging and sometimes
> stressful. And this happens all the time around mempool policy,
> even if PRs with 100+ comments that get locked are fairly rare.
>
> 4. However, after (ironically) discussing this email off-list with a
> bunch of people, I think that these problems stem from a fairly small
> cultural issue: that the Github repo appears to be a totally open
> forum where anyone is welcome to participate, even in code review
> threads, because technically anybody _can_ participate with no
> obvious sense that they're leaving X and entering somebody's
> workplace.
>
> And _this_, IMHO, might be solvable by something extremely simple. It
> might be sufficient to just move from Github to Gitlab or Codeberg or
> something where far fewer people have accounts. It would probably be
> sufficient to just find a platform where you have to register on the
> Core repo somehow then wait 24 hours before you can post, with the
> implication that if you're not there to contribute technically, you
> might lose your access. (This is true on Github but the only
> mechanism is that you can be banned from the org, something that
> feels heavy and scary for maintainers to use -- I really hate doing
> this to non-bots on rust-bitcoin and I don't even have to worry that
> they'll go on twitter to scream censorship and that I'm taking over
> Bitcoin or whatever -- and is also more-or-less invisible to users
> until it happens to them, so it's not an effective deterrent.)
>
> It would certainly be effective to put a strong technical barrier,
> e.g. you have to produce a custom mining share to join, or a strong
> social barrier, e.g. you need personal invitations from two people.
>
> But I think such tech barriers would be unnecessary and the social
> barriers wouldn't be worth the cries of censorship and centralization
> that they'd inevitably (and somewhat reasonably) cause.
>
> 5. I don't see much of benefit to making the repo *unreadable* to
> outsiders. It sorta prevents linking on Twitter but if we expect
> there to be mirrors, people can just link to the mirrors.
>
>
> Again, it's not my project and I don't mean to advocate for anything in
> particular. Just trying to organize thinking on the topic a bit.
>
>
> --=20
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
>

--=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/=
4ad72033-dac1-4a4d-a432-1cc525f92e6dn%40googlegroups.com.

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

<div>My personal opinion is that the best solution is to create a very stro=
ng ruleset on disallowing any non-technical contribution on github, and app=
lying that rule rigorously no matter whether the content *feels* acceptable=
 or not, and no matter how well respected the contributor is and might righ=
tfully be given some slack. This would be for PRs; for Issues, I don't know=
 how much of a similar problem you have, but templates aren't bad I guess.<=
/div><div><br /></div><div>Such extreme discipline is only needed in that r=
epo, virtually no other repo needs it.</div><div><br /></div><div>I also do=
 realize this could end up a bit of a weak-sauce suggestion compared to oth=
ers in this thread (I quite like Andrew's suggestion but, not sure it's exa=
ctly the right one).</div><div><br /></div><div>This would have to be accom=
panied by a very strong cohesion around what *is* the correct forum for tec=
hnically-adjacent bitcoin policy discussion (as just one example, advocatin=
g for or against soft forks goes in this bucket), and also tonally to *enco=
urage* such discussion; that encouragement would have to be broadcast from =
the github repo itself, certainly in messages to people whose discussion co=
ntribution is blocked. Obviously it would have to be noted elsewhere too li=
ke the main distribution website for the software.</div><div><br /></div><d=
iv>Unfortunately I don't think this mailing list *quite* fits the job, thou=
gh it's close ... on the other hand, where else? If this list is manually m=
oderated (as I believe it is), do we have a bitcoin-"policy" mailing list o=
r other channel?</div><div><br /></div><div>I think the biggest problems ar=
ise when you insist that there is *no* place for what you see as "brigading=
", "sock puppetry" etc. I have seen several times in the past (most notably=
 around the blocksize wars) where many highly respected engineers dismissed=
 all opposing opinions as sock puppetry. This is not realistic, nor is it h=
ealthy. If you stuff all contrary opinions (uneducated or not!) into a garb=
age bin that you label "politics" (imagine the phrase "go and discuss it on=
 bitcoin-politics" with the tacit assumption that no one serious is ever go=
ing to read that dumpster fire), it invites the exact conflict you're tryin=
g to avoid. I suggest "bitcoin policy" as a general title for such things, =
because bitcoin does indeed have "policies" in the general sense (not just =
the technical meaning of "policy" in bitcoin-the-software but also consensu=
s itself is a flavor of policy). If it doesn't end up being a place that se=
rious people talk seriously, then of course it will have failed in the inte=
ntion.</div><div><br /></div><div>Cheers,<br />AdamISZ/waxwing</div><br /><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Sunday,=
 June 15, 2025 at 1:30:24=E2=80=AFPM UTC-3 Andrew Poelstra wrote:<br/></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-lef=
t: 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" target=3D"_blank"=
 rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3De=
n&amp;q=3Dhttp://wpsoftware.net&amp;source=3Dgmail&amp;ust=3D17501723360320=
00&amp;usg=3DAOvVaw1A2d-yPaVkRy8llZuji0RQ">wpsoftware.net</a>
<br>Web:   <a href=3D"https://www.wpsoftware.net/andrew" target=3D"_blank" =
rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den=
&amp;q=3Dhttps://www.wpsoftware.net/andrew&amp;source=3Dgmail&amp;ust=3D175=
0172336032000&amp;usg=3DAOvVaw128xmXxKVlvwH2wrCREnSv">https://www.wpsoftwar=
e.net/andrew</a>
<br>
<br>The sun is always shining in space
<br>    -Justin Lewis-Webster
<br>
<br></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/4ad72033-dac1-4a4d-a432-1cc525f92e6dn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/4ad72033-dac1-4a4d-a432-1cc525f92e6dn%40googlegroups.com</a>.<br />

------=_Part_470319_1293404734.1750086884650--

------=_Part_470318_706782074.1750086884650--