1363 reason field deregistrations

[darcys22]

Addressing #1363

Adds a decommission reason to the service node decommission votes.

[darcys22]

This should be ready for review, there will be additional reasons added after #1370 is merged.

Only query I had was regarding the hashing of the obligation dereg transaction. The code had previously backed out the state integer if it was a deregister. Should this remain as is after implementing the reason field:

  static crypto::hash make_state_change_vote_hash(uint64_t block_height, uint32_t service_node_index, new_state state)
  {
    uint16_t state_int = static_cast<uint16_t>(state);

    auto buf = tools::memcpy_le(block_height, service_node_index, state_int);

    auto size = buf.size();
    if (state == new_state::deregister)
        size -= sizeof(state_int); // Don't include state value for deregs (to be backwards compatible with pre-v12 dereg  votes)

    crypto::hash result;
    crypto::cn_fast_hash(buf.data(), size, result);
    return result;
  }

[jagerman]

Should this remain as is after implementing the reason field:

Yeah. The state change vote hash is meant to unique identify the (height, SN index, state) tuple. But prior to v12 there was no "state" parameter (we only had deregs) so if it's a dereg we just use the hash of (height, SN index). It's not necessary anymore, but if we change it now then the hash won't match up across different versions, so easier just to leave it.

[Azazel020]

The node on this server was expired so I updated the server to the latest version 8.1.5 and started the node . After some time the storage server crashed and the server went in decom. I received the notification from the bot, restarted the VPS and all services were up again. At that point I had enough blocks uptime credits to get reinstated by the network but ended in a decom. It seems that with the new version/qty of nodes the credit time with a new start (60+ blocks) isn`t enough to fix things.
Attached both log files.

log_oxen_node.txt
log_oxen_storage_server.txt

[darcys22]

Hi azazel, this thread is regarding an unimplemented feature and not the right place to post a bug report. However from those logs it appears that the storage server was not communicating with the network which would have caused the decom even if the node was submitting uptime proofs

[darcys22]

This should be ready to review now, updated to include the new timesync decommission reasons

[jagerman]

One suggestion from a community member which would be pretty nice to have:

Viewable on explorer is fine, maybe the node itself should be told, and it can report it under oxend status?

So instead of just showing "decommissioned" we could show something like

"decommissioned(storage)" or "decommissioned(uptimes,timesync,checkpoints)" or whatever our different reason flags are.

[darcys22]

Updated to print reason