[bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet

From: Michael Folkson <michaelfolkson@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet
Date: Sat, 29 Aug 2020 11:14:50 +0100	[thread overview]
Message-ID: <CAFvNmHQM5DB1paFZZ=uT3uY3hN6pOY=opfh92vS-HTka-uH3Yw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4967 bytes --]

Hi all

Signet has been announced and discussed previously on the mailing list so I
won't repeat what Signet is and its motivation.

(For more background we recently had a Socratic Seminar with Kalle Alm and
AJ Towns on Signet. Transcript, reading list and video are available.)

https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-08-19-socratic-seminar-signet/

The first (of multiple) Signet PR 18267 in Bitcoin Core is at an advanced
stage of review and certainly additional code review and testing of that PR
is encouraged.

https://github.com/bitcoin/bitcoin/pull/18267

However there are some meta questions around Signet(s) that are best
discussed outside of the Bitcoin Core repo and it would be good to ensure
everyone's testing needs are being met. I will put forward my initial
thoughts on some of these questions. These thoughts seem to be aligned with
Kalle's and AJ's initial views but they have not reviewed this post and
they can chime in if they feel I am misrepresenting their perspectives.

1) Should there be one "default" Signet that we use for specific purpose(s)
or should we "let a thousand ships sail"?

To be clear there will be multiple custom Signets. Even if we wanted to
prevent them we couldn't. But is there an argument for having a "default"
Signet with a network effect? A Signet that a large proportion of the
community is drawn to using with tooling and support? I would say yes.
Especially if we see Signet as a staging ground for testing proposed soft
fork(s). Otherwise there will be lots of splintered Signet networks all
with different combinations of proposed soft forks enabled and no network
effect around a particular Signet. I think this would be bewildering for
say Taproot testers to have to choose between Person A's Signet with
Taproot enabled and Person B's Signet with Taproot enabled. For this to
work there would have to be a formal understanding of at what stage a
proposed soft fork should be enabled on "default" Signet. It would have to
be at a sufficiently mature stage (e.g. BIP number allocated, BIP drafted
and under review, PR open in Bitcoin Core repo under review etc) but early
enough so that it can be tested on Signet well in advance of being
considered for activation on mainnet. This does present challenges if soft
forks are enabled on Signet and then change/get updated. However there are
approaches that AJ in particular is working on to deal with this, one of
which I have described below.

https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining

2) Assuming there is a "default" Signet how many people and who should have
keys to sign each new "default" Signet block? If one of these keys is lost
or stolen should we reset Signet? Should we plan to reset "default" Signet
at regular intervals anyway (say every two years)?

Currently it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys.
It was suggested on IRC that there should be at least one additional key
present in the EU/US timezone so blocks can continue to be mined during an
Asia-Pacific outage. (Kalle and AJ are both in the Asia-Pacific region).
Kalle believes we should keep Signet running indefinitely unless we
encounter specific problems and personally I think this makes sense.

https://github.com/bitcoin/bitcoin/issues/19787#issuecomment-679160691

3) Kalle has also experienced concern from some in the community that
testnet will somehow be replaced by Signet. This is not the case. As long
as someone out there is mining testnet blocks testnet will continue.
However, there is the question of whether testnet needs to be reset. It was
last reset in 2012 and there are differing accounts on whether this is
presenting a problem for users of testnet. Assuming Signet is successful
there will be less testing on testnet but what testing use cases will still
prefer testnet? It has been argued that testnet should be a large chain to
stress test certain IBD, P2P scenarios in which case it may be the case
that we don't want to reset testnet. All other testing use cases would not
be impacted by the downsides of a large chain as they would gravitate
towards Signet regardless.

https://bitcoin.stackexchange.com/questions/98579/will-there-be-a-testnet4-or-do-we-not-need-a-testnet-reset-once-we-have-signet/

If you have thoughts, feedback, questions it would be great to hear them.
Certainly we should seek to make sure everybody's testing needs are being
considered.

There is a closed issue on the Bitcoin Core repo if you seek to review some
of the prior conversation. Ideally though we would have discussion that
isn't directly impacting Bitcoin Core here on the mailing list or on IRC
rather than in the Bitcoin Core repo.

https://github.com/bitcoin/bitcoin/issues/19787

Thanks
Michael

-- 
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

[-- Attachment #2: Type: text/html, Size: 6790 bytes --]