Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B8C55C002A for ; Thu, 20 Apr 2023 09:24:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8767E83FAD for ; Thu, 20 Apr 2023 09:24:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8767E83FAD Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=uitnaVsN X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQWXlMRHg92v for ; Thu, 20 Apr 2023 09:24:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A7D0A83F9D Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp1.osuosl.org (Postfix) with ESMTPS id A7D0A83F9D for ; Thu, 20 Apr 2023 09:24:34 +0000 (UTC) Date: Thu, 20 Apr 2023 09:24:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1681982672; x=1682241872; bh=UpQ53lyd5aDSUYsPQ2A94B+kQbwDtPfBEqMm5znWl/Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=uitnaVsNenher4sv5d6C9zTJL4tVkjIHzRd+WQMaz33pxjrQng06tHiJPskXc6hG7 LHVOYdIHNo1mCtERSn6u8X06vp1eoU3pflNVrtVVk6KsrfJvzns3eRTlHlv8qXnE0c OQDm1uJkdVI7roAWewjb/QIHEfSmp/OwyZG4Y71QYLiD8agyGiBtVhCwUDD1+z1Q3R nMRGXU6eC+5UJCCug5ve6sDOPmmHumHxivxGunht7JY7SBG8XeLPJoRTaq/8O+mViq DlyIAbcKHWDTjW4i8LN4vFqyK3AVjKUned+0G2JZO7tQtVpZ/u1OnkJHqP0OQWHpYK iOMvPLEBrj44g== To: Anthony Towns From: Michael Folkson Message-ID: In-Reply-To: References: Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 20 Apr 2023 10:40:08 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2023 09:24:35 -0000 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 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