Date: Thu, 20 Apr 2023 09:24:19 +0000
To: Anthony Towns <aj@erisian.com.au>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <WDVwDUeYiJoJ_pfvagNC7JVoZEacE_MU_MHkS1GHgxV1arDZcCOdEwKf-5vX9CkHsMFsXtHVrYLFAEHAwmkgVEsqdRhUGIJIyCDr5EPr4_Y=@protonmail.com>
In-Reply-To: <ZECjAWr1cYtBKb+U@erisian.com.au>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <ZECjAWr1cYtBKb+U@erisian.com.au>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
Precedence: list

Hi AJ

> Competition is the only answer to concerns about the bad effects from a m=
onopoly.

Well one can first make suggestions and requests to the monopoly and see if=
 the monopoly is open to them. In the case of bitcoin-inquisition/default s=
ignet I like the idea of a group who are interested in following and testin=
g proposed future consensus changes working on the same fork of Core / same=
 signet blockchain. But I've asked on a number of occasions now what the th=
inking is in terms of criteria for merging a proposed default policy change=
 or a proposed consensus change (progress on BIP, level of review, a work i=
n progress / still in flux / essentially finalized unless a problem is iden=
tified) and you haven't been willing to discuss it. So it is essentially th=
e same black box model of maintainership we see on Core. As far as I know y=
ou could wake up one day and just merge all open pull requests to the bitco=
in-inquisition repo because you're bored. On a custom signet do whatever yo=
u want. On the default signet that we're trying to build an ecosystem aroun=
d, get block explorers to support, can be connected to through the default =
config in Core etc merge decisions essentially being subject to the whims o=
f AJ doesn't seem ideal to me.

The brunt of having to deal with the CTV activation chaos fell on me (not a=
 long term contributor, unfunded) because few wanted to get involved so it =
would be nice if lessons were learned and we don't have a soft fork proposa=
l merged onto default signet, a bunch of transactions generated to simulate=
 demand and then this used to justify another contentious soft fork activat=
ion attempt on mainnet. When there are vacuums of communication from mainta=
iners and long term contributors it just invites unnecessary chaos.

Thanks
Michael


--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Thursday, April 20th, 2023 at 03:27, Anthony Towns <aj@erisian.com.au> w=
rote:


> On Tue, Apr 18, 2023 at 12:40:44PM +0000, Michael Folkson via bitcoin-dev=
 wrote:
>=20
> > I do think the perception that it is =E2=80=9Cthe one and only=E2=80=
=9D staging
> > ground for consensus changes is dangerous
>=20
>=20
> If you think that about any open source project, the answer is simple:
> create your own fork and do a better job. Competition is the only answer
> to concerns about the bad effects from a monopoly. (Often the good effect=
s
> from cooperation and collaboration -- less wasted time and duplicated
> effort -- turn out to outweigh the bad effects, however)
>=20
> In any event, inquisition isn't "the one and only staging ground for
> consensus changes" -- every successful consensus change to date has
> been staged through the developers' own repo then the core PR process,
> and that option still exists.
>=20
> Cheers,
> aj