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
|
Return-Path: <contact@varunram.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 24B1E30F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 09:15:26 +0000 (UTC)
X-Greylist: delayed 02:32:40 by SQLgrey-1.7.6
Received: from MTA-07-3.privateemail.com (mta-07-3.privateemail.com
[68.65.122.17])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9AC186F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 09:15:25 +0000 (UTC)
Received: from MTA-07.privateemail.com (localhost [127.0.0.1])
by MTA-07.privateemail.com (Postfix) with ESMTP id 1E64760051
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 05:15:25 -0400 (EDT)
Received: from mail-qk1-f173.google.com (unknown [10.20.151.233])
by MTA-07.privateemail.com (Postfix) with ESMTPA id 06F166004E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 09:15:25 +0000 (UTC)
Received: by mail-qk1-f173.google.com with SMTP id s26so614575qkm.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Mar 2019 02:15:24 -0700 (PDT)
X-Gm-Message-State: APjAAAUmktho5rWIx/GY/qVyrKp2NEGFo34uUggR62mHbbzFK5qzC3CH
tfGudwheUybXK7pkBAcaIoUvL7qGgAfL9gVQ1fc=
X-Google-Smtp-Source: APXvYqz/6IJH0331wp1iBiK+FfwzyOImCr6MadYm4NTwiE3DLo680ZChWwIrn9aoMUsk2XBHkf4INZzi+fjJKSpSq3w=
X-Received: by 2002:a37:d6ce:: with SMTP id p75mr12793374qkl.286.1552468524473;
Wed, 13 Mar 2019 02:15:24 -0700 (PDT)
MIME-Version: 1.0
From: Varunram Ganesh <contact@varunram.com>
Date: Wed, 13 Mar 2019 14:45:13 +0530
X-Gmail-Original-Message-ID: <CACJ+XmKFndz8JdqwftXtbQLdfexP8Eyt2q=LHu4fm2Gc4=Sodg@mail.gmail.com>
Message-ID: <CACJ+XmKFndz8JdqwftXtbQLdfexP8Eyt2q=LHu4fm2Gc4=Sodg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000ed3c1f0583f63e78"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 13 Mar 2019 09:50:01 +0000
Subject: Re: [bitcoin-dev] Signet
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 13 Mar 2019 09:15:26 -0000
--000000000000ed3c1f0583f63e78
Content-Type: text/plain; charset="UTF-8"
Hello Kalle,
I like your idea of a signet as it would greatly help test reorgs and stuff
without having to experiment with regtest. But I'm a bit concerned about
running a common signet (Signet1) controlled by a trusted entity. I guess
if someone wants to test signet on a global scale, they could spin up a
couple nodes in a couple places (and since it is anyway trusted, they can
choose to run it on centralised services like AWS). Another concern is that
the maintainer might have unscheduled work, emergencies, etc and that could
affect how people test stuff on. This would also mean that we need people
to run signet1 nodes in parallel with current testnet nodes (one could
argue that Signet is trusted anyway and this doesn't matter, still)
I'm sure you would have considered these while designing, so would be great
to hear your thoughts.
Regards,
Varunram
--000000000000ed3c1f0583f63e78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hello Kalle,<div><br></div><div>I like yo=
ur idea of a signet as it would greatly help test reorgs and stuff without =
having to experiment with regtest. But I'm a bit concerned about runnin=
g a common signet (Signet1) controlled by a trusted entity. I guess if some=
one wants to test signet on a global scale, they could spin up a couple nod=
es in a couple places (and since it is anyway trusted, they can choose to r=
un it on centralised services like AWS). Another concern is that the mainta=
iner might have unscheduled work, emergencies, etc and that could affect ho=
w people test stuff on. This would also mean that we need people to run sig=
net1 nodes in parallel with current testnet nodes (one could argue that Sig=
net is trusted anyway and this doesn't matter, still)</div><div><br></d=
iv><div>I'm sure you would have considered these while designing, so wo=
uld be great to hear your thoughts.</div><div><br></div><div>Regards,</div>=
<div>Varunram</div></div></div>
--000000000000ed3c1f0583f63e78--
|
