Lunie: Show status if validator is tombstoned

[fedekunze]

Is your feature request related to a problem? Please describe.

as a user i'd like to see if a validator is tombstoned

Describe the solution you'd like

Get and display if the validator is tombstoned from the slashing_info, eg:

index_offset: "34790"
jailed_until: "1970-01-01T00:00:00Z"
missed_blocks_counter: "0"
start_height: "0"
tombstoned: false <--

Describe alternatives you've considered

Add a red cross (+ or x ) on the status, as we do it with the rejected proposals

[jbibla]

can you remind us how tombstoned relates to jailing?

[fedekunze]

jailing is just slashing + time that you can propose blocks. You can unjail it when the unjail period ends
tombstone is slashing + validator is banned from the network (can't come back to active set of validators)

[jbibla]

validator is banned from the network (can't come back to active set of validators)

woah. ok. what happens to the validators delegations? auto-undelegated?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jbibla]

we should probably add support for tombstoning.

[jbibla]

@mariopino this is type of status we can display the same way we display other status'

[jbibla]

hey @fedekunze is this still a thing in cosmoshub-3?

https://cosmos.network/docs/spec/slashing/07_tombstone.html

[fedekunze]

yeah, still exists

[jbibla]

if a validator is tombstoned, the undelegations / redelegations are not automatic? the user has to do these? will the validator accept me delegations?

[mariopino]

@mariopino this is type of status we can display the same way we display other status'

I'll check!

[jbibla]

we can add something on the li-validator as well in another PR

[fedekunze]

if a validator is tombstoned, the undelegations / redelegations are not automatic? the user has to do these?

no, they are not. Every delegator needs to submit them

will the validator accept me delegations?

The validator can still receive delegations (all Jailed validators can). Tombstoning is just a Jailed validator with the highest available JailPeriod (i.e until Dec 31, 9999 - 23:59:59 GMT)

[mariopino]

Some example queries to get the needed info from rpc:

https://stargate.cosmos.network/staking/validators?status=bonded&page=1&limit=1

[
  {
    "operator_address": "cosmosvaloper1qdxmyqkvt8jsxpn5pp45a38ngs36mn2604cqk9",
    "consensus_pubkey": "cosmosvalconspub1zcjduepqmq2l5ehgl3rxwjgzgr6sgzp69qwjl5ufvtyvacc9ms8p3phazl2qh3ulfw",
    "jailed": false,
    "status": 2,
    "tokens": "176483178197",
    "delegator_shares": "176483178197.000000000000000000",
    "description": {
      "moniker": "真本聪&IOSG",
      "identity": "8A79F44CC25D26DF",
      "website": "iosg.vc",
      "details": "To The Moon Then Cosmos. We are a crypto community and venture capital combined staking service provider"
    },
    "unbonding_height": "528965",
    "unbonding_time": "2019-06-24T19:55:42.604341211Z",
    "commission": {
      "rate": "0.100000000000000000",
      "max_rate": "1.000000000000000000",
      "max_change_rate": "1.000000000000000000",
      "update_time": "2019-08-05T07:24:32.572614545Z"
    },
    "min_self_delegation": "1"
  }
]

https://stargate.cosmos.network/slashing/validators/cosmosvalconspub1zcjduepq7mft6gfls57a0a42d7uhx656cckhfvtrlmw744jv4q0mvlv0dypskehfk8/signing_info

{
  "start_height": "0",
  "index_offset": "2273095",
  "jailed_until": "1970-01-01T00:00:00Z",
  "tombstoned": false,
  "missed_blocks_counter": "16"
}

Jailed validator:

https://stargate.cosmos.network/slashing/validators/cosmosvalconspub1zcjduepq5supzpux2jafyv06qw2dnd0fzshd2enmea9zeak9emu2ft5rs8nswzlqxf/signing_info

{
  "start_height": "0",
  "index_offset": "2",
  "jailed_until": "2019-06-01T14:55:22.603567975Z",
  "tombstoned": false,
  "missed_blocks_counter": "2"
}

[jbibla]

we're already getting some of this data - should be trivial to add jailed_until.

[faboweb]

Should we hide tombstoned validators or still show them?

[mariopino]

I think showing it as INACTIVE with the subtitle Tombstoned provides the user with all the information as we talked previously. In this case we probably want to display a warn to the user before delegate to a tombstoned validator, because it's possible to delegate to a jailed/tombstone validator (as discussed in https://github.com/luniehq/lunie/issues/1932).

This is another reason to show them: If we don't display tombstoned validator it makes impossible to delegate to this validator, althought this is allowed by the network (probably not convenient but allowed).

What do you think about that?

[faboweb]

I think in some cases we should be oppinonated about interacting with the networks. When there is no sane reason to delegate to a tombstoned validator, we shouldn't allow it.
A reason to show them in my head would be to prevent users from being confused that a validator is missing all of a sudden.

[mariopino]

I think in some cases we should be oppinonated about interacting with the networks. When there is no sane reason to delegate to a tombstoned validator, we shouldn't allow it.

Yep, I also was thinking in validator operators use case. Maybe in some circunstances would be useful to delegate to a jailed validator. I.e: if it's jailed period is about to end, althought I have to admit that it wouldn't be a common use case :-)

[faboweb]

That could be a usecase, true. But you would never delegate to a tombstoned validator right?

[fedekunze]

You shouldn’t hide them from the list because you want users to undelegate from them. Maybe just hide the delegate button ?

[faboweb]

So no hiding just marking them as inactive and giving the details: banned from the network. This is already implemented in the backend standardization PR.

[jbibla]

@fedekunze what happens if a user delegates to a tombstoned validator?

[fedekunze]

@jbibla it works as usual. You can still delegate to a jailed/tombstoned validator.