From: Karl-Johan Alm <karljohan-alm@garage•co.jp>
To: Varunram Ganesh <varunramganesh@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Date: Thu, 14 Mar 2019 10:17:31 +0900 [thread overview]
Message-ID: <CALJw2w51z+aLTx+nUpNaj20aqsga0kZNA5QcZqB-D9bkTKY6Zw@mail.gmail.com> (raw)
In-Reply-To: <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
<varunramganesh@gmail•com> wrote:
>
> 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.
For starters, I assume that the signer would run an automated script
that generated blocks on regular intervals without requiring manual
interaction. So even if the signer went on a vacation, the network
would keep on ticking. I also assume the signer would be running a
faucet service so users could get coins as needed. Ultimately though,
if a signer ended up vanishing or being unreliable, people would just
set up a new signet with a different signer and use that instead, so
ultimately it's not a big deal.
next parent reply other threads:[~2019-03-14 1:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
2019-03-14 1:17 ` Karl-Johan Alm [this message]
2019-03-13 9:15 Varunram Ganesh
-- strict thread matches above, loose matches on Subject: below --
2019-03-08 5:54 Karl-Johan Alm
2019-03-08 20:20 ` Matt Corallo
2019-03-10 0:43 ` Karl-Johan Alm
2019-03-10 17:01 ` David A. Harding
2019-03-12 5:44 ` Karl-Johan Alm
2019-03-13 3:23 ` Anthony Towns
2019-03-14 1:07 ` Karl-Johan Alm
2019-03-09 19:52 ` Lautaro Dragan
2019-03-10 1:02 ` Karl-Johan Alm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALJw2w51z+aLTx+nUpNaj20aqsga0kZNA5QcZqB-D9bkTKY6Zw@mail.gmail.com \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=varunramganesh@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox