Delegate / Witness Resignation about bitshares-core HOT 8 CLOSED

Seems fairly important that they be able to resign if they want. Do we need it for launch -- not so sure.

from bitshares-core.

From @nathanhourt on July 7, 2015 20:41

I definitely want witnesses to be able to resign. The logical way to do this is to set their block producing key to null. It would also be nice if they could un-resign by setting it again. If a witness's owner decides to go on vacation or something, he might not want to/be able to maintain his node, so it would be desirable if he could disable his node while he's away, then re-enable it when he returns. I'd like to have this working for launch.

It seems less necessary that delegates be able to resign, but we might as well allow it. I don't see as clear a reason delegates should be able to un-resign, though.

Since we're on the topic, do we allow workers to resign? If we want to allow all three to resign, it might be worth implementing this at the voting level, allowing the owner of a votable entity to withdraw that entity from contests, and later re-enter it.

from bitshares-core.

From @VoR0220 on July 8, 2015 2:31

49fb41c440339121a066a33dc97069a5144bdf93

a152351766b8710554c531888aef2bf342bd9aef

I made these commits in my forked repo. I wasn't super positive in terms of where to start in terms of setting up an outline of where to attack, so I made two and hoped that one of them might be a useful place. Let me know if they're helpful and I'll create a PR.

from bitshares-core.

From @arhag on July 8, 2015 4:28

Please consider this: https://bitsharestalk.org/index.php/topic,17308.0.html

from bitshares-core.

From @ThomasFreedman on July 8, 2015 14:11

Nathan wrote: " If a witness's owner decides to go on vacation or something, he might not want to/be able to maintain his node, so it would be desirable if he could disable his node while he's away, then re-enable it when he returns. I'd like to have this working for launch."

What is meant by "witness's owner" ? Also, allowing witnesses to come and go may lead to instability of network. Would "the next standby" be signing block in his own delegate name or in the name of the delegate his substitutes for? This discussion should be brought into the forums for broader perspective. As a current delegate, I think this isn't good for the ecosystem, but do recognize the convenience it provides. Just don't believe that's worth the risks.

from bitshares-core.

From @ThomasFreedman on July 8, 2015 14:20

As to resigning, I think some automatic measures should be built in, like firing a witness if they miss X number of blocks. Translate blocks to time, the limit should not be more than a day or 2.

Obviously if a worker / witness / delegate no longer desires or is able to perform their duties, the network should provide a way to facilitate a replacement as fast and efficiently as possible. In the case of delegates I see no urgency, and they can be replaced through voting schedule / mechanism. Workers and witnesses require more care, and shareholders definitely need to be involved. For witnesses the issue is the most urgent, but again with the numbers involved (who knows how many will be required in 2.0, and how that will be determined as a function of growth and network security), perhaps not all that urgent either.

from bitshares-core.

From @nathanhourt on July 8, 2015 15:22

@ThomasFreedman A witness is a server which connects to the network and produces blocks. The person running that server/controlling the private keys is the witness's owner.

The point of having protocol support for disabling a witness without sacrificing its approval rating is to prevent instability. A witness can be disabled, at which point it will not be eligible for election at the next maintenance interval, and the next runner up will be elected instead. If the witness is re-enabled, and still has sufficient approval to be elected, he will be elected again at the next maintenance interval.

The problem is that runner-ups may not have nodes online when they get elected. We could either regard this as worst practice and recommend stakeholders withdraw approval of this witness, or we could require unelected candidates to submit a ticket proving their nodes are online prior to the maintenance interval at which they may be elected. If no ticket is submitted, they will not be eligible for election. I do not think this feature is important enough to delay launch, but it's something to consider for the future.

from bitshares-core.

Not happening

from bitshares-core.