Discussion around HF semantics/Validator node maintenance

This conversation happened on a separate channel on 01/18/2018 ~8PM PST.

The discussion centers around what we should do if a Validator is unresponsive to a HF update request.

John, [18.01.18 18:55]
Interesting … if Michael doesn’t indicate he is going to update we can:

  1. Do nothing — but then the blockchain will fork into (2) chains ( we can fix by forcing parity to resync post HF )
    or
  2. Remove him from consensus before HF via Ballot, i.e. remove mining key ( assuming this will work )

Igor Barinov, [18.01.18 18:56]
[In reply to John]
2 - no need

John, [18.01.18 18:57]
ok. rationale?

Igor Barinov, [18.01.18 18:58]
Our goal is to make hardfork not to have 100% on the Hf

Igor Barinov, [18.01.18 18:59]
If majority is on HF it’s fine.

John, [18.01.18 19:14]
So a node that is not on the majority’s spec.json … is it a malicious node? or how does one qualify this node ( is it acting in best interest of network? )

Igor Barinov, [18.01.18 19:27]
[In reply to John]
It’s an offline node with noise traffic for the network, because it’s on different spec.json. Thus, it’s not a part of consensus

(Good conversation for the forum)

Sherina Yang, [18.01.18 19:29]
good to go on my end!
18: “509355”: {
19- “safeContract”: “0x03048F666359CFD3C74a1A5b9a97848BF71d5038”

1Proof_fan, [18.01.18 19:29]
Good work Sherina!

Sherina Yang, [18.01.18 19:29]
:+1:

Roman, [18.01.18 19:29]
perfect!

John, [18.01.18 19:30]
here is new validator node status:
1.- MoC - yes
2.- Roman - yes
3.- John - yes
4.- 1proof ( Validator SOKOL Chicago A ) - yes
5.- 1proof ( Validator SOKOL Chicago B ) - yes
6.- Rocco - yes
7.- Michael -no
8.- Melanie - yes
9.- Sherina - yes
10.- Stephen (hashguide) - yes

John, [18.01.18 19:31]
FYI, got an email from Michael that he is on it and will update ASAP

Roman, [18.01.18 19:31]
:+1:

Roman, [18.01.18 19:31]
thank you @johnny_thg

Roman, [18.01.18 19:33]
General guideline for forks: we only care of 51% of validators to update their spec.json, if some people cannot, they will simply not be mining the network after HF. If 51% not reached by the time of HF, I believe it will still be mining the old chain and wait when all miners will agree on new chain(programatically agree)

Jeff Flowers, [18.01.18 19:36]
I’m needing to complete onboarding and promise to asap :+1:

Sherina Yang, [18.01.18 19:37]
What happens to the miners who don’t HF? If they don’t mine on the new chain, they continue to line on old chain?

Roman, [18.01.18 19:37]
[In reply to Jeff Flowers]
Jeff, you are not miner on sokol :blush:

Roman, [18.01.18 19:38]
[In reply to Sherina Yang]
correct

Jeff Flowers, [18.01.18 19:38]
I just submitted my keys.

Roman, [18.01.18 19:38]
like what happened last time with Rocco

Roman, [18.01.18 19:38]
[In reply to Jeff Flowers]
what do u mean?

Jeff Flowers, [18.01.18 19:38]
I feel bad.

Roman, [18.01.18 19:38]
where did you submit it? why do u feel bad?

Jeff Flowers, [18.01.18 19:38]
I generated and sent John my keys just recently. :wink:

Roman, [18.01.18 19:39]
ok, we will vote for you after HF

Jeff Flowers, [18.01.18 19:39]
I think it’ll get done tomorrow at the latest

Jeff Flowers, [18.01.18 19:39]
At a UX conf at the moment.

Sherina Yang, [18.01.18 19:39]
Oh got it - will there be updates for the old miners to eventually get back on the HF chain?

Roman, [18.01.18 19:39]
[In reply to Jeff Flowers]
man, no rush :blush:

Roman, [18.01.18 19:39]
[In reply to Sherina Yang]
of course, we already had this situation with Rocco last time

Jeff Flowers, [18.01.18 19:39]
:+1:

Roman, [18.01.18 19:40]
he simply updated spec.json

Roman, [18.01.18 19:40]
and became a miner on new chain again

Rocco Mancini, [18.01.18 19:40]
It was a pretty easy fix.

Sherina Yang, [18.01.18 19:40]
Gotcha

Sherina Yang, [18.01.18 19:41]
No man (woman) left behind!

John, [18.01.18 20:02]
does network performance degrade if we don’t have 100% on same chain

John, [18.01.18 20:03]
?

1Proof_fan, [18.01.18 20:03]
Yes… we lose 1/N validator power…

Igor Barinov, [18.01.18 20:03]
[In reply to John]
Network degradation is not a critical problem

1Proof_fan, [18.01.18 20:03]
also true.

John, [18.01.18 20:04]
average block time and through put not impacted?

Igor Barinov, [18.01.18 20:07]
impacted

Igor Barinov, [18.01.18 20:07]
but it’s not critical

1Proof_fan, [18.01.18 20:08]
if 10 validator nodes are authorized to exist, and 1 node does not fork, 1 out of 10 of validators is not available for validation, until it does fork. As Igor says this have very low to no impact at the moment since there are few transactions. In this example, every 10th round-robin valiation attempt will not happen. Does not cause network failure, only potential slight delay.

Igor Barinov, [18.01.18 20:08]
Because you have 48 hours or less to restore the normal state

Igor Barinov, [18.01.18 20:10]
48 hours to remove validators… Less - to explain to a validator that his behaviour impacts network performance

1Proof_fan, [18.01.18 20:10]
:+1:

Igor Barinov, [18.01.18 20:10]
We will replace aura one day to another algorithm… but for now it works this way

John, [18.01.18 20:16]
Yes, I understand the nuance but thought would be intertesing avenue to go down as part of the “maintaing your node” responsibility of a Validator

1Proof_fan, [18.01.18 20:18]
I see. John, you a suggesting creating a “Consquences of not maintaining your node” document, is that the idea? I think this a good idea, at least at some point.

John, [18.01.18 20:25]
Take a look at:

Let’s come up with a reliable HF process here that doesn’t result in fire drills :slight_smile:

Catching up on the Telegram support channel, HF2 fork was proposed and agreed upon by several on the support channel at 2:12pm, scheduled for 9pm. Problem is, validators might not get a chance to see this. Worst yet, they might not be able to access the secure console within such a short time period. We need to plan HFs ahead of time and we need a separate push notification mechanism when specific actions are required from validators.

Suggest we have a 1 business day announcement and send those as PMs to validators, so they are sure to notice. Even better if we can SMS the validators (their cell #s should be kept secret though, so they don’t get a ton of unsolicited calls).

Thoughts?

Thanks, MM

1 Like

Speaking for myself, I do not monitor Slack or Telegram ever, having at least a dozen channels in each. If you want to reach me reliably, better email.
However, I would not care to get an SMS, potentially in the middle of the night, in whatever timezone I am that week. Unless it’s a true emergency, like a security breach requiring immediate attention.

1 Like

For P2/S2 issues (and lower) we could always schedule and SMS to be sent between 10am and 10pm for validator’s timezone. It would also be an option, others being email, telegram, slack.

P1/S1 would go out immediately, flagged Critical. Those I expect to be rare, limited to increased risk of compromise network.

-MM

I like the idea of SMS for critical items. Slack, Telegram, email could be too crowded (at least for me). SMS is a legacy and not used, so it easy to see this message.

Although I constantly monitor validator chat, so if there is a need for action (in advance) that would also be OK.