Karl-Johan Alm [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-13 📝 Original message:Hi Varunram, On Wed, Mar ...
📅 Original date posted:2019-03-13
📝 Original message:Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
<varunramganesh at 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.
📝 Original message:Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
<varunramganesh at 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.