From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A6EB9C0051 for ; Sat, 29 Aug 2020 10:15:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 95245883BF for ; Sat, 29 Aug 2020 10:15:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQa7q+MLL-Ba for ; Sat, 29 Aug 2020 10:15:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by hemlock.osuosl.org (Postfix) with ESMTPS id 4C4B187D57 for ; Sat, 29 Aug 2020 10:15:02 +0000 (UTC) Received: by mail-ot1-f51.google.com with SMTP id 5so1373894otp.12 for ; Sat, 29 Aug 2020 03:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xqkSIoQDZkPedhj1m+FYYGSBhO6xp+uGrt8aj7tL1uc=; b=l3+YCqplbzHPbIBPM1fSOoaI3Rw9uqWeP5rZOus38Ior6A2yZ6CVYOb9Fem8Oc73wL jKM/UyCAIg5aW1dgIAfZLTwciq/vHukE1Hfhzd+GqMe8REmfbbFI5/LaTnn1gBc/lUnm cdEgJ9lB6F2CYcCOYnzDyg3eYZdlHkS2cu0HEQ8f77T4IjgPu1xD2vCo9QofI7tKL9oP vdbgRziyBIKzBQIDDXzvk5qLgueVJDP0N1ij0Dxz2t6sWKiHyf4YhFQ0n8DkVY8/DLkG JOdUrDvcT2JtFqd3/o6eeAIS+ILB4pgOHVs4NE3rpbYgJOH8ZEcD7lJumFSmqb63FJup KeSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xqkSIoQDZkPedhj1m+FYYGSBhO6xp+uGrt8aj7tL1uc=; b=gY/efiojZeUa/uiH0tMWd4R0WPhD4Zaae5pc8bA1eliYiKCJIAVsbie0O7cNrbGB02 dZp54NhhcWvdWkIx3jTr1nevq4Uc1QSYdmMYu6zB0EorfeLkthdQXtZ3KSuqRJOYFQoj 5DS4nKAkLluHUAhvW/Sr062yOi6XfYg+ymc+YPn7HoIYyTn1Ffg3KkaJx6Hu0664W47O PSHpMk43p38Ay347yvfo6wNCzUaVVeJlmrmQ4RV1l/LK2VfHVauB9DGZuhWBopnZOAL9 Q/auRrFHdl1R/iIDKjywcj+EncvUroYTvy0tJPBY1QN/zzhK4srykkmgR2ASN39EPsrD GZpQ== X-Gm-Message-State: AOAM53034ZlDripmnpsgITtn32o3kljbzcwAF/RgLKyxF91jfwdNEFYc DNhtsbAAqVXUWHgpFL9tb6Hwytq+Ed3+1cByDlHg8rZJP12z8A== X-Google-Smtp-Source: ABdhPJzzP+VI9J6Uz5lV9ppXftN5XUWXt93KCWM6QhTwdp02Sbuz1fVIzhxpUVTkf4YKRikDwgey7Wcz74LMs9JEUyo= X-Received: by 2002:a9d:226:: with SMTP id 35mr1621369otb.305.1598696100978; Sat, 29 Aug 2020 03:15:00 -0700 (PDT) MIME-Version: 1.0 From: Michael Folkson Date: Sat, 29 Aug 2020 11:14:50 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="00000000000033e4ca05ae0171d7" X-Mailman-Approved-At: Sat, 29 Aug 2020 12:01:15 +0000 Subject: [bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 10:15:03 -0000 --00000000000033e4ca05ae0171d7 Content-Type: text/plain; charset="UTF-8" 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 --00000000000033e4ca05ae0171d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all

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

(For more background we recen= tly had a Socratic Seminar with Kalle Alm and AJ Towns on Signet. Transcrip= t, reading list and video are available.)


The first= (of multiple) Signet PR 18267 in Bitcoin Core is at an advanced stage=C2= =A0of 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 g= ood to ensure everyone's testing needs are being met. I will put forwar= d 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 revi= ewed this post and they can chime in if they feel I am misrepresenting thei= r perspectives.

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

To be clear the= re will be multiple custom Signets. Even if we wanted to prevent them we co= uldn't. But is there an argument for having a "default" Signe= t 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). Otherw= ise there will be lots of splintered Signet networks all with different com= binations of proposed soft forks enabled and no network effect around a par= ticular Signet. I think this would be bewildering for say Taproot testers t= o have to choose between Person A's Signet with Taproot enabled and Per= son 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 b= e enabled on "default" Signet. It would have to be at a sufficien= tly 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 Signe= t and then change/get updated. However there are approaches that AJ in part= icular is working on to deal with this, one of which I have described below= .


2) Assuming there is a "default"= ; Signet how many people and who should have keys to sign each new "de= fault" 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 su= ggested on IRC that there should be at least one additional key present in = the EU/US timezone=C2=A0so blocks can continue to be mined during an Asia-P= acific outage. (Kalle and AJ are both in the Asia-Pacific region). Kalle be= lieves we should keep Signet running indefinitely unless we encounter speci= fic problems and personally I think this makes sense.

<= div>https://github.com/bitcoin/bitcoin/issues/19787#issuecomment-67= 9160691

3) Kalle has also experienced conc= ern from some in the community that testnet will somehow be replaced by Sig= net. This is not the case. As long as someone out there is mining testnet b= locks testnet will continue. However, there is the question of whether test= net needs to be reset. It was last reset in 2012 and there are differing ac= counts on whether=C2=A0this is presenting a problem for users of testnet. A= ssuming Signet is successful there will be less testing on testnet but what= testing use cases will still prefer testnet? It has been argued that testn= et should be a large chain to stress test certain IBD, P2P scenarios in whi= ch case it may be the case that we don't want to reset testnet. All oth= er testing use cases would not be impacted by the downsides of a large chai= n 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 t= he Bitcoin Core repo if you seek to review some of the prior conversation. = Ideally though we would have discussion that isn't directly impacting B= itcoin Core here on the mailing list or on IRC rather than in the Bitcoin C= ore repo.


Thanks
Michael

--
Michael Folkson<= div>Email:=C2= =A0michaelfol= kson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D4= 0 EAF4 9835 92D6 0159 214C FEE3
<= /div>
--00000000000033e4ca05ae0171d7--