Cosmos-sdk: gaiacli stake signing-info not updating after block 10k, even though node is still signing

Created on 28 Jul 2018  路  4Comments  路  Source: cosmos/cosmos-sdk

Summary of Bug

gaiacli stake signing-info not updating after block 10k, even though node is still signing.

I have a validator on gaia-7003 signing since the validator block (although starting_height has always read '2').

Running gaiacli stake signing-info cosmosvalpub1zcjduepqzcsjtmd00g66dqmf28uejh6y90l26w2930nxjfz036qy2y5qtzyqumqjvp returns:

Start height: 2, index offset: 10945, jailed until: 0, signed blocks counter: 9998

At index_offset 10,000, the signed blocks counter was 9,998, but has not increased since - even though I am still signing (node logs show no problem, at blocks at or around 10,000-10,008, or since, AND querying http://localhost:26657/commits=height=X for random blocks between 10k and current height, shows that I am signing these blocks).

Steps to Reproduce

Run node on gaia-7003 since Genesis until after block 10k (nothing special to replicate).


For Admin Use

  • [ ] Not duplicate issue
  • [ ] Appropriate labels applied
  • [ ] Appropriate contributors tagged
  • [ ] Contributor assigned/self-assigned

Most helpful comment

You are right @KamuelBob - despite me spending last week playing with this very code, I didn't clock that this signed blocks counter is a count of the number of blocks signed in the last window.

This isn't a bug. Closing!

All 4 comments

This appears to affect other validators too.

@adrianbrink 's validator shows the following:

gaiacli stake signing-info cosmosvalpub1zcjduepq5fsr8wy6dnc2tal7ywpdfw8sjrpuc8mh82mr0j6lqzx4jazpw4kqsrrxsv
Start height: 2, index offset: 11029, jailed until: 0, signed blocks counter: 10000

Edit: This appears to affect all validators (at least, every one of the ten or so active validators I checked)

Appears to be showing a rolling 10,000 block snapshot as b-harvest reporting that their number of signed blocks is decreasing. 9973 -> 9972 -> 9969.

This means as soon as this variable drops below 5000, the validator would be revoked and slashed.

The calculation makes sense but it's not the expected output of this variable from an intuition point of view. Dev expectation may be another story.

You are right @KamuelBob - despite me spending last week playing with this very code, I didn't clock that this signed blocks counter is a count of the number of blocks signed in the last window.

This isn't a bug. Closing!

Oh.. is it closed?
I just post this new strange thing about signing-info.
When latest_block_height is 18684, below are the results of signing-info with height flag
--height=18611 is OK
--height=18580 is error (_panic: UnmarshalBinary cannot decode empty bytes_)
--height=10000 OK
--height=0 OK
--height=10001 error
--height=15000 error

it seems that signing-info works for height between currentheight and currentheight-100
OR, height is dividable by 10,000.
This is very unconfortable because, i cannot pull count of missing vote during certain period
(from height A to height B).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

adrianbrink picture adrianbrink  路  3Comments

ValarDragon picture ValarDragon  路  3Comments

rigelrozanski picture rigelrozanski  路  3Comments

johnmcdowall picture johnmcdowall  路  3Comments

ValarDragon picture ValarDragon  路  3Comments