Date: Wed, 28 Sep 2022 11:48:32 +0000
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.com>
In-Reply-To: <Yyg++7tqBC9WGOzc@erisian.com.au>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
 <Yyg++7tqBC9WGOzc@erisian.com.au>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
Precedence: list

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 <bi=
tcoin-dev@lists.linuxfoundation.org> 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