1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1F719C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2020 02:11:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 0447F86830
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2020 02:11:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id goCTlHMBVggz
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2020 02:11:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by whitealder.osuosl.org (Postfix) with ESMTPS id A10878682D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Sep 2020 02:11:33 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id 95E5A3283A1;
Mon, 14 Sep 2020 02:11:32 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1600047665; t=1600049492;
bh=3AHve9ScW3fvTu4wXdlC1dAiTdkq5D95g3cgS2SfjgM=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=CaCB+qmf/192Q4M0rkybKRz+kE9L8Ou/Dq/HiXcjiYSOeKoGgWgoOO1g4uhKE6mjS
wk6raplBWTeJX6GfYC0C4TbazxlBE7SaZnLym5MaZL0+vjFfx48z9QwBWQzuDi+3gg
nfQQgN2pFn46Mbe1Ga3kAXCFBhH6sgg5jZNu+BjqvQzmm0/SwnRVAMIGEXUU2g4lN4
l1/YtUrjFrN+N58NYNd4fuXI0kijD3EXYGgeltlb+XgEGlfFuP5nJ5ULAK/+qDFh+T
9DHaGQn0C64m+QDJoDbQdRh2LwalBhfMmVgzD763/VNbNb1Wa1o/bh7np6spNQgIJo
UHhtNmVSrcXDg==
To: Michael Folkson <michaelfolkson@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFvNmHQM5DB1paFZZ=uT3uY3hN6pOY=opfh92vS-HTka-uH3Yw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <0713f5a0-73ce-5a06-90e1-56000f5ddeba@mattcorallo.com>
Date: Sun, 13 Sep 2020 22:11:32 -0400
MIME-Version: 1.0
In-Reply-To: <CAFvNmHQM5DB1paFZZ=uT3uY3hN6pOY=opfh92vS-HTka-uH3Yw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 02:11:35 -0000
[resent with correct source, sorry Michael, stupid Apple]
Yes, a “default” signet that regularly reorgs a block or two all the time and is “compatible” with testnet but a faster
block target (eg so that it is trivial to mine but still has PoW) and freshly-seeded genesis would be a massive step-up
in testing usability across the space.
I don’t have strong feelings about the multisig policy, but probably something that is at least marginally robust (ie
2-of-N) and allows valid blocks to select the next block’s signers for key rollovers is probably close enough.
There are various folks with operational experience in the community, so let’s not run stuff on DO/AWS/etc, please.
Matt
On 8/29/20 6:14 AM, Michael Folkson via bitcoin-dev wrote:
> 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/
> <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 <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
> <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
> <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/
> <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 <https://github.com/bitcoin/bitcoin/issues/19787>
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail.com <mailto:michaelfolkson@gmail.com>
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
