Has anyone figured out where are tokens rewarded for staking collected? On which address, how often are rewards distributed and if we need to claim rewards?
They did this so that THEY could mop up all the initial hype money that poured in to the asset- by the time you get access to your tokens it will be on its way to $50…or less at this rate, we’re already teetering on $100 that could go at any moment- really lost a lot of trust and faith in Dfinity by the way the handled the token rollout and the amount of tokens they dumped on market- the EXACT thing they said they wanted to prevent VC/seed investors from doing by locking their tokens up in canisters with a dissolve-delay timer that only gives them access to a little bit at a time once a month!- THAT is scammy as hell, I don’t care how respected the project or its foundation are- that’s the kind of shit you expect from obscure/shady projects - T
5 Likes
How did you “lose” your tokens?
I purchased 122.63 icp, through the trading platform okex, and during the transfer from the platform to another platform, my other trading platform did not receive the icp.
Not sure which “other platform” you mean, but you really need to ask the customer service of it. The token is in their wallet, but not credit to your account.
Any updates on making it easier for seed people to access their tokens?
- hardware wallet?
- ui?
I’ve basically given up on this project and I’ve been in since Feb 2017 and feel like the rug has been pulled out from under the earlier supporters. I don’t even care about price, just make it a reasonable process for people to access their tokens.
2 Likes
why is there not documentation for so many things relevant to seed round? How do you spawn a neuron from one that has reached maturity? Fine no nice ui, why can’t team provide documentation that shows how to do this via cli???
1 Like
One would have to assume that it was a purposeful decision. I wonder why they would do that?
2 Likes
Cross linking this here
4 Likes
Thanks very much for the document.
Have you tried get_full_neuron for seed neurons? It doesn’t work for me. Sends back a governance error with empty error message. get_neuron_info sends back correct/expected data for exact same neuron ID (obviously switch to Result_2 from Result_1 in didc command for proper decode).
Decoded result of get_full_neuron:
(variant { Err = record { error_message = ""; error_type = 3 : int32 } })
I get the same error no matter which neuron ID I send in. If I send in a fake neuron ID I get expected error that neuron could not be found.
CAN ANYONE CONFIRM WHETHER THEY GOT get_full_neuron TO WORK ON THEIR SEED NEURON?
afaik the owner of the neuron has to sign the get_full_neuron command. did you import the .pem from your seed into dfx to run the command?
Oh, okay. I’ll have to try that. Assuming you mean for get_full_neuron. get_neuron_info works fine without signing anything.
Also, the IC should return a meaningful error like “signature missing” or something like that.
1 Like
Hi @cryptoschindler,
Thanks again for the instructions and clues.
You were right, get_full_neuron needs to be signed. However in an air-gapped setup the situation is quite a bit more complicated. And let’s face it, everyone in this thread should be using an air-gapped as we have been urged to do by the Dfinity foundation. Hopefully “Full Custody” and hardware wallet solutions are still on the way.
As of dfx 0.7.1 we can pass the —status flag after the send command in order to get our status data back. So this part has recently become a little more user friendly, and I have now have the response data. See here: How to sign using ledger "send_dfx" to maintain full air gap - #11 by prithvi
Then the instructions say this which I have not been able to understand or figure out: “However the result is actually a Certificate type that you’ll have to paste into cbor.me and decode"
Here is what I have tried but nothing has worked:
- Try decoding the full response as hex in
didc. Fail - Put the response into cbor.me, grab the the {Certificate: } and try to decode this in
didcas a hex value. Fail - In cbor.me, there is a section that looks like it has converted it into a large bunch of bytes that look like this syntax
\xd6\xe4\x02q\x8e\xe0\x9c"t\x8b.... This is obviously not hex, so try to decode as a blob indidc. Fail. - According to this post, we must find and replace all
\xwith just\so that we can decode as a blob. See suggestion here: Decode canister response to query request - #2 by chenyan Removing all the\xI end up with the same list of bytes like so\d6\e4\02q\8e\e0\9c"t\8b...I try to decode as a blob indidcthe whole data received. FAILS. - So then I must conclude perhaps it’s some subset of the giant list of bytes that needs to be decoded as a blob? I see the string
DIDLin the byte data. so I try to just grab the subset that begins withDIDLand decode that as a blob indidc. FAILS. What subset if any would work? I’ve tried many things.
Every attempt at decoding this data has failed. I’ve been at this for many hours now without much help or clue. Supposedly I have the data I just can’t view it.
Would you please be willing to test your get_full_neuron instructions under an air-gapped / sign/send setup and make sure the instructions are complete?
I’m grateful for any and all help.
I did test them on an airgapped setup. Usually get_full_neuron should just return the result which you can decode with didc as described here. You don’t to check the request. The error you mentionend means that you’re not authorized to make this call.
Did you follow the steps here?
3 Likes
Hi @cryptoschindler ,
Thanks for the error list. That certainly makes sense to describe the issue I was previously having where I wasn’t signing the get_full_neuron request. I’ve since moved on from that and I’m facing the issue of trying to get the results of the signed get_full_neuron request.
I apologize, I’m thoroughly confused by your response. Your document explains that when we sign a message and send it we will receive a Request ID, and then the document says:
Unfortunately the Request ID can’t be inspected as the Identity on the hot machine is not the one that has signed the corresponding message we just sent.
Okay. So how can we get more information from the Request ID? dfx canister --help describes the use of request-status but that term does not exist in the guide you created.
When I try to run the command I get the following:
$ dfx canister --no-wallet --network=$NETWORK request-status $REQUESTID $CANISTER
An error happened during communication with the replica: error sending request for url (https://ic0.app/api/v2/canister/rrkah-fqaaa-aaaaa-aaaaq-cai/read_state): http2 error: protocol error: not a result of an error
Another reports that he doesn’t get responses at all: All dfx request-status calls fail
And in the thread I previously forwarded people have been having issues with getting the status with a Request ID for a long time: How to read the result of sign/send just as we do with call
SO THE STATUS IS I DON’T KNOW HOW TO THE GET THE RESULTS OF A SEND COMMAND WITH A REQUEST ID. And I don’t see any evidence that anyone else does either.
In that discussion thread a new workaround was suggested that we can actually get results by passing the --status flag right after sending the send command. So I tried that and got an encoded result back. BUT the issue as I’ve previously described is that the results come back as a Certificate type and there are no instructions on how to actually decode that data that is coming back in this format.
I sincerely apologize if I’m missing something obvious, but I don’t understand how the guide addresses these roadblocks, and I’ve been keyword searching to try to understand. Again, I’m curious how exactly get_full_neuron was tested from an airgapped / sign/send setup? Was it tested in a test environment perhaps? Is there a current bug on the live IC? I’m very confused.
Thanks so much for your help.
2 Likes
Oh that’s totally my bad! It took me until now to figure out that I described this get_full_neuron command by using a hot machine. Thank you for the hint. I will update the guide and let you know!
Sorry for the inconvinience
1 Like
@Claude1 I’ve been writing a tool that might help you out. You can check it out here:
You’ll need to clone the repo and compile it yourself.
This tool is still under works/code review, use it at your own risk. I do not advise staking any neurons with this yet and am not liable if anything goes wrong.
here is the command
you’ll need to export PEM_PATH=<path to pem file> first
icx-nns --sign neuron <id> full-info
icx-nns send message.json
You’ll see a response like so (I’m testing this against a testnet)
Will send message:
Creation: 2021-06-06 01:47:23 UTC
Expiration: 2021-06-06 01:52:23 UTC
Network: http://[2a00:fb01:400:42:5000:31ff:fe88:4a6c]:8080
Call type: query
Sender: 2x3kc-3n2jw-v3q5h-ngy4b-w2rsb-2ef5e-xxwan-qvhuq-lesp5-zmkjb-bae
Canister id: rrkah-fqaaa-aaaaa-aaaaq-cai
Method name: get_full_neuron
Arg: [68, 73, 68, 76, 0, 1, 120, 134, 159, 85, 99, 136, 83, 4, 174]
Okay? [y/N]
y
(
variant {
17_724 = record {
23_515 = opt record { 23_515 = 12_539_239_107_753_516_934 };
79_599_772 = opt principal "2x3kc-3n2jw-v3q5h-ngy4b-w2rsb-2ef5e-xxwan-qvhuq-lesp5-zmkjb-bae";
349_671_467 = vec {};
456_924_626 = true;
852_549_734 = false;
1_029_637_143 = 0;
1_257_408_332 = 100_000_000;
1_392_680_831 = 1_622_941_957;
2_399_567_118 = 1_622_941_957;
2_680_861_478 = vec {};
2_707_029_165 = blob "\9b\5c\a2#\08\dfl\05&\ee-\b2o4^\a7\01\1c\13\f0\89K\99S\d5~Pk\99&\5cF";
3_084_775_299 = opt variant { 1_620_537_965 = 0 };
3_407_357_762 = vec {};
3_439_871_066 = 0;
3_664_621_355 = opt record {
1_077_262_001 = blob "\9b\5c\a2#\08\dfl\05&\ee-\b2o4^\a7\01\1c\13\f0\89K\99S\d5~Pk\99&\5cF";
1_103_886_095 = 100_000_000;
1_136_829_802 = opt principal "2x3kc-3n2jw-v3q5h-ngy4b-w2rsb-2ef5e-xxwan-qvhuq-lesp5-zmkjb-bae";
1_213_809_850 = 123;
1_835_347_746 = vec {};
3_066_807_170 = 1_622_941_957;
3_583_743_961 = 5;
};
}
},
)
3 Likes
Hi @prithvi,
Thanks for offering this tool. It looks like a great utility you are building! Unfortunately I don’t think it addresses this situation. The tool looks like it is assuming that the identity is on networked machine, and as @cryptoschindler has pointed out we already know that that scenario works and the data returned is easily decoded by didc. The problem is in airgapped sign/send setup. In that case when you send the get_full_neuron signed message, and once you get the data response (the only known way is the new --status flag), the problem is it comes back in a Certificate format and no one seems to know how to decode the information. I believe @cryptoschindler is looking into this. Once we have a working solution you might be able to put it into your utility tool as well.
1 Like
@Claude1 no that is not the case, it has support for segregated sign and send.
On air gapped machine you’ll do icx-nns --sign neuron <id> full-info which produces a message.json
On a networked machine you’ll do icx-nns send message.json after transferring the json file via usb
The tool also handles the Certificate, and outputs idl as displayed above. I’ll be adding native support for the governance and ledger candid today so that the record/field names will not be serialized like above (removing the need to use didc)
1 Like