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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 86503C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 00:50:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with UTF8SMTP id 62C7384A52
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 00:50:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id LZ4rdJCIAAeq
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 00:50:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp1.osuosl.org (Postfix) with UTF8SMTPS id D90A684A29
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 00:50:17 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 4H5HN56yhJz120fD;
Fri, 10 Sep 2021 00:50:13 +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=1631233266; t=1631235014;
bh=OZ6zu4QhT2e5rCX2pgqBB+wbBaFo8QIJSLBiqE1u61A=;
h=Subject:To:References:From:In-Reply-To:From;
b=5t6oTdKcn2X7os+wS1qYCzWoBqlIpzhW9Agg5TcC/bo0byQPZToPdm8yRci3gLZtn
kiRorZGTENMvZlUaq2uPhJqPUPcQU1vWrr98IhK3LNY/CD0y9Fst659aSAqfMzJuYZ
caynYPg26uwej0v1uAmOfAWRaLUUHIlx2B7htqXiTTz50hpcGbotp24ChWeoJCUntj
WrpZ7ZhAtEvp8By3BPJpeP8mZb9ErB33guB3QKg/OSahBkBBodGtmomw/tPajWgzs7
vGk2X3lAkaK1bFm9XAktFCI6dPn2S37u5+stAjc0BSyINF+Gq8riBYVljwyMyohfNJ
dCEqwh6KbC3uw==
Message-ID: <e11d718f-2bb7-335a-80dc-7d44244a0e98@mattcorallo.com>
Date: Thu, 9 Sep 2021 17:50:08 -0700
MIME-Version: 1.0
Content-Language: en-US
To: 0xB10C <0xb10c@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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, 10 Sep 2021 00:50:20 -0000
On 9/7/21 09:07, 0xB10C via bitcoin-dev wrote:
> Hello,
>
> tl;dr: We want to make reorgs on SigNet a reality and are looking for
> feedback on approach and parameters.
Awesome!
> AJ proposed to allow SigNet users to opt-out of reorgs in case they
> explicitly want to remain unaffected. This can be done by setting a
> to-be-reorged version bit flag on the blocks that won't end up in the
> most work chain. Node operators could choose not to accept to-be-reorged
> SigNet blocks with this flag set via a configuration argument.
Why bother with a version bit? This seems substantially more complicated than the original proposal
that surfaced many times before signet launched to just have a different reorg signing key. Thus,
users who wish to follow reorgs can use a 1-of-2 (or higher multisig) and users who wish to not
follow reorgs would use a 1-of-1 (or higher multisig), simply marking the reorg blocks as invalid
without touching any header bits that non-full clients will ever see.
> The reorg-interval X very much depends on the user's needs. One could
> argue that there should be, for example, three reorgs per day, each 48
> blocks apart. Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day. Developers don't
> need to wait for, for example, a week until they can test their reorgs
> next. However, too frequent reorgs could hinder other SigNet users.
I see zero reason whatsoever to not simply reorg ~every block, or as often as is practical. If users
opt in to wanting to test with reorgs, they should be able to test with reorgs, not wait a day to
test with reorgs.
> We propose that the reorg depth D is deterministically random between a
> minimum and a maximum based on, e.g., the block hash or the nonce of the
> last block before the reorg. Compared to a local randint() based
> implementation, this allows reorg-handling tests and external tools to
> calculate the expected reorg depth.
>
> # Scenario 1: Race between two chains
>
> For this scenario, at least two nodes and miner scripts need to be
> running. An always-miner A continuously produces blocks and rejects
> blocks with the to-be-reorged version bit flag set. And a race-miner R
> that only mines D blocks at the start of each interval and then waits X
> blocks. A and R both have the same hash rate. Assuming both are well
> connected to the network, it's random which miner will first mine and
> propagate a block. In the end, the A miner chain will always win the race.
>
> # Scenario 2: Chain rollback
>
> This scenario only requires one miner and Bitcoin Core node but also
> works in a multiminer setup. The miners mine D blocks with the
> to-be-reorged version bit flag set at the start of the interval. After
> allowing the block at height X+D to propagate, they invalidate the block
> at height X+1 and start mining on block X again. This time without
> setting the to-be-reorged version bit flag. Non-miner nodes will reorg
> to the new tip at height X+D+1, and the first-seen branch stalls.
Both seem reasonable. I'm honestly not sure what software cases would be hit differently between one
or the other, as long as reorgs happen regularly and at random depth. Nodes should presumably only
ever be following one chain.
> # Questions
>
> 1. How do you currently test your applications reorg handling? Do
> the two discussed scenarios (race and chain rollback) cover your
> needs? Are we missing something you'd find helpful?
>
> 2. How often should reorgs happen on the default SigNet? Should
> there be multiple reorgs a day (e.g., every 48 or 72 blocks
> assuming 144 blocks per day) as your engineers need to be awake?
> Do you favor less frequent reorgs (once per week or month)? Why?
>
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
6 is the "standard" confirmation window for mainnet. Its arguably much too low, but for testing
purposes we've gotta pick something, so that seems reasonable?
Matt
|
