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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 83563C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 19:22:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with UTF8SMTP id 5F9A9414BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 19:22:06 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id LUdwWYOnlwYZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 19:22:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [IPv6:2620:6e:a000:1::99])
by smtp4.osuosl.org (Postfix) with UTF8SMTPS id 18567414CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Sep 2021 19:22:05 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 4H5m2y3qbGz123Jr;
Fri, 10 Sep 2021 19:22:02 +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=1631300464; t=1631301723;
bh=fJvTAoeXSZ+oRc/OxORos+7TiddM9XDXRXpwnF0FkpA=;
h=Subject:To:Cc:References:From:In-Reply-To:From;
b=HTJdew6nbY9qWaoAyMocItln2S2JCDg9D+ratkamZ+YuJtdj0dL6QyKo7CTmnJJQG
QlOwwCG3LuWfAP3i+cmI0XQysg+WVL3fVLYOPKKItO2F5YVfBdiGWgnzQ80F+blI0y
IQfPCIkMp/+hIPHUajhL/MBxL1MdJwtY+gp+ZCeRcsAXiUR1ziAOdo4hY7CVnM8kQo
XG+cHVuA4snu91liBCOyBDP2JWyyh4IF/cpYiFT2UylelRi3s0RiLKGQYqpkTFzSbH
18pAfuPCqEsORdnKK4cCk8FKniVZZHEEzKaQRNh/v7ClHKm/nNRH3G3f1p1u6/ZWlf
kLYvYRDr3QDyg==
Message-ID: <966de823-557a-ad71-68b3-c9c8938e60e5@mattcorallo.com>
Date: Fri, 10 Sep 2021 12:22:00 -0700
MIME-Version: 1.0
Content-Language: en-US
To: Michael Folkson <michaelfolkson@gmail.com>
References: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.gmail.com>
<50970c07-b447-0b49-3f2b-b8a4961761f1@mattcorallo.com>
<CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 19:22:06 -0000
Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this
is a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).
On 9/10/21 12:00, Michael Folkson wrote:
>> 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.
>
> I guess Kalle (and AJ) can answer this question better than me but my
> understanding is that the motivation for Signet was that testnet
> deviated erratically from mainnet behavior (e.g. long delays before
> any blocks were mined followed by a multitude of blocks mined in a
> short period of time) which meant it wasn't conducive to normal
> testing of applications. Why would you want a mainnet like chain? To
> check if your application works on a mainnet like chain without
> risking any actual value before moving to mainnet. The same purpose as
> testnet but more reliably resembling mainnet behavior. You are well
> within your rights to demand more than that but my preference would be
> to push some of those demands to custom signets rather than the
> default Signet.
Huh? You haven't made an argument here as to why such a chain is easier to test with, only that we
should "match mainnet". Testing on mainnet sucks, 99% of the time testing on mainnet involves no
reorgs, which *doesn't* match in-the-field reality of mainnet, with occasional reorgs. Matching
mainnet's behavior is, in fact, a terrible way to test if your application will run fine on mainnet.
My point is that the goal should be making it easier to test. I'm not entirely sure why there's
debate here. I *regularly* have lunch late because I'm waiting for blocks either on mainnet or
testnet3, and would quite like to avoid that in the future. It takes *forever* to test things on
mainnet and testnet3, matching their behavior would mean its equally impossible to test things on
mainnet and testnet3, why is that something we should stirve for?
> Testing out proposed soft forks in advance of them being considered
> for activation would already be introducing a dimension of complexity
> that is going to be hard to manage [0]. I'm generally of the view that
> if you are going to introduce a complexity dimension, keep the other
> dimensions as vanilla as possible. Otherwise you are battling
> complexity in multiple different dimensions and it becomes hard or
> impossible to maintain it and meet your initial objectives.
Yep! Great reason to not have any probabilistic nonsense or try to match mainnet or something on
signet, just make it deterministic, reorg once a block or twice an our or whatever and call it a day!
Matt
|
