Seed Round Access

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 didc as 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 in didc. Fail.
  • According to this post, we must find and replace all \x with just \ so that we can decode as a blob. See suggestion here: Decode canister response to query request - #2 by chenyan Removing all the \x I 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 in didc the 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 DIDL in the byte data. so I try to just grab the subset that begins with DIDL and decode that as a blob in didc. 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?

Is anyone employed by dfinity working on a GUI to enable managing seed neurons? @diegop @hpeebles

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

Well that sounds amazing. We should then be able to manually decode the Certificate response data with cbor.me and didc somehow correct? Any idea on how to do that? Or is it only possible to do it programmatically? Adding in the governance annotations into the tool will be awesome too. Thanks!

Also, will you also add some installation instructions to the README? Not familiar with Ruby and need to understand how to map main.rs to icx-nns command and install all the packages. Then once I can install properly, I need to figure out how to copy all of those changes over to an airgapped machine that cannot access the package manager.

1 Like

I second Claude’s response. How do we decode that certificate? It seems you are using the candid crate, but I’m not very familiar with Rust so I have no idea what is going on in the ‘Decode’ method you use. Can you shed some light on this @prithvi ? Many thanks!

I’m not able to build this, what Rust version are you using?
getting errors like this

dependency (ic-agent) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed.

Hey Claude,
thanks again for the heads up! I wasn’t able to build @prithvi 's tool, but @PaulLiu released something similar just recently. The blog is now updated and you should be able to run get_full_neuron successfully with an airgapped machine.

Let me know if you have any questions!

(you might need to clear you cache to see the latest updates)

1 Like

A response to this would be appreciated.

I’m also not sure about this. Dfinity has previously said they are working on what they call “self custody” which is basically the same thing as hardware wallet support. Right now you cannot use this “self custody” approach with IC dapps like nns.ic0.app unfortunately. But I’m guessing that once they have this figured out we should be able to put seeds into hardware wallets and gain access to nice existing GUIs to manage our neurons in the nns app.

If this is wrong, someone please correct me.

@cryptoschindler Thank you very much for looking into this! I’m looking forward to trying this out soon.

Love watching the token price just tank and seed people who supported the project 4.5 years ago having no ability to access their tokens.

5 Likes

Not even to sell the tokens but to manage them and spawn to compound. Managing 48 neurons from command line plus all the spawned neurons is not practical. Spawning and staking 48 new neurons every time.

I was told the NNS UI team is in charge and it would be possible to manage when hardware wallets are supported.

Who is on the NNS UI team? Can they chime in about hardware wallet support? And what stage they are at?

4 Likes

Hi @PaulLiu , Great tool thank you!

Would you be willing to add the ability to simply upload a message.json file to the tool? So the tool would work with both scenarios: QR scan or uploading a message.json file directly. I would be very grateful if you could add that to the tool as my setup doesn’t work too well with QR codes and I manually copy message.json files. Your tool would work perfectly for this use case as well.

Thank you very much for your consideration.

1 Like