@everyone

[tropic stag]

😔

For more than 24 hours we have been waiting for our validators to become valid

Also, isn't the faucet protected by pow?

[past drift]

@fast lotus
The latest rankings will be preserved as much as possible.

maybe best to restart the points too, just to avoid any misbehavior that might had happened.

[lethal ledge]

I appreciate that we can have the weekend to relax:) thanks team!

[tropic stag]

why?

[low pumice]

Good idea, Anyone who has encountered the problem of peers on startup will support this.😀

[past drift]

yes i think fair for all participants

[waxen quartz]

funny that faucet was exposed to bots)

[barren sandal]

I vote for a complete reboot

[real rose]

@fast lotus
and please update the docs, it's not fair if docs are not updated, those who can look into src code have advantage over others.

[wind lake]

and what if I delegated to my validator?

[topaz pine]

I bonded my node with my NAAN tokens, is my balance in validator reset or still remain ?

[vapid wraith]

A total of 10,469 Pilots and 129,238 Crew Members will be competing and cooperating with each other from the expedition’s genesis in an asteroid mining race.

That is how this event was announced.

I have skipped sleep and put aside other work to compete in this race. Fought through the incomplete, outdated and scattered documentation. And made it to #3.

Now some suggest to nullify that effort and sacrifice?

I do not condone botting the faucet, so I agree with installing countermeasures and reversing the accumulation of NAAN through that exploit in the last hours.

But completely rebooting the ranking as some have suggested, would make me very disappointed.

[ruby gazelle]

when is the network scheduled to shut down?

[spiral thunder]

finally genesis validators can complete tasks they missed

[scarlet meadow]

As if Shielded -100 folks don’t have enough advantage already. Why penalize honest post-gen validators who toiled to get up the ranks. Not fair

[scarlet meadow]

lol, so genesis Vals get a shot at Genesis related tasks again 😆

[tawny crystal]

Okay

[shell badge]

gazs

[mild trench]

So we can't perform a task till Monday

[brisk patrol]

🫡

[humble vigil]

What part of the docs are unclear to you? I am trying to update them before restart

[spiral thunder]

with validator_stake_threshold = "1000000000000" task 4 (become part of valset for at least 1 epoch) is for pre-genesis only too?

[tranquil granite]

many did the same, i even mocked the shielded expedition genesis balances , created my fork and ran my validator many times before the genesis time to make sure everything works, but just couldn't connect in early due to bad peers and that restart bug

you did a great job. but don't think others were lazy.

and in case of a reset score, i think the ROID system is deterministic, you can repeat all the tasks again and achieve same score except for joining early

[scarlet meadow]

Genesis validators couldn’t bring node up at Genesis, and want a do over. Is that right?

Wasn’t that one thing they prepared for quite a while

I don’t think it’s fair to reset scores so that genesi vals who had such and advantage and still didn’t do well, are allowed a do over again.

Just my 2 cents

[tranquil granite]

hey, I'm okay with any decision the team makes about the scores. just wanted to clarify things that if someone claimed the first 5min score it doesn't mean they have worked harder, since the problem, at least in my case was connecting to bad peers.
many participants in this competition are far more experienced than me and they deserve to get higher spots in the leaderboard. I just think in this particular step a bit of luck was involved not expertise.

anyway, I won't comment on this topic anymore, we have an exciting journey ahead and I want to enjoy it to the end.
good luck

[humble vigil]

No that is for any pilot (pre-genesis or post-genesis)

Also regarding score resets, we have already announced that the points are frozen, i.e that they will be kept in tact as much as possible, not reset

[humble vigil]

Let me know what part of the documentation is still scattered/incomplete/outdated, I'd really like to update it

[real rose]

last i tried, shielded transaction, ibc transaction & gov voting were not clear (voting i got it working later)

one more thing @humble vigil

as Park said, pre-gen piltots don't have a significant edge over 2nd pilots, but i see (including mine) our validators didn't get get into active set, after 2 epochs, that means we loose uptime points, can you please clarify on that or please fix it on 2nd run

@pallid chasm @fast lotus

[real rose]

i am not in SE-100, so don't know what exactly happened, so what you are saying those bad peers wasn't your fault?

[winter orchid]

there’s a lot missing in various places. commands that aren reflecting the latest changes in syntax. things like the memo field for SE would be nice to have as part of the official docs

[winter orchid]

pre gen definitely has a very significant edge. that’s self-evident when looking at the scoring categories and considering the limited number of pre-gens

[humble vigil]

I put it under https://docs.namada.net/networks/testnets#shielded-expedition but maybe I can scatter it elsewhere

[humble vigil]

Every time you see something that isn't clear/needs to be added, can you open an issue github.com/anoma/namada-docs ? It would really help

[winter orchid]

sure will keep it in mind. should we add bugs on the github when/if we find minor issues during SE btw?

[winter orchid]

and yes I think it's important that info is also disseminated in the rest of the docs, but maybe that's just my personal pref

[winter orchid]

do we have anywhere in the docs where implicit/established accounts are explained in-depth? seen a few questions and suddenly have them of my own 🙂

[humble vigil]

Right now it's what you can get under https://docs.namada.net/users/transparent-accounts

Would you like me to expand something?

[winter orchid]

let me check..

[winter orchid]

it's ok I guess, to me the terminology is super counter-intuitive though - might I be so bold as to suggest better terms if I understand the mechanics of it correctly?

or maybe I don't have better suggestions, but the terms don't make much intuitive sense. think I got it now but a little unsure - and going by a few questions in the chat during testnet that goes for a few others here too

I am correct in thinking there is only one implicit account (corresponding to a transparent address) per keypair, and that this is used to create other established accounts? (and can never become an established account itself?)

[humble vigil]

I can see the confusion

[winter orchid]

I think I understand the mechanics of it now, but the terminology, and maybe the conceptualization, I think, could be improved

perhaps, or maybe I'm not in-depth enough yet

happy to enter into dialogue on it if needed, but don't want to take your time if it's not an issue.

[vapid wraith]

I agree, the rationalizations and mechanics behind the concepts are not explained, only their usage. If a user has no understanding of those concepts, they have to memorize the exact steps to use the system rather than interact with it intuitively.

• Why are there different types of accounts?
• What are the features and limitations of the different types of accounts?
• Can the account type be converted to another type?

[winter orchid]

ideally there would be more precision around the concepts of keypairs and how they relate to addresses and how implicit and established addresses work differently in that context. clarification of tpknam and tnam. my current understanding is a pair of tpknam and tnam are generated for each keypair derivation, and that there can only be one implicit (again super confusing terminology), which can then create other adresses/accounts. (will those accounts also have their own tpknam associated?) also difference/precision between accounts and addresses

[vapid wraith]

A deeper understanding also helps finding vulnerabilities.

[winter orchid]

I assume some of these constructions are made by design and can't be changed, but I assume some of it is simply terminology. and possibly the current terminology doesn't reflect the underlying design choices very well?

questions in my mind are things like: why can't implicit tnam be used directly? is that a design choice? a consequence of how the underlying tech works? are the "established" accounts a bit like smart wallets / smart accounts in eth?

it took me a few days now and trying to convert an implicit account to a validator account before I realized I must be barking up the wrong tree 🙂

[tropic stag]

is there an easy way to update the namada cli tool?

[humble vigil]

Yeah, there are also legacy reasons behind their naming. At the moment, the pracitical difference is that one can have multiple keys whereas the other one cannot.

But the longer story is that when we were working with custom "validity predicates" (now called resource logics, RLs for short) the idea was that established accounts can have any arbitrary RL attached to it. Now that all validity predicates/RLs are whitelisted (i.e not custom), it means that an established accounts capababilities are found in the vp_user validity predicate/RL. The vp_user mainly takes care of making sure that the signatures are verified according to the threshold set in the multisig

[humble vigil]

wdym

[vapid wraith]

Are there future plans to merge implicit and established type accounts into a single universal account? I wonder if that is possible since established accounts are initialized on-chain while implicit accounts can be derived offline from the keypair.

[tropic stag]

namada version on my server: v.0.31.0
SE namada version: v.0.31.1

is there an easy way to update this, like namada --update or should I download the new version and compile it?