Are canisters not allowed control neurons?

[Jesse]

I’m attempting to assign a canister principal as a neuron’s controller, but I’m getting the following error:
Cannot add neuron, controller PrincipalId must be self-authenticating

is this error being thrown because the principal is that of a canister? if so, when will canister’s be allowed to control neurons? Having this ability is a necessity for the application that I’m building. I wouldn’t expect this of all things to be what blocks me.

[diegop]

AFAIK, a canister cannot natively control a neuron out of the box so the simple answer is “no”… however, I heard one could do the following (not straightforward process): A canister should be able to do an HTTPS outcall to the NNS canister and use Threshold ECDSA to control an NNS neuron. I am not aware of folks who have done this in practice though.

[Jesse]

Is there a reason for requiring devs to undergo such a roundabout process in order to enable neuron staking within canisters? What’s preventing the restrictions in place from being lifted?

I ask because I’m currently building a product that’s meant to facilitate collective IC staking and governance amongst different communities. Additionally, it’s meant to allows users to be able to collateralize their neuron stake in order to receive liquidity in the form of a loan.

To do this, I’ll need a treasury canister that has the ability to control a neuron. I’ve already built most of the code needed. This restriction on canisters has become a roadblock for me in development.

It wouldn’t make much sense to write up some convoluted system for enabling the treasury canister to control a neuron when, instead, the 1 or 2 lines of code that restrict canisters from controlling neurons could simply be removed.

[domwoe]

@diegop

A canister should be able to do an HTTPS outcall to the NNS canister and use Threshold ECDSA to control an NNS neuron. I am not aware of folks who have done this in practice though.

The OpenChat SNS is doing this in practice. The code can be found here: open-chat/backend/canisters/neuron_controller at master · open-chat-labs/open-chat · GitHub

@Jesse

It wouldn’t make much sense to write up some convoluted system for enabling the treasury canister to control a neuron when, instead, the 1 or 2 lines of code that restrict canisters from controlling neurons could simply be removed.

I would personally vote in favor if you put forward a proposal.

[diegop]

@Jesse

Is there a reason for requiring devs to undergo such a roundabout process in order to enable neuron staking within canisters? What’s preventing the restrictions in place from being lifted?

I am not an expert on this topic, so I am not aware of what the design goals or constraints on these are (or if there is some security issue, or if its just its a feature that has been low in priority queue), so I am sorry I cannot shed more light on this.

[jamesbeadle]

So I am in the process of this of creating a canister controlled neuron in this way, my WIP can be found in the neuron controller folder here:

OpenFPL/src/neuron_controller at Create-DAO-Neuron-controller ·...

So in neuron_controller.mo you will see the function get_public_key_der:

But I have no idea how to write this function, is there any information you could give me?

[domwoe]

Hey James,

If I understand correctly, for this you just need to call the API at the management canister, see examples/motoko/threshold-ecdsa/src/ecdsa_example_motoko/main.mo at 340cc897f5de49eee10c78ec769602a5b1eb391a · dfinity/examples · GitHub

You might also want to checkout this library: Mops • Motoko Package Manager

[jamesbeadle]

So yeah I can get the tECDSA public key in secp1 format but then I think I need to convert it back to DER format for future requests to the IC?

I can’t actually load the spec
https://internetcomputer.org/docs/current/references/ic-interface-spec

[domwoe]

@jamesbeadle

So yeah I can get the tECDSA public key in secp1 format but then I think I need to convert it back to DER format for future requests to the IC?

yep, haven’t parsed the “der” But the library I linked does this AFAICT.

[jamesbeadle]

In the tecdsa library? I went through all the code and it doesn’t mention this format DER anywhere. It’s all new to me, is there any information you can give me on it?

[Jesse]

@jamesbeadle There’s actually an active discussion proposed Here that would lift the restriction that prevents canisters from being able to control neurons directly.

My guess, is that the restriction will be lifted soon, and all the work that you’re about to do in order to perform an tECDSA-signed HTTPS request will be made redundant.

I’m not sure what your timeline is, but that’s an option for you

[domwoe]

bittoko/tecdsa/blob/89fadbdad91ef8303b8a861fe9e7457ce134ba9a/src/Client/class.mo#L26

[jamesbeadle]

Daily rewards on the neuron are probably around 20 ICP on the current figure so waiting obvs costs a lot of money especially when you’d set the DAO up to stake and pay the team through interest.

[jamesbeadle]

Would you be able to give me any information on what this does and how it relates to getting the public key der in the same way OC does?

[LightningLad91]

@jamesbeadle here is a breakdown I posted in response to another post.

Error: Failed to authenticate request ... due to: Invalid signature: Invalid public key: Malformed Placeholder public key: , error: Error in DER encoding: Invalid length of bit string: -74"

I had to figure out how to encode ECDSA keys a couple years ago for work and what I found is that it’s relatively easy if your key size stays the same. (when compared to something like encoding RSA keys). I modified IC-Py to write the encoded public to a file so I could deconstruct it. Here is what I got: 30 Sequence 56 Sequence Length (86b) 30 Sequence 10 Sequence Length (16b) 06 Object Identifier 07 OID Length (7b) 2a 86 48 ce 3d 02 01 (id-ecPublicKey) 06 Object Identifier 05 OID Len…

Happy to add more context later, but currently at work.

[Jesse]

I understand.

Once you’ve retrieved the public key, you’ll have to decompress it, and then prepend a constant Blob to the decompressed public key.

This thread should be helpful:

Error: Failed to authenticate request ... due to: Invalid signature: Invalid public key: Malformed Placeholder public key: , error: Error in DER encoding: Invalid length of bit string: -74"

I’m currently attempting to send an HTTPS request that has been ECDSA signed. Upon doing so, I get a 403 status returned along with the following error message: Failed to authenticate request 0x9b8...3baa due to: Invalid signature: Invalid public key: Malformed Placeholder public key: 030...4aa, error: Error in DER encoding: Invalid length of bit string: -74" I’m using a CBOR encoder to encode the request’s envelope. The envelope consists of the evelope’s content, the public key and the si…

[jamesbeadle]

Is that what is happening in here?

[LightningLad91]

Yes, you can find that function here:

bittoko/tecdsa/blob/89fadbdad91ef8303b8a861fe9e7457ce134ba9a/src/Client/pk.mo#:~:text=import { fromArray = blobFromArray,50