Date: Wed, 28 Sep 2022 20:01:46 +0000
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <U3f8PdO0Wm3FyUH3FViPodLCWlvZckitTgchR8hqxGSBPVjV2WTtbyFRxx3OZUd9TEm-p_Juft9EqjjkWG1LdmFdPmDP0WfW3RW_TgXOqtI=@protonmail.com>
In-Reply-To: <lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.com>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
 <Yyg++7tqBC9WGOzc@erisian.com.au>
 <lEYH8tZZf8onusZyemenCfTXz44xohxMwOflLeHnxcsk-MwNuOFLKId8GQnLBkAe10UOUjD6tQ-pJhbpMDQMA7Y5FIK7xvs2bAvQI2KBbQs=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

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 <bitcoin-dev@lists.linuxfoundation.org> 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