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

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

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. 
2) Every soft fork that is implemented on signet should be discussed on mailing list before merging the pull request.
3) Pull request that implements a soft fork should have at least 2 ACKs from the maintainers, 3 ACKs from developers who have either authored or reviewed enough consensus related pull requests in bitcoin core and 1 ACK from maintainers of other implementations (knots, btcd, libbitcoin, bcoin etc.)
4) Every technical NACK from any developer or user in the pull request should 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 reviewed by lot of developers and I think AJ found a [bug][2] recently.

Gatekeeping at several levels already exists in bitcoin development and difficult to solve. If some developers believe a soft fork should have been implemented 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 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.

Mainnet and Testnet have already been [removed][3] from the 'bitcoin-inquisition/bitcoin' repository, and signet in bitcoin core is largely used by developers or power users, thus it should not be a problem. Signet could also be removed from bitcoin core binaries that are released regularly while being available if built from source.

Since signet coins have no value, utilizing this chain to experiment with soft 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 several advantages. We can implement many consensus changes and compare alternatives in a better way. Pre-baked ability to abandon the soft fork isn't implemented 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 <bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev