Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EF0E9C002D for ; Wed, 28 Sep 2022 20:02:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B278A817F5 for ; Wed, 28 Sep 2022 20:02:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B278A817F5 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=NoL9fZam 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 7O2d1wJ1mQad for ; Wed, 28 Sep 2022 20:02:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6F305817EB Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6F305817EB for ; Wed, 28 Sep 2022 20:02:00 +0000 (UTC) Date: Wed, 28 Sep 2022 20:01:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1664395317; x=1664654517; bh=KRBTsGhQI0xUKAyjI/jckAtBw9cc5Hadm4o27cxJ9RI=; 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=NoL9fZamIwgpX0Modbd5FLtasKbB8s5Fr36zKtqH6hmpTmbGUjsG+PfnDBW8lP7hX gJNyT0e5Ru1s6+PphNYcLa+MJ77UAJlt6wh2NN2kd3PZPq5wpOzBxgM++sw/YFI8mO NeS+SHb9ukUFAZHEUxg3yA36LQirGiLDp/UtwsibDPmbS8Kmc5zBz+NgJw7c/iFIXU +EoduMex+xHmNRkTUtIzqFzaBpK+h21S5QQUBAtUW9GL1i59V7OIYjHHvg0BH+e+rM OI6qdXBHusd0ZXF3adPTSIDGwaaMsCH+p559/aP9RcLsFQOgYLyUf4iD8mf1MM8cYe zbNqUo/OKwDPg== To: Michael Folkson From: alicexbt Message-ID: In-Reply-To: References: Feedback-ID: 40602938: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 20:24:34 +0000 Cc: Bitcoin Protocol Discussion , Anthony Towns 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 20:02:04 -0000 Hi Michael, > We then get into the situation where the block signers (currently AJ and = Kalle) are the gatekeepers on what soft fork proposals are added. Things that could solve the gatekeeping issue: 1) Adding more maintainers that are experienced enough to review consensus = code.=20 2) Every soft fork that is implemented on signet should be discussed on mai= ling list before merging the pull request. 3) Pull request that implements a soft fork should have at least 2 ACKs fro= m the maintainers, 3 ACKs from developers who have either authored or revie= wed enough consensus related pull requests in bitcoin core and 1 ACK from m= aintainers of other implementations (knots, btcd, libbitcoin, bcoin etc.) 4) Every technical NACK from any developer or user in the pull request shou= ld be resolved/answered before merging the pull request. This was not the case in [implementing BIP][1] 119 however it could be used= in future or something similar that everyone agrees upon including AJ and = Kalle. Pull request implementing BIP 119 in bitcoin core is already reviewe= d by lot of developers and I think AJ found a [bug][2] recently. Gatekeeping at several levels already exists in bitcoin development and dif= ficult to solve. If some developers believe a soft fork should have been im= plemented on global signet but it was not, there is always the possibility = of running custom signet with certain trade-offs. > 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 rep= o (to avoid it being merged into Core prematurely) it is still determining = what soft forks are accessible from the signet flag in Bitcoin Core. I don'= t think it is fair on the signet block signers to put them in that position= and I don't think it is wise to put other Bitcoin Core contributors/mainta= iners in the position of having to defend why some proposed soft forks are = accessible on the default signet while others aren't. Mainnet and Testnet have already been [removed][3] from the 'bitcoin-inquis= ition/bitcoin' repository, and signet in bitcoin core is largely used by de= velopers or power users, thus it should not be a problem. Signet could also= be removed from bitcoin core binaries that are released regularly while be= ing available if built from source. Since signet coins have no value, utilizing this chain to experiment with s= oft forks will only help the bitcoin development process. If we can't even = agree to implement something on a network used for testing then it will be = nearly impossible to do any soft forks on mainnet. This experiment has seve= ral advantages. We can implement many consensus changes and compare alterna= tives in a better way. Pre-baked ability to abandon the soft fork isn't imp= lemented yet AFAIK, however that could further improve things. [1]: https://github.com/bitcoin-inquisition/bitcoin/pull/3 [2]: https://github.com/bitcoin/bitcoin/pull/21702#discussion_r979273387 [3]: https://github.com/bitcoin-inquisition/bitcoin/pull/1 /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, September 28th, 2022 at 5:18 PM, Michael Folkson via bitcoin-= dev wrote: > I've given this some extra thought and discussed with others who may late= r chime in on this thread. I'm now convinced this should be done on a custo= m public signet rather than on the default signet. SegWit was added to a ne= w testnet (Segnet) for testing rather than the pre-existing testnet and I t= hink future soft fork proposals should follow a similar approach. >=20 > Even if there is community consensus on what soft fork proposals should b= e added to the default signet today (which may or may not be case) I find i= t highly unlikely this will always be the case. We then get into the situat= ion where the block signers (currently AJ and Kalle) are the gatekeepers on= what soft fork proposals are added. The default signet is directly support= ed with the -signet flag in Bitcoin Core. Even if we are moving the propose= d soft fork code to an external repo (to avoid it being merged into Core pr= ematurely) it is still determining what soft forks are accessible from the = signet flag in Bitcoin Core. I don't think it is fair on the signet block s= igners to put them in that position and I don't think it is wise to put oth= er Bitcoin Core contributors/maintainers in the position of having to defen= d why some proposed soft forks are accessible on the default signet while o= thers aren't. >=20 > The default signet was a long term project to address the unreliability a= nd weaknesses of testnet. Many default signet users won't be interested in = testing soft fork proposals and it is not reasonable for them to be subject= to a stalling or forked blockchain because changes to a soft fork proposal= or a buggy soft fork proposal pushed to the default signet makes previous = valid/invalid transactions invalid/valid. If they want to test proposed sof= t forks on a custom signet they are opting in to possible disruption rather= than it being forced upon them. >=20 > By focusing on custom signets rather than the default signet it also allo= ws for more experimentation. Don't like the choices of which soft fork prop= osals have been added to bitcoin-inquisition? Set up your own custom signet= with a different set of soft fork proposals and get users for your custom = signet on a level playing field to bitcoin-inquisition. A soft fork proposa= l is found to be strictly inferior to another soft fork proposal? Just spin= down the custom signet with that inferior soft fork proposal on it without= impacting default signet users. >=20 > So TL;DR still enthusiastic about this concept. Just with a strong prefer= ence that it is done on a custom signet rather than on the default signet. >=20 > Thanks > Michael >=20 > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >=20 >=20 > ------- Original Message ------- > On Monday, September 19th, 2022 at 11:05, Anthony Towns via bitcoin-dev b= itcoin-dev@lists.linuxfoundation.org wrote: >=20 >=20 >=20 > > On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev= wrote: > >=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= this > > > evaluation is as much done by the original author than its peers and = a > > > wider audience. > >=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 empiricis= m in > > > matter of consensus upgrades. I.e, slowly emerging the norm of a work= ing > > > prototype running on bitcoin-inquisition` as a determining factor of = the > > > soundness of a proposal. E.g with "upgrading lightning to support elt= oo", 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,= the > > > evolvability of APO with more known upgrades proposals or the > > > implementation complexity of a fully fleshed-out state machine and mo= re > > > questions. > >=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 = the > > > summer, another one might not want "noise" interferences with new > > > fee-bumping primitives as the miner incentives are modified. > >=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 experime= nt > > with "fee incentives" too) > >=20 > > > I hope the upcoming > > > Contracting Primitives WG will be able to document and discuss some o= f the > > > relevant experiments run on bitcoin-inquisition. > >=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 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev