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
188
189
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3B2ECC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Sep 2021 14:34:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 129646076B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Sep 2021 14:34:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HEXHASH_WORD=1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id G6oWqgK2oLax
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Sep 2021 14:34:21 +0000 (UTC)
X-Greylist: delayed 00:05:01 by SQLgrey-1.8.0
Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl
[213.180.149.157])
by smtp3.osuosl.org (Postfix) with ESMTPS id 7F01E608B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Sep 2021 14:34:21 +0000 (UTC)
Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4H6sS62NkGz2K2ncH;
Sun, 12 Sep 2021 16:29:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1631456951; bh=rJzjG5xaZuuaE6pDUbNj54mEBEsVghcRZzDRelQcwtE=;
h=From:To:In-Reply-To:Date:Subject:From;
b=JW+4BrQFaaQXdXHh8QbIKYYKPkJ8720NDvxdQdIU/2c16xaUNSijDBnOiT5P2CmWb
eHRDn5q2eAWk0goAcSVhjwv1zPR38AfL/iypoI89uj31N9oiQnDGoeTbU2LOpQ1Gcl
RfhQt4zvPBjNxESOlEoD35ocuwPDSHxh546F4Co4=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.232.77] by pmq7v.m5r2.onet via HTTP id ;
Sun, 12 Sep 2021 16:29:10 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: Anthony Towns <aj@erisian.com.au>,bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <20210908075903.GA21644@erisian.com.au>
Date: Sun, 12 Sep 2021 16:29:08 +0200
Message-Id: <140049304-b536fa7b4b29a5afe6fe058ef76145cb@pmq7v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.77;PL;2
X-Mailman-Approved-At: Sun, 12 Sep 2021 14:42:36 +0000
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: Sun, 12 Sep 2021 14:34:23 -0000
> - 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
Anyone can do 1 block reorg, because nonce is not signed, so anyone can rep=
lace that with better value. For example, if you have block 00000086d6b2636=
cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with 0x0007f4cc nonce, yo=
u can replace that with 0x00110241 nonce and get 000000096a1c4239d994547185=
c80308a552cba85d5bd28a51e9dc583ae5eadb block, where everything is identical=
, except the nonce.
Sometimes that reorg could be deeper if you would be lucky enough to get a =
block with more work than N following blocks combined.
On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> 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.
Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.
> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.
And also for there to reliably be reorgs when they're not awake, which
might be a useful thing to be able to handle, too :)
> 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.
Being able to run `bitcoind -signet -signetacceptreorg=3D0` and never
seeing any reorgs should presumably make this not a problem?
For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
> # 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.
I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?
My feeling is:
- 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
- 2-3 block reorgs: good for testing the "your tx didn't get enough
confirms to be credited to your account" case, even though it barely
ever happens on mainnet
- 4-6 block reorgs: likely to violate business assumptions, but
completely technically plausible, especially if there's an attack
against the network
- 7-100 block reorgs: for this to happen on mainnet, it would probably
mean there was a bug and pools/miners agree the chain has to
be immediately reverted -- eg, someone discovers and exploits an
inflation bug, minting themselves free bitcoins and breaking the 21M
limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
bug that splits the chain, and the less compatible chain is reverted
(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
or something similar. Obviously the bug would have to have been
discovered pretty quickly after it was exploited for the reorg to be
under a day's worth of blocks.
- 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
getting >50% of miners organised took more than a few hours. This will
start breaking protocol assumptions, like pool payouts, lightning's
relative locktimes, or liquid's peg-in confirmation requirements, and
result in hundres of MBs of changes to the utxo set
Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?
I think sticking to 1-6 block reorgs initially is a fine way to start
though.
> After enough testing, the default SigNet can start to do periodical
> reorgs, too.
FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=3D0 don't
end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.
A quick draft of code for -signetacceptreorg=3D0 is available at =
https://github.com/ajtowns/bitcoin/commits/202108-signetreorg
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
