From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1B158C002D for ; Wed, 28 Sep 2022 11:48:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E726C40320 for ; Wed, 28 Sep 2022 11:48:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E726C40320 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=wB+Rozyd X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl86UPDz-_H9 for ; Wed, 28 Sep 2022 11:48:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D44DD40221 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp4.osuosl.org (Postfix) with ESMTPS id D44DD40221 for ; Wed, 28 Sep 2022 11:48:38 +0000 (UTC) Date: Wed, 28 Sep 2022 11:48:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1664365716; x=1664624916; bh=lY+InCzgWHPkvqRve77EPoi+IwWypQ8eo65QWK+78q4=; 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; b=wB+RozydlPYwVN6vsu3rjsfO2JBmuUqbvBvyMhT54tnCQwthOy08KbLRupMNBTPDI Ni3n729DORIgZxxD766Qp2oUXiilUfCNWGQcUOikikngJddVjOcx3F0CkYsCVZTcpL 0rmZ6p0xNZ9l7jmiXhRuofJ2w5Bpnw7c3Ng47GsBXC7eBRKoAO51qghbm59kIMq4Et swCUhzdZKjTUUo24fJ01evPByBjP76eqA3M19tM3cIylbVE8LcEtsKUJIBXRzUxECc G/TDZzZZMurJ3tKhsVaflwWfkAT51wa2A0gXs4S69MTOhX4CMd5NoKhcAauXaNKreF MJjUSfx1f/8Ug== To: Anthony Towns , Bitcoin Protocol Discussion 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: Wed, 28 Sep 2022 12:16:36 +0000 Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet 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: Wed, 28 Sep 2022 11:48:41 -0000 I've given this some extra thought and discussed with others who may later = chime in on this thread. I'm now convinced this should be done on a custom = public signet rather than on the default signet. SegWit was added to a new = testnet (Segnet) for testing rather than the pre-existing testnet and I thi= nk future soft fork proposals should follow a similar approach. Even if there is community consensus on what soft fork proposals should be = added to the default signet today (which may or may not be case) I find it = highly unlikely this will always be the case. We then get into the situatio= n where the block signers (currently AJ and Kalle) are the gatekeepers on w= hat soft fork proposals are added. The default signet is directly supported= with the -signet flag in Bitcoin Core. Even if we are moving the proposed = soft fork code to an external repo (to avoid it being merged into Core prem= aturely) it is still determining what soft forks are accessible from the si= gnet flag in Bitcoin Core. I don't think it is fair on the signet block sig= ners to put them in that position and I don't think it is wise to put other= Bitcoin Core contributors/maintainers in the position of having to defend = why some proposed soft forks are accessible on the default signet while oth= ers aren't. The default signet was a long term project to address the unreliability and= weaknesses of testnet. Many default signet users won't be interested in te= sting soft fork proposals and it is not reasonable for them to be subject t= o a stalling or forked blockchain because changes to a soft fork proposal o= r a buggy soft fork proposal pushed to the default signet makes previous va= lid/invalid transactions invalid/valid. If they want to test proposed soft = forks on a custom signet they are opting in to possible disruption rather t= han it being forced upon them. By focusing on custom signets rather than the default signet it also allows= for more experimentation. Don't like the choices of which soft fork propos= als have been added to bitcoin-inquisition? Set up your own custom signet w= ith a different set of soft fork proposals and get users for your custom si= gnet on a level playing field to bitcoin-inquisition. A soft fork proposal = is found to be strictly inferior to another soft fork proposal? Just spin d= own the custom signet with that inferior soft fork proposal on it without i= mpacting default signet users. So TL;DR still enthusiastic about this concept. Just with a strong preferen= ce that it is done on a custom signet rather than on the default signet. 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 Monday, September 19th, 2022 at 11:05, Anthony Towns via bitcoin-dev wrote: > On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev w= rote: >=20 > > Said succinctly, in the genesis of creative ideas, evaluation doesn't > > happen at a single clear point but all along the idea lifetime, where t= his > > evaluation is as much done by the original author than its peers and a > > wider audience. >=20 >=20 > Sure. I definitely didn't mean to imply a waterfall development model, > or that the phases wouldn't overlap etc. >=20 > > I would still expose a concern to not downgrade in the pure empiricism = in > > matter of consensus upgrades. I.e, slowly emerging the norm of a workin= g > > prototype running on bitcoin-inquisition` as a determining factor of th= e > > soundness of a proposal. E.g with "upgrading lightning to support eltoo= ", a > > running e2e won't save us to think the thousands variants of pinnings, = the > > game-theory soundness of a eltoo as mechanism in face of congestions, t= he > > evolvability of APO with more known upgrades proposals or the > > implementation complexity of a fully fleshed-out state machine and more > > questions. >=20 >=20 > I agree here; but I think not doing prototypes also hinders thinking > about all the thousands of details in a fork. It's easy to handwave > details away when describing things on a whiteboard; and only realise > they're trickier than you thought when you go to implement things. >=20 > > E,g if one implements the "weird" ideas > > about changes in the block reward issuance schedule discussed during th= e > > summer, another one might not want "noise" interferences with new > > fee-bumping primitives as the miner incentives are modified. >=20 >=20 > (I don't think "miner incentives" are really something that can be > investigated on signet. You can assume how miners will respond to > incentives and program the mining software to act that way; but there's > no competitive pressure in signet mining so I don't think that really > demonstrates anything very much. Likewise, there's much less demand for > blockspace on signet than on mainnet, so it's probably hard to experiment > with "fee incentives" too) >=20 > > I hope the upcoming > > Contracting Primitives WG will be able to document and discuss some of = the > > relevant experiments run on bitcoin-inquisition. >=20 >=20 > Likewise. >=20 > (Lots trimmed due to either agreeing with it or having nothing to add) >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev