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: <lf-lists@mattcorallo.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0CF28C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 18:24:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with UTF8SMTP id E32BE401E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 18:24:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5
tests=[BAYES_50=0.8, 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: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id 62SWLQEgdGMM
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 18:24:21 +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 smtp2.osuosl.org (Postfix) with UTF8SMTPS id A9939402D8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 18:24:21 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 4H5kmK6c9hz1239w;
Fri, 10 Sep 2021 18:24:17 +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=1631296864; t=1631298258;
bh=DMtx1cHCKsrr9dZXvSLxNqzkcaAU+EMe9ip6uW+fF5U=;
h=Subject:To:References:From:In-Reply-To:From;
b=k6heEQUXBh4WxxtTnRFx/C4bZy8kSXDMVmeG/W0gk11xLbSv2ryldqlNk0eh47k4c
iiM/BhjogzThHrjltgu29P2TXsrUoznfLdlqQ+RkRoV8K/C0lEkY36Ni7fsmNjk3QK
Rusabl2tmkDVBika8T9HEErdZ8YDV4rTmY6x0AWKx8n8OMniMudciZz5zPlpbE4dEK
DG0HKEenv1bU8Ut1WUak/GJG/PHt64cy138U0U08bebCwUrsc0gfmoIVLIuXqxZtVt
8zewEbUR5xS0Ep7qsCLycXTFvL5ig3FfHXNzbX/CLag4Y2FOsfkkMMEDqhRQx3a2gF
EZ4Bs4pIwmgCQ==
Message-ID: <50970c07-b447-0b49-3f2b-b8a4961761f1@mattcorallo.com>
Date: Fri, 10 Sep 2021 11:24:15 -0700
MIME-Version: 1.0
Content-Language: en-US
To: Michael Folkson <michaelfolkson@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.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 18:24:23 -0000
On 9/10/21 06:05, Michael Folkson wrote:
>> 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.
>
> 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.
Huh? Why would the goal be to match mainnet? The goal, as I understand it, is to allow software to
use SigNet without modification *to make testing simpler* - keep the header format the same to let
SPV clients function without (significant) modification, etc. The point of the whole thing is to
make testing as easy as possible, why would we do otherwise.
Further, because one goal here is to enable clients to opt in or out of the reorg chain at will
(presumably by just changing one config flag in bitcoin.conf), why would we worry about making it
"similar to mainnet". If users want an experience "similar to mainnet", they can simply turn off
reorgs and they'll see a consistent chain moving forward which never reorgs, similar to the
practical experience of mainnet.
Once you've opted into reorgs, you almost certainly are looking to *test* reorgs - you just
restarted Bitcoin Core with the reorg flag set, waiting around for a reorg after doing that seems
like the experience of testnet3 today, and the whole reason why we wanted signet to begin with -
things happen sporadically and inconsistently, making developers wait around forever. Please lets
not replicate the "gotta wait for blocks before I can go to lunch" experience of testnet today on
signet, I'm tired of eating lunch late.
>> 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.
>
> 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.
I believe my suggestion was not correctly understood. I'm not suggesting *users* sign blocks or
otherwise do anything manually here, only that the existing block producers each generate a new key,
and we then only sign reorgs with *those* keys. Users will be able to set a flag to indicate "I want
to accept sigs from either sets of keys, and see reorgs" or "I only want sigs from the non-reorg
keys, and will consider the reorg keys-signed blocks invalid"
Matt
|
