Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

From: Michael Folkson <michaelfolkson@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Date: Wed, 28 Sep 2022 11:48:32 +0000	[thread overview]
Message-ID: <lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.com> (raw)
In-Reply-To: <Yyg++7tqBC9WGOzc@erisian.com.au>

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 think 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 situation where the block signers (currently AJ and Kalle) are the gatekeepers on what 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 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/maintainers in the position of having to defend why some proposed soft forks are accessible on the default signet while others 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 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 soft forks on a custom signet they are opting in to possible disruption rather than 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 proposals 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 proposal 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.

So TL;DR still enthusiastic about this concept. Just with a strong preference 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 <bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev wrote:
> 
> > 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.
> 
> 
> Sure. I definitely didn't mean to imply a waterfall development model,
> or that the phases wouldn't overlap etc.
> 
> > 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 working
> > prototype running on bitcoin-inquisition` as a determining factor of the
> > 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, the
> > evolvability of APO with more known upgrades proposals or the
> > implementation complexity of a fully fleshed-out state machine and more
> > questions.
> 
> 
> 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.
> 
> > 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.
> 
> 
> (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)
> 
> > I hope the upcoming
> > Contracting Primitives WG will be able to document and discuss some of the
> > relevant experiments run on bitcoin-inquisition.
> 
> 
> Likewise.
> 
> (Lots trimmed due to either agreeing with it or having nothing to add)
> 
> Cheers,
> aj
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev