missing uptime

[hasty remnant]

Thanks for keeping us informed 👍 🔥
Please solve the problem with sending tasks of the S class for crew members, It’s been showing an error for 2 weeks now : "User is not SE partisipant"
Thanks!

[lament quest]

please make S, B and C class missions more transparent

we want to be able to see how many points an user has received from which task

[upper cradle]

agreed! we're going to publish the spreadsheet of what's been awarded points or not, pls stand by

(oh and fyi, no S Class points have been added to the Nebb yet!!)

[modest axle]

is there any feedback on why most post-genesis (with only very few exceptions) are not tracking their uptime and validator efforts on the nebb?

[upper cradle]

@modest axle my understanding is that uptime on Nebb is calculated this way:
(all signed blocks by a validator) / (total blocks)

so if you're in the active set for a short period of time relative to the life of the chain, then your uptime will be reported as negligible

[lament quest]

our profile photo is also not visible, probably because we could not match our nebb profile with our validator

How can we do this?

I appreciate you answering our questions!

[coarse mica]

as said before, this type of calculation is not fully fair in the conditions when we have a closed channel that gets info faster than others, also they literally had two additional active epochs (as pre-gen)
e.g. that silent restart put into jail everyone who didn't know that the chain was running already with consequent jail for 2 epochs
described in my recent two posts:

• #🫂︱se-community-support message
• #shielded-expedition message
  so, if the whole competition continues for 1-2 months such downtime can be negligible, otherwise, it is again a bonus to pre-genesis guys
  just an example: 1 month of 5s blocks = 518400 blocks, 95% uptime is a miss of 25920

[tranquil bane]

liver23 has been warned

Reason: Posted a link

[coarse mica]

usual uptime is based on block_window, this is how Cosmostation guys calculate it in their tool: h ttps://cosmostation.github.io/namadatools/
so, you need to be in active set with a stable environment with low number of missed blocks per window

[modest axle]

i've been in active set long enough that I should be well above zero. so have several others. we are wondering if the memo tag is sufficient to tag the validator tnam though on init-validator

[modest axle]

this right here. genesis have massive advantages.

[modest axle]

that's a good point, that could be connected to the lack of tracking

[upper cradle]

i think we've discovered an issue with uptime reporting, pls stand by (could be tomorrow, core devs are in CET)

[modest axle]

awesome

[upper cradle]

okay so on yesterday's validator call, Gian (Fraccaman) checked and it's likely that people experiencing this did not init_validator with the identifying info in the memo field, which is essential for the software to track (even after consensus key changes!)

@modest axle @lament quest could this be the case for you?

[modest axle]

nope we did do that. or at least I did. on second regenesis. which is all that should count. 100% I had the memo field there.

could the issue be that the memo-field isn't propagated further when the init-validator creates several new subcommands, and the transactions that actually create the tnam which will be used for validator won't have the memo-field attached, so that nebb/you guys won't have any way to connect our validator tnam to our public key? or is that done by looking up pk anyways and thus not an issue?

that was convoluted sorry lol

as you can see above, I am extremely concerned what it means in practice if we need to reinit. both in terms of our already bonded naan and losing our entire uptime already. A more workable way might be to simply collect our validator addresses manually if they can't be automatically connected to our implicit tnam

[lament quest]

I don't remember, I inititated my validator in the first blocks and at that time there was no information about the memo field

[modest axle]

that's first genesis though?

which shouldn't be relevant?

new role, who dis

[upper cradle]

@hasty remnant are you sure that you are submitting from an account that was registered in the original Shielded Expedition signup?

[modest axle]

and more fair for the competition even if it's a bit of a pain for team to collect

[upper cradle]

okay pls stand by (and sorry for the delay replying, i was mostly away yesterday)

[modest axle]

@wraith glen just tagging you here too - if I recall correctly you said you did everything right there too. so proposed fix is unlikely to fix anything regardless of the issues arising from it

[wraith glen]

Faya and thunda!

Yes, I've memo'd all my inits. Never forgot to do this.

(I did once for a bond transaction 😥)

[modest axle]

I'm sure the nebb is forgiving if you send another one 🙂

[coarse mica]

also, submitted init with memo, two times 😄 when the restart happened

[upper cradle]

okay core devs are asking for a document for each person with missing uptime so that they can further investigate

do we feel comfortable posting these here?
player id (tkpnam1) -> namada validator address (tnam)

missing uptime

[wraith glen]

tpknam1qz36mzdvdmxvvcpv3c36zzs5v369jauws0tzrxesuaexy0p25r5sy0jsuac -> tnam1qy6sfh87d4uy0d8mcc9gww5h0pctxvf0m5vdgw2c

[modest axle]

not sure, do we? 🙂

tpknam1qqtyg8u8g3z89axzxhcv2aq9209lqsn88vnetphsqdxhyjx3v7c9qnpznsc -> tnam1qyanxt2m6sqcgupl3vsh7d4ryqdtn0uv5vfu0xwr

if you mark when you've copied over I'll remove again

[coarse mica]

tpknam1qqkwe6wghcfg2vjn99c8cqeaxv59nfnr67w6sph4f4ejelyjk7dykdjlplh -> tnam1qxzx92ztwjmtka0mdfd60wn7ejcljgx6sqe4800u
I was in jail 2-3 times I guess, while playing with consensus key changing, and during first late restart

[lament quest]

tpknam1qrflwggnn9g4wp6p8u63nvte6y7nf9xr2cwqsvltgvauxl9s4nmw7476fnl -> tnam1qx5ycpg52w796hn33vsdfna6nqx42kryxsxvxtfs

[slender abyss]

tpknam1qpr9k2cus3suzqa0vfy5xasd96ayerk33rryn8qw5mtt2n6fw05a7997t90 -> tnam1qxuf2l6fkn4exujc90jn8k44gmtkl94l2y3jj04a Was in consensus set for two epoch before being jailed for changing consensus key. Have two different conseneus keys associated with the above validator address and for the original one, should have uptime reflected for two epochs

[wraith glen]

I think we also need @still nacelle here as an "edge" case. You were post genesis but did see uptime, right?

[modest axle]

yes his is interesting

[wraith glen]

I was thinking maybe he did a become-validator transaction with previous consensus keys after the first halt, but never asked 😅.

[modest axle]

we have speculated that but think he disconfirmed

[still nacelle]

What's up! Yep, I am post-genesis and my uptime counts

You can check my transactions on extended-nebb, I was also wondering if I did something different, but it seems like everyone goes the same path.
init acc
bacome val
bond
And if you see transaction on extended-nebb it means that you've included --memo

[wraith glen]

We're gathering tpknam player ID -> tnam val addresses for the devs to research this, would you be so kind as to share yours :)?

Yours should be labeled special case though

You feeling how special you are now?

[still nacelle]

I've not done anything special. I just did those 3 steps above, after first chain halt I did not need to unjail, as I was not jailed and then eventually I got into consensus set and since then my uptime counts. I suspect that it is something in the Nebb's backend

[coarse mica]

not always, I definitely have memo in each, but from Feb, 14 don't see any new tx

[still nacelle]

So my player address: tnam1qptpw59jf40nwatcpgpu02wkcpwh5ajapues8qly
public key tpknam1qr3u70ng268u5fw4wsuzwrnksexlgc4w47dtq22lzgyqhhj3ec0tq892se4

My validator address:
tnam1q9m8fe30clslts7fg6q8s0v9u2wsgymqtue9rhgr
And I am "labisque" on the Nebb

Yeah, I see. It's weird, but you are not alone. Encipher is top 6 with one tx only. Legend 😄 @coarse mica

[upper cradle]

what's the tpknam for validator?

[still nacelle]

Hmm, I am not sure where to look for it.

What I get for my validator alias:

namadaw find --alias labisque
Found transparent address:
  "labisque": Established: tnam1q9m8fe30clslts7fg6q8s0v9u2wsgymqtue9rhgr

And for my wallet:

namadaw find --alias main
Found transparent keys:
  Alias "main" (encrypted):
    Public key hash: 561750B24D5F3775780A03C7A9D6C05D7A765D0F
    Public key: tpknam1qr3u70ng268u5fw4wsuzwrnksexlgc4w47dtq22lzgyqhhj3ec0tq892se4
Found transparent address:
  "main": Implicit: tnam1qptpw59jf40nwatcpgpu02wkcpwh5ajapues8qly

[tranquil bane]

liver23 has been warned

Reason: Posted a link

[coarse mica]

h ttps://cosmostation.github.io/namadatools/
a lot of validators are with blank uptime, nvm pre or post-gen seems

[silk pumice]

Oh we had a bug now ! Validators who ve been not having any miss, zero missed, are not showed in our app we will fix today!

If you are developer, you can call this api too
https://api-namada.cosmostation.io/validator_siging_infos

[silk pumice]

Let me invite you to check your epoch uptime for your validator node
https://cosmostation.github.io/namadatools/

[wraith glen]

Dope!

Lol I got 99.99% 🤯, missed 1 block.

[silk pumice]

Look so good to see your validator. don't forget it's only couting for this epoch! actually, you only consider it for liveness slashing

[lament quest]

100.00% 😎

idk why

but its cool

[upper cradle]

added to https://hackmd.io/chuOwVIuSvqsWxzI0zyP4g
lmk what others i should add!

[coarse mica]

403 🙂

[upper cradle]

⏳

[silk pumice]

In the future, each validator meta data will be updated to add validator moniker?

[spare spade]

i'm not a post genesis validator, but i was in jail 1 time for joining late on first restart of current chain id. can I expect an appeal too ? 😬

tpknam1qprzf0s5vtjqg09qyymul22msekwdnqfw5sxyex2th3l3cggpt4h62ysz9z -> tnam1q9k0jkssxmwdd0g3vpulvl7yp3rv7rnnuyezutcp

[wraith glen]

Btw, I've been thinking and the logic of linking a registered key with the validator address via memo is kinda flawed.

What stops anyone from using someone else's pk in their memo? Don't think anyone had these preconceived intentions, but it does say the logic isn't failproof.

Isn't there a way to see which key signs a validator address' transaction? Or a way to allow people to proof owning a specific address? (maybe by utilizing the namada extension?)

[modest axle]

you're supposed to be jailed for that..

[spare spade]

IMO, this one is different. because we were explicitly told there would be a 24-hour notice before the relaunch (here : #📣-se-announcements message).
however, the patch was released 6 hours after this announcement. if there is going to be a change in uptime scores, it would be nice to consider this too, Yet, I'm not arguing about the final decision.

just saw that it is mentioned here #1209184672270123019 message by @coarse mica and i did the same

[onyx stirrup]

Guys, the explorer does not show the uptime, although I am active, and in other explorers it shows the uptime.

[onyx stirrup]

tpknam1qrdp36tufyelt2tmcylcsxpqppvpy2sp0qcw3klk68gs2sa4qcq9g4lx3wl ->
tnam1q860ncdzdz32aad3lv8rrku37dq9p3gad56x3k2d

[opal aspen]

Hi, I have zero uptime too, but cosmostation.github.io/namadatools/ shows 99.69%, here is my data.
What I get for my validator alias:

curl -s localhost:26657/status | jq -r .result.validator_info.address
E9FA496DA4C5E533CDE943ABF777827908E6C666

namadac find-validator --tm-address E9FA496DA4C5E533CDE943ABF777827908E6C666
tnam1q8gpxyxhe68xh57cxh9mmapy44jumavccsanp6qg

namadaw find --alias crazydimka
Found transparent address:
  "crazydimka": Established: tnam1q8gpxyxhe68xh57cxh9mmapy44jumavccsanp6qg

And for my wallet:

namadaw find --alias wallet
Found transparent keys:
  Alias "wallet" (encrypted):
    Public key hash: CE852C7D3048B58B845712037DDEFE22EE8BAEB7
    Public key: tpknam1qzk6u8wh6qhqc7j9etxdlz9wqczyh2vsm44hgs6dphed3vp0uk2tvl8lcm5
Found transparent address:
  "wallet": Implicit: tnam1qr8g2traxpyttzuy2ufqxlw7lc3wazawku2g5etu

[opal aspen]

here, as requested, as I understood it to be.
tpknam1qzk6u8wh6qhqc7j9etxdlz9wqczyh2vsm44hgs6dphed3vp0uk2tvl8lcm5 -> tnam1q8gpxyxhe68xh57cxh9mmapy44jumavccsanp6qg

[pallid wigeon]

tpknam1qzz44wapdrufszq4tjuu5rhg0fp3zgaqy2sgw2x9c4s2tf5ng4dcz440jx8 -> tnam1qys4a3sv52mhv5qhnmwmhdpcf2a2d3l2murxa74e
If necessary, I have logs with all tx with the creation of the validator

[visual pine]

I seem to have serious problems with uptime, but I have top-end hardware, all the time (even on weekends) I updated immediately to gather consensus during all network halts, most likely I went to prison at the start of genesis because my validator caught bad ones peers and became on the 5th block of the network, after which I was forced to reset everything and perform the init from the beginning, and only the second time the network started working, as I understand it, there are simply no options to return the lost uptime and I was out of luck? Thank you
Public key: tpknam1qqnsu3l53nh77ufr46t9xgy7npad86hwal3j9u3y4k2d92qh98ht5xv4yxt
transparent address: tnam1qrw6q5xyapewe0j0sqwgj52d5g6ygpwz3yy3xxza

[modest axle]

that's a separate issue to the topic here

[leaden pond]

tpknam1qpgeqdqup5g5e7mzp3gu20qtzcrds8msg4x88hufxcnm00musy5zyl60t3l -> tnam1qzj4ghc428ptcfxv9uajz8gt0ujxg5e3ay75z8ta

[west forge]

Not accessible. My competition tpk and validator pubkey are: tpknam1qpnxpylp9phlx9nycrxskuldsuua3htkys3yzz48f7gr0war2w337dweysv -> tnam1qxhagx4gfe70cefqk4k3yxtx0gz33m2vhym4wq0a

[crimson nest]

tpknam1qz6w9ksk48yx8yntzslhpqcu6l6e5txtr4knk84magmdha9cdkrp2zgrus9 tnam1q9gx7anyzey3f4lhl95eav48dxt4jwqvjg9yvec3

@upper cradle It may be a good idea to make an ANN out of this thread, a lot more people in chat have this issue but many have not seen the thread. 🙂

[winter cargo]

Also post gen validator, but I did my validator through "become-validator", with the memo

tpknam1qpayc0rxtuulknrvygcwvlhehuw2tvmxhvhxmjm8s43hxj3vdxjlv62jzcq
->
tnam1qyy7y23gc3g4334qxaz0fmvwvjaffrg8hcuj3hz8

I also got the consensus key issue, so I was jailed for a few epochs. But I think that before that, my validator was up and running for at least 2 epochs.
It's been unjailed and running since epoch 14 or 15

[twilit compass]

tpknam1qp657jtd7tzkadzua0wqr6f5cewrlrah08fn7ny92vcfjuh3lcehvnspw8y -> tnam1qx2pka43jha6v6srs6hza4vmqdc77vktfygte2xt

[frosty crow]

tpknam1qz6k8mw2x5k52ygv3sv9s5cvynlregrk7cl8p0ltqha4wfmcxrq87rz28l8 -> tnam1q892hqc6qlpu56jj79xrvaqkc4whftmq85ka96k5

[modest axle]

@upper cradle slightly unrelated, but someone suggested there might be an issue scoring points if --memo is not placed at the end of the command. I assume that's not the case, but is it possible to confirm with team no mistakes have been made there?

[winter cargo]

@upper cradle Is ther anything else we can do to get registered ? The HackMD page is still not accessible

[pure swan]

tpknam1qzaqvxm6g4h7z34pgdqyzh3y4xevx072ednsfcujfza02knwrfkwqrgywah -> tnam1q8nsk3c3lv5lnf6329tycrs3nq65ewvneurmvz73

[frosty minnow]

tpknam1qza5h520kau4efds29e99fruhefld3mtqwx9x3ax6eys8g0s672cw72sssw -> tnam1qypw0crcylq3eax6vwwmuvc3qcgm3jh3ryj770kx

[upper cradle]

we're going to keep it unpublished for now, not sure why yet

[upper cradle]

not sure i follow--are you asking me?

[upper cradle]

my understanding is that every action must be taken with the memo 😅

[upper cradle]

the hackmd is just for tracking tools and whatnot--not relevant to the uptime issue

[modest axle]

that's not my question- it's I assume it does not matter where in the order of params --memo is included? (I realize it should not matter, but if any mistakes..)

[upper cradle]

ah! the order in the command does not matter

[upper cradle]

good thinking! but i think we just want some data to see what may be going wrong (not to log everyone)

[crimson nest]

The end goal would be to get points credited, hopefully thats the result after we figure out whats wrong :). Quick question do we know how much longer testnet will be up for? Are we talking weeks or days? Thanks.

[modest axle]

you sure that's the case for whether the points get scored on the nebb? just want to doublecheck

[pure swan]

i'm tired of restarting the node to sync because every time it successfully syncs, suddenly, a moment later, the block gets stuck

[lament quest]

is your node public?

[spare spade]

i have a similar concern but about quotes around memo.
for a few days i sent my memo quoted single quotes and double quotes
like "tpknam..." and 'tpknam..'
does nebb trim memos ?

[modest axle]

good question

I assume if your tx shows on extended nebb it's all good

[spare spade]

yeah i hope so 🙄

[modest axle]

you got all the roles man 🙂

nice one

[pure swan]

yea

[pure swan]

how to get those roles btw

[spare spade]

I don't even know what those fire and thunder are😂

[wraith glen]

Lol you're both!

You're a special breed.

Oh wth me too

[spare spade]

seriously what are they?😂

[wraith glen]

I remember getting the fire role after Housefire

So think it started since then

Though it's evolving 👀

Thunder might be those who are rapid-fire styled answering people's questions lol

I'm overthinking it

[spare spade]

you lord of fires , today your fire emojis crashed my poor fullnode server 😂

[daring wing]

When the last time nebb update roids

[hasty remnant]

LAST UPDATED: 2024-02-25 06:35

[pallid wigeon]

nothing has changed. unfortunately.🙁
Rank Moniker Namada Account Stake Uptime ROIDs
363 SNSMLN tnam1qq6…gv9mdanr 0.00% 0.0%

[coarse mica]

what is happening with this one? still zeros for a lot I guess

[modest axle]

all

[upper cradle]

@here how is uptime looking now? are there any changes?

[wraith glen]

Hmm, still zero, but many have signed and still are signing blocks.

[daring wing]

still zero

[upper cradle]

my understanding is that the calculation is

uptime = your_signed_blocks / all_blocks

for many this will effectively be 0

[lament quest]

i cant reactivate my validator

[wraith glen]

Though I have to say, I didn't reinitialize my validator. I found it a bit strange to do this as a solution. Since I did init my validator using my memo back then.

But many others have the issue of having deactivated or jailed validators, so yeah, many different reasons for those being here.

[twilit compass]

I have to wait a bit to know
I thin tomorrow I could get more taht 0 uptime hopefully

[wraith glen]

Mine is still signing, never left consensus nor got below threshold since it was active. Think it hasn't left consensus since epoch 8? (before 8 I did a change-consensus-key and also a deactivate, so before that epoch it was a bit on and off).

Though, my validator is for some reason not linked to my implicit key I registered with. Many others have this as well, else there would have been a lot more with their avatars shown etc.

[modest axle]

nope we signed mannnyyyy blocks

[west forge]

Also seeing 0 uptime. Validator was jailed during the downtime around block 78k I think, but before that it was in consensus and also proposed plenty blocks

[wraith glen]

Yeah you're right btw, we'd probably not even be able to get to the >= 95%. Which equals 0 if we think of ROIDs.

[coarse mica]

not in jail for weeks already, still 0

[modest axle]

I thought we were already super clear this was something that really needed fixing. not even the roid class for being part of set for one epoch can be attained without any meaningful mapping of our user to validator.

[still nacelle]

now it calculates in a window, if I am not mistaken

[pallid wigeon]

Sorry, I don't have uptime 🙁
Only ROIDS && position are changed
2024.04.03
363 SNSMLN tnam1qq6…gv9mdanr 0.00% 0.0%
right now
110 SNSMLN tnam1qq6…gv9mdanr 0.00% 0.0%

[modest axle]

how do you draw this data?

[pallid wigeon]

You mean where did I get my uptime?
namada.net/shielded-expedition/pilot-rankings

[grave vortex]

tpknam1qqm2cd40luwxhpaath4f9nf38d8f8rhy47jl25nn03gtlw4cpjkezjl85ud -> tnam1qqssedgx7nyak90d9r2dvdw8wn3tx3kr6u2vv5ua

UPTIME issue for post genesis is still there.

[daring wing]

Yes

[opaque quartz]

are all post-genesis validators showing 0% uptime? any exceptions to this?

[modest axle]

labisque is an exception

@still nacelle

we haven't been able to figure out why

there was someone else too who claimed to have solved it by deactivating and changing something but unsure how reliable that report was

except those, the vast majority have zero uptime in spite of including memo and being in active set many epochs

[modest axle]

personally I think where it goes wrong is the ability to track which validator established address is created by init-validator (which has several steps), but idk. if it is tracked it's very strange it doesn't appear to be regging uptime for any of us..

[slender abyss]

Yes

I think there are 1-2 exceptions

[still nacelle]

There are more than 1-2, I think, just look for “stake” column, there are quite a few people with 0.01% stake, which means they are post-gen too

[modest axle]

where, on nebb?

[still nacelle]

yeah, I like being special, but I am not the only one 😄

[tight cloud]

No, the same for my part, would I like to share a Gsheet document to list all the post-genesis validators impacted by this behavior?
https://docs.google.com/spreadsheets/d/1wDfwgzqTEQ1gtOesS4mvBvLr1M5ngbTgwi1mVz-oa80/edit#gid=

this gsheet can be edited by anyone

For a while I had the problem preventing unjail, I don't know if the other impacted validators are in the same situation.
For some unknown reason I have 3.5% uptime for a few days but it doesn't change.

[modest axle]

alright but how many are we talking about out of 10k post-gen validators?

[pallid wigeon]

what 10k. 10k dreamed that they would be able to launch a validator. in reality there are now 450 validator nodes. 60 of them are pregenesis

[modest axle]

fair enough. same question though

[modest axle]

@upper cradle how will the v2 task for pilots be awarded to post-genesis when our uptime by and large isn't being tracked for reasons none of us yet know? (or know if will be resolved)

also, is there anything against implementing a self-report of our validator address so we can get out uptime points?

it has to be around 3 different subclasses we can't score points in while this issue is unresolved. (across SE)

[daring wing]

Then team should to remove the uptime roids from all participants 😅

If they ware not able to track the uptime

[modest axle]

not sure shielded-100 would appreciate that

[daring wing]

Then team can use to the uptime record by looking at third party explorers

Like @azure escarp explorer

[coarse mica]

it must be fair for everyone, if not possible to track for all participants then no one should get it

[modest axle]

they won't know which validator is yours..

[modest axle]

I think they should just get on this and find a way to track us. and tbh I don't think these issues have been taken nearly seriously enough

[coarse mica]

and taking into account jails caused by issues it is better to omit this task at all

or just schedule the 2-3 epochs dedicated for the uptime tracking

e.g., find the mechanism, announce "we will track uptime from epoch N till N+4", get conclusion

[azure escarp]

there is no any problem to track any uptime since block 1 for any validator ever

[daring wing]

yeah thats the main issue

[modest axle]

yes but the issue is that they clearly have trouble connecting our post-gen validators to our accounts, even though --memo was used to init the validator

haven't looked in indexer whether those tx are/should be traceable

[onyx stirrup]

everything is true, otherwise it's not fair

[glass kiln]

I've been parsing my records and now I'm 90% sure I created my post-gen validator without the memo field. What action do I need to take? Should I re-create the validator? 🥲

[modest axle]

noone is really getting uptime anyways

[glass kiln]

Thank you. Yeah I know, I've reread a bunch of posts already. But I also double-checked my actions and it looks like I'm one of those who didn't add the memo field. So I'm trying to figure out my next steps.

[lament quest]

What's the latest on missing uptime?

[modest axle]

good question

@opaque quartz you know anything about how this may be handled?

[winter cargo]

I mean, you have that one @modest axle 😄

At that point, it's not threads, it's a whole tangle of them

[modest axle]

I made some artwork

all of these are potentially affected if our validators aren't identified as post-genesis...

[upper cradle]

I think so

I've neglected this thread! i will start investigating how uptime has been tracked

esp with the Nebb being broken

[winter cargo]

Note that there are 2 ways to instantiate a validator : "init-validator" and "become-validator" but the uptime issue does not seem to be related to a specific method

[modest axle]

have people used both? init creates a become also I think

[winter cargo]

dunno
I created mine through "become" because I had an issue with the init command at the beginning (I had messed up my aliases)

but right now, the NEBB is broken anyway, so we dont know if the uptime is actually uptime. I for instance, have been unjailed since epoch 50 ish, so, being at 73 means I should have at least some uptime by now

[modest axle]

we all should have some uptime

[twilit compass]

yeah uptime is kinda strange issue here, as many many pilots were unable to unjail for weeks

[coarse mica]

it depends actually on the mechanism how it was designed to track, since we do not know this, hard to say

[modest axle]

doesn't matter the mechanism for calculation - we should have some at least

[coarse mica]

matters, coz in such a way you can understand why it is wrong))

[modest axle]

I'm saying when we all have zero, it's not a matter of which calculation method they use

[coarse mica]

but not all are with zeros, meaning from all including pre and post

[modest axle]

pre are not relevant here because they are tracked differently.. Post have a very few with no zeroes only. very few

[coarse mica]

who said that they are tracked diff? what is the diff in the code specifically? what is the mechanism to track both?

[frosty minnow]

It is not clear why I can see my uptime from block 0. But the nebb can't

[daring wing]

#1209184672270123019

[modest axle]

my understanding is the genesis validator addresses are baked into the genesis file?

[coarse mica]

Yes, if the genesis is somehow used and db of others is not or with mistakes, then this is the reason

[modest axle]

that's what I assume is happening

[tight cloud]

on this explorer, availability is well discovered. However, I do not know the time limit for calculating the percentage.
https://namada.valopers.com/validators/tnam1q9cw4x0vxzds9cf44le99wcmcgu3hr6rmvazkvps

[modest axle]

interesting, but I don't think it ties that info to our SE-participation profile?

it basically just reads whatever metadata we put into it?

[tight cloud]

I don't understand what you mean 😦

in my case, this is my validator that is registered in SE. And the uptime is correct here

[modest axle]

the issue imo with missing uptime (which relates to competition and nebb only) is not that the network does not track uptime for a specific validator - that data is on-chain. the issue is that somehow the nebb does not connect our validator to our SE-profile (what I'm saying is that even if our "profile info" is on the page you linked, that's just the info we manually put into our validator, not our actual SE-participation key, ie public/implicit pair)

[modest axle]

@upper cradle we really need a fix or plan on how to work around this uptime issue. It's not fair to post-gen

[modest axle]

cf this