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
|
Return-Path: <michaelfolkson@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6D07EC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 13:05:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 48F5460EAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 13:05:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 jAQt_0QH-2lP
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 13:05:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
[IPv6:2607:f8b0:4864:20::b31])
by smtp3.osuosl.org (Postfix) with ESMTPS id 08DBD60BBC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 13:05:52 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id s16so3787181ybe.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 06:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=3dvNxeMK1Oa+6UKc32wzosdbsUlJ+HuG0F+evMQYKgE=;
b=poHV8AYg6I7IDqnrqtSJj4JsPKNCF1gHeO91iIi0Jz5h61tf62rCl5at6ZURxmWdxY
3N+LTfpryC9b6aqJo7RgaI2El1RFQoZn19SO9U/yTOHboqj7U7gRXVXOMCmx7JuAxElK
8n4itoSvXL0WaWQvTMtbhAw6GJPLvZzJtO57Pz7UzBuSDvp2fktnkjN9UwuAjAr2FK+J
eMhw7gFp+C0AUCmrFCOu70ylgKtCJ3/HWzDFNJOnuGpUxMuHBUVVLU9DIy5KlK96tUDO
6Vo5BEvmneAxSwKIC3lSsTv5z/sZnuoGkMF0KgP6szeaq9UhL0kUOCI/ifP1jkWX3lPe
8oxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=3dvNxeMK1Oa+6UKc32wzosdbsUlJ+HuG0F+evMQYKgE=;
b=6Wm1D+/j/Hlr+m6kQlrCIPmkoZQSua7NHASYqcyqeedf3rrsrTUYyexOdRzmgZXE+A
qqZX3VtZmV+M3N+1sKxuT8CaCej5yzdsmpeI2J27mKxWMxcZYqwkJMf4hT6vcEtYT3kP
Eiq3nTfWoTJxaZyejcawJ2UbSibayvjyvvpjhX90Lty8L3LEgPL5qiIUzuwyKaloaA7k
E33Yqd44XW7R8tMgOvncpcr2cetM2A1UJkqroQeyhLY3/az0iI1TgJ51vK9UfVuIiiN0
UViKNLmJ7jXipDG9sCRS/Tsyjk/+2GGYHJSh+eTo0yoPohAoiKwoigU0DuOWNFxx4KkV
cQAQ==
X-Gm-Message-State: AOAM530lFt1/DtG02FN2ZPQOPeJPVv+IjhPcold4T05nSIvnxMNvtbDp
8VgHjdKzGJj8GtkieeiH75nDIGBRVqjslCR2KWF4zlD2K8o=
X-Google-Smtp-Source: ABdhPJzFllzMdTpRfCZLIMW6IwtiHpRXhwqVs0SSNVt/5I3T1tFFP0l4upsm1yhsfRLmX7CmEZEo/gvNR5h7U6EFOuo=
X-Received: by 2002:a25:44d:: with SMTP id 74mr12064132ybe.54.1631279151718;
Fri, 10 Sep 2021 06:05:51 -0700 (PDT)
MIME-Version: 1.0
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Fri, 10 Sep 2021 14:05:40 +0100
Message-ID: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 10 Sep 2021 13:07:09 +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: Fri, 10 Sep 2021 13:05:54 -0000
> I see zero reason whatsoever to not simply reorg ~every block, or as ofte=
n as is practical. If users opt in to wanting to test with reorgs, they sho=
uld be able to test with reorgs, not wait a day to test with reorgs.
One of the goals of the default Signet was to make the default Signet
resemble mainnet as much as possible. (You can do whatever you want on
a custom signet you set up yourself including manufacturing a re-org
every block if you wish.) Hence I'm a bit wary of making the behavior
on the default Signet deviate significantly from what you might
experience on mainnet. Given re-orgs don't occur that often on mainnet
I can see the argument for making them more regular (every 8 hours
seems reasonable to me) on the default Signet but every block seems
excessive. It makes the default Signet into an environment for purely
testing whether your application can withstand various flavors of edge
case re-orgs. You may want to test whether your application can
withstand normal mainnet behavior (no re-orgs for long periods of
time) first before you concern yourself with re-orgs.
> 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 foll=
ow 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 w=
ill ever see.
If I understand this correctly this is introducing a need for users to
sign blocks when currently with the default Signet the user does not
need to concern themselves with signing blocks. That is entirely left
to the network block signers of the default Signet (who were AJ and
Kalle last time I checked). Again I don't think this additional
complexity is needed on the default Signet when you can set up your
own custom Signet if you want to test edge case scenarios that deviate
significantly from what you are likely to experience on mainnet. A
flag set via a configuration argument (the AJ, 0xB10C proposal) with
no-reorgs (or 8 hour re-orgs) as the default seems to me like it would
introduce no additional complexity to the casual (or alpha stage)
tester experience though of course it introduces implementation
complexity.
To move the default Signet in the direction of resembling mainnet even
closer would be to randomly generate batches of transactions to fill
up blocks and create a fee market. It would be great to be able to
test features like RBF and Lightning unhappy paths (justice
transactions, perhaps even pinning attacks etc) on the default Signet
in future.
--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
|
