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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6B3CFC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 04:42:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 3F52F40136
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 04:42:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 3.054
X-Spam-Level: ***
X-Spam-Status: No, score=3.054 tagged_above=-999 required=5
tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.276, PDS_OTHER_BAD_TLD=1.975,
SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Y8ZkpX_o0wQ5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 04:42:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4846540001
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 04:42:03 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1mbF2Z-0001eF-Un; Fri, 15 Oct 2021 14:41:58 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 15 Oct 2021 14:41:50 +1000
Date: Fri, 15 Oct 2021 14:41:50 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20211015044150.GD6451@erisian.com.au>
References: <20210914045610.GA25475@erisian.com.au>
<90AD5816-4B44-4BBB-A2FC-39CD381D6395@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <90AD5816-4B44-4BBB-A2FC-39CD381D6395@mattcorallo.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: 1
X-Spam-Bar: /
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on
approach and parameters
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: Fri, 15 Oct 2021 04:42:06 -0000
On Wed, Sep 15, 2021 at 08:24:43AM -0700, Matt Corallo via bitcoin-dev wrote:
> > On Sep 13, 2021, at 21:56, Anthony Towns <aj@erisian.com.au> wrote:
> > I'm not sure that's really the question you want answered?
> Of course it is? I’d like to understand the initial thinking and design analysis that went into this decision. That seems like an important question to ask when seeking changes in an existing system :).
Well, "are there any drawbacks to doing X instead, because that would make
it easier for me to do Y" just seems like a more interesting question?
Because:
> > Mostly
> > it's just "this is how mainnet works" plus "these are the smallest
> > changes to have blocks be chosen by a signature, rather than entirely
> > by PoW competition".
doesn't seem like that interesting an answer...
To be a bit more specific, it's not at all clear to me what you would
be happy with? (I mean, beyond "something magic that works exactly how
I want it, when I want it, even if I don't know what that is yet or
change my mind later" which is obviously the desired behaviour for all
software everywhere)
You say you're happier with both mainnet and testnet3 than signet,
but mainnet isn't any faster than signet, while (if you've got an ASIC)
testnet3 will give you a block per second, especially if you don't mind
your blocks getting reorged out. There's a lot of ground between those
two extremes.
> > For integration testing across many services, I think a ten-minute-average
> > between blocks still makes sense -- protocols relying on CSV/CLTV to
> > ensure there's a delay they can use to recover funds, if they specify
> > that in blocks (as lightning's to_self_delay does), then significant
> > surges of blocks will cause uninteresting bugs.
> Hmm, why would blocks coming quicker lead to a bug? I certainly hope no one has a bug if their block time is faster than per ten minutes. I presume here, you mean something like “if the node can’t keep up with the block rate”, but I certainly hope the benchmark for may isn’t 10 minutes, or really even one.
The lightning to_self_delay is specified in blocks, but is meant to allow
you to be offline for some real time period; if you specify 1000 blocks
and are sure you'll be online every two days, that's fine on mainnet
and signet as it stands, but broken on testnet.
> > It would be easy enough to change things to target an average of 2 or
> > 5 minutes, I suppose, but then you'd probably need to propogate that
> > logic back into your apps that would otherwise think 144 blocks is around
> > about a day.
> Why? One useful thing for testing is compressing real time.
Sure, but if you're compressing _real_ time you need to manipulate the
nTime not just the number of blocks -- and that might be relevant for
nLocktime or nSequence checks by mtp rather than height. But that's
not something signet's appropriate for: you should be using regtest for
that scenario.
> > We could switch back to doing blocks exactly every 10 minutes, rather
> > than a poisson-ish distribution in the range of 1min to 60min, but that
> > doesn't seem like that huge a win, and makes it hard to test that things
> > behave properly when blocks arrive in bursts.
> Hmm, I suppose? If you want to test that the upper bound doesn’t
> need to be 100 minutes, though, it could be 10.
Mathematically, you can't have an average of 10 minutes and a max of 10
minutes without the minimum also being 10 minutes...
> > Best of luck to you then? Nobody's trying to sell you on a subscription
> > plan to using signet.
> lol, yes, I’m aware of that, nor did I mean to imply that anything has to be targeted at a specific person’s requirements. Rather, my point here is that I’m really confused as to who the target user *is*, because we should be building products with target users in mind, even if those targets are often “me” for open source projects.
I don't really think there's a definitive answer to that yet?
My guess is "integration testing" is close to right; whether it be
different services validating they interoperate, or users seeing if a
service works the way they expect in a nearly-live environment.
For private signets, the advantage over regtest is you don't risk some
random participant causing major reorgs, and can reasonably use it over
the internet without having to worry too much about securing things.
For the default public signet, the advantage over regtest is probably that
you've got additional infrastructure already setup (eg explorer.bc-2.jp
and mempool.space/signet, perhaps eventually a decent lightning test
network? there's signet-lightning.wakiyamap.dev)
The advantage of a private signet vs the default public one is probably
only that you can control the consensus rules to introduce and test a
new soft fork if you want. The advantage of the default public signet
over your own private one is probably mostly that it already has
miners/explorers/faucets setup and you don't have to do that yourself.
I think the default public signet makes sense as a "demo mainnet" --
somewhere you can do all the things you can on mainnet, with pretty
similar constraints, but some more interesting behaviours -- like bigger
reorgs, or earlier availability of new features.
So to me that adds up as:
* are you a single developer making software? do it on regtest so you've
got complete control
* are you trying out some software? so it on the default public signet,
because that's the least effort and will give you a pretty good idea
how it will behave on mainnet
* are you checking your software interoperates with some random other
project in the way you expect? again, default public signet, since
hopefully the other project already supports it
* are you doing a collaboration/partnership with another development
team? do you want a stable environment for your team to collaborate
on? setup your own private signet for the test environment (but do
local tests and CI tests via regtest too)
YMMV, that's just my opinion, etc.
FWIW, I was frustrated the other day when trying to mine [0] and seeing
the next block wasn't due for ~40 minutes (and the spend script had a
CSV constraint, so I had to wait for it to be mined before I could get
the followup txs in the mempool). OTOH, it wasn't frustrating enough to
either mine a block early or switch to regtest, so... I guess I see the
point, but not really any particular action to take for it?
[0] https://explorer.bc-2.jp/tx/ba58d99dfaad83e105a0de1a9becfcf8eaf897aaaada54bd7b08134ff579997c?input:0&expand
Cheers,
aj
|
