Rename revoke/unrevoke to jail/unjail

[adrianbrink]

unrevoke sounds extremely confusing, since you are unbonded and not revoked. Also unrevoke needs documentation in the --help.

[rigelrozanski]

hmm okay let's think of a better name, however rebond isn't accurate because when you unrevoke you may not actually be able to rebond if you're nolonger in the top 100

[rigelrozanski]

Here are some more ideas:
revoke -> suspend / pause / lock
unrevoke -> unsuspend / resume / unlock (maybe reinstate?)

Thoughts? CC: @cwgoes @jackzampolin

[cwgoes]

Hmm, how about jail / unjail - that way we can say that a validator is jailed, which is nicely evocative.

[rigelrozanski]

haha yeah I'm good with jailed - it's nice and intuitive. Also then we can turn the CLI into a monopoly game. Go directly to Jail. Do not pass Go. Do not collect $200.

[jackzampolin]

+100 for CLI monopoly. Lets take this to jail. I would imagine that this needs to get changed a couple of places. I'll rename this issue to reflect this decision.

[jbibla]

i don't understand what you guys are talking about.

could someone elaborate the use case for this soon-to-be-decided verb?

[cwgoes]

could someone elaborate the use case for this soon-to-be-decided verb?

Renaming an existing state ("revoked") to a new name: "jailed" - and updating the CLI/API to match.

[jbibla]

ah ok - we're talking about the validator states. but i still don't understand the use case.

why do we ever have to say "unrevoke" or "unjail"? is that a tx type or something? once a validator is revoked or in jail - what are their options / what are the actions required / what will they do about it? and how does this affect their delegators?

[rigelrozanski]

@jbibla you are correct - getting out of jail requires a transaction (currently gaiacli stake unrevoke), if you have been pushed out for liviness faults (or any number of faults), it is up to you to decide when you have a stable setup and are ready to join back into the validator set - once you're validating again you are liable once again to get slashed.

what are their options / what are the actions required / what will they do about it

• determine the root cause of their fault and fix it
• communicate with their delegators to minimize delegators leaving them
• participate in any out-of-band solutions they may have set up with their delegators (aka maybe they want to pay delegators back for a slashing if they're really nice validators)
• wait until the minimum jail time passes and then send an unrevoke aka unjail transaction then continue normal operation

how does this affect their delegators?

delegators will be begin unbonding with their validators once jailed. The delegators can wait for their validator to unjail and join the validator set again, OR a delegator could choose to instantaneously re-delegate to another validator. Note that currently (and probably for a while post launch), delegators can only redelegate once per unbonding period, so if the delegator delegated to a new validator which then ALSO gets slashed, they would lose out double and just have to wait for the new validator to come back online

[jbibla]

thanks @rigelrozanski that's very helpful.

is being revoked fundamentally separate / different from being slashed?

since this relates to uptime - i would suggest using down and up in some way to indicate the state / status and the tx required... has that been considered?

[rigelrozanski]

is being revoked fundamentally separate / different from being slashed?

interesting - well they are actually tightly coupled. If I'm not mistaken every instance of being slashed also comes with some jail time, although this is configurable and doesn't necessarily need to be this way. Fundamentally, being slashed is having bonded stake burned, while as being jailed is just being forced out of the bonded validator group (shifting your tokens to the unbonding state) independent of whether you have had any tokens burned simultaneously. - There may be a common subset concept here... not sure though (CC @cwgoes )

since this relates to uptime - i would suggest using down and up in some way to indicate the state / status and the tx required... has that been considered?

Being jailed applies much more broadly then when you have a liviness fault - if you double sign for instance, you also are jailed (and I think for a considerably longer period) - thus I think we should keep jail / unjail

[cwgoes]

Fundamentally, being slashed is having bonded stake burned, while as being jailed is just being forced out of the bonded validator group (shifting your tokens to the unbonding state) independent of whether you have had any tokens burned simultaneously.

They're not necessarily tied - at the moment, for both currently instantiated slashing conditions (downtime & double-signing), we both burn tokens and jail the offender. We could elect to only burn tokens or only jail if desired.

[rigelrozanski]

@cwgoes yeah I mean the concepts are clearly distinct but do they really need to be? Do you have any (/many) particular circumstances in mind where we would really want to only one or the other? If I'm not mistake the most cases (and the only case we're currently using) includes slashing and jailing simultaneously. - I think there may be a few edge cases which only includes one or the other, in which case, if we did decide to couple jailing and slashing into a single "thing" we could always include logic for those edge cases to still allow for jailing without slashing or vise versa.

I'm starting to form the opinion that reducing the number of distinct concepts required at the highest level will be beneficial for dev comprehension. For instance we could just call this common object a penalty which includes a fine and some jail time - however still allows for a fine with no jail time or vice versa.

Just a thought

[jackzampolin]

I'm starting to form the opinion that reducing the number of distinct concepts required at the highest level will be beneficial for dev comprehension. For instance we could just call this common object a penalty which includes a fine and some jail time - however still allows for a fine with no jail time or vice versa.

I want to +100 this. I think that a penalty concept could encompass this and be much easier for devs and users (our Validators are just operators) to wrap their minds around.

[jbibla]

fine + jail makes sense to me now. if you guys think grouping the concepts under a penalty is even better - that also sounds great. simple, straightforward, self explanatory. better than revoked/unrevoke for those reasons.

sorry for accidentally closing this issue 😄

[cwgoes]

fine + jail makes sense to me now. if you guys think grouping the concepts under a penalty is even better - that also sounds great. simple, straightforward, self explanatory. better than revoked/unrevoke for those reasons.

I think we want to retain the flexibility of separate concepts in the state machine, as they have different effects on validator incentives and fee distribution, but if we want to summarize them as a "penalty" in the UX/docs level that seems fine.

[rigelrozanski]

Let's do that

[jackzampolin]

Reopening pending implementation

[cwgoes]

Reopening pending implementation

Thanks, a minor case of overenthusiastic Github automation I think.