How many certs does this require? It was 3 when I tried on another iteration a few months ago.
It’s 3 smith certs, but 5 certs to become member on the main wot. You already have 3, so 2 more needed
- 2457 = HugoTrentesaux
- 6951 = Poka
- 7139 = tuxmain
Je suis dans la toile forgerons moi ??
ahahahahaha
pardon Manu, probablement moi qui t’es ajouté à py-g1-migrator pendant le hackaton de bordeaux.
On peut te retirer si tu veux.
Retirer du prochain genesis, oui, mais pas de la toile forgeron Ğdev5. Si tu veux en sortir, tu peux appeler smithsMembership.revokeMembership()
.
Il est techniquement possible de lancer un proposal au commitée tech pour se faire aussi non ?
Oui, comité tech ou sudo, tu as raison.
I now have smith membership. As I understand it I don’t need to wait for 48h before going online since my node has been running for 3 weeks already. Am I right?
@HugoTrentesaux
I must have done something wrong:
-
smithMembership > requestMemberShip()
→ seems OK -
authorityMembers > setSessionKeys()
→ error NotMember
Seems not because the smithsMembership.counterForMembership()
is still 6. I would like to have an indexer to search in the blockchain history, but this one has been deleted, so we have to setup a new.
I would have check whether you called
successfully. Otherwise, I’ll have to dig to understand why you were not added to authority members.
I did. And I checked using smithMembership.membership(7228)
which returned a record with an expiration value. But when checking again afterwards it doesn’t return anything anymore, just <None>
. Weird.
EDIT: Trying smithsMembership.requestMembership()
again I have the error MemberShipAlready
. Maybe I should retry after rotating the key again?
storage.smithsMembership.pendingMemberships(7228)
{
ownerKey: 5GBVhdJUdsGhxozu6R8X6x2pTZvuuW46s7JSU4tiW7Zd3WmY
p2pEndpoint: /dns/gdev-smith.pini.fr/tcp/443/wss/p2p/12D3KooWCEVBrLK9g8unsHLj8wWzobbwArDZMMwg5LeCbiWhB3ug
sessionKeys: 0x3b8ccba0a36ab6c5b04d159d2e3188c6bd2e8257bdec6935ae6d812e31d36d857610e984e7cf0f444c47369a490373d4389ec37c32a5139f61d3935137595e10d4969256ac9618dd33046693ec6d2114f0ee5979a6fa83434d972f306ed88b031e7f4b506d028435d0916ce059914b4d9fb1bd00e8f76f1912855af225126775
}
storage.smithsCert.certsByReceiver(7228)
[
[
7,139
10,954,075
]
[
6,951
10,954,196
]
[
6,317
10,954,063
]
[
2,457
10,855,477
]
]
storage.smithsMembership.pendingMemberships(7228)
So, my smith membership is pending. But we don’t know why is it held in this state, still?
I think you have to claimMembership:
Done, and it was reported successful. Then I could set session keys and go online. How can I monitor that everything is alright?
Rotate keys, then set session keys and see if it’s successful. You can see the session keys in onchain storage (pallet session or babe probably).
For goOnline, the only way to be sure it works is to wait a few hours…
Don’t worry, it’s not a problem if some blocks are missed. Just goOffline if you see it doesn’t work.
Congrats, you are the first non-genesis ǦDev5 smith! If you want to complete the documentation on https://duniter.org/wiki/duniter-v2/become-smith/ that will be very useful to future joiners!
What is strange about claim_membership()
is that it is documented as disabled:
https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/xtask/src/gen_calls_doc.rs#L135
I think it is a mistake. I’ll improve this part of the documentation as well.
[edit] when looking at the expected behavior, I read the join smith test (https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/pallets/duniter-wot/src/tests.rs#L59-L87)
The list of certification, smith certifications, session keys and authorities which will expire within a week is updated daily here: https://txmn.tk/g1/gdev/expire.txt
gcli --no-indexer expire -s 168
Since offenses are not yet implemented, detecting failing nodes would require much work from the indexer (counting the number of blocks forged by each authority during the last session).