Tackling CertifiedData in Motoko

[bjoern]

@LightningLad91

Do you know if I risk losing control of the neuron in the scenario described above?

That is not a risk. Let us look at the spec, in particular the part that defines the “public key” for canister signatures:

The BIT STRING field subjectPublicKey is the blob |signing_canister_id| · signing_canister_id · seed, where |signing_canister_id| is the one-byte encoding of the the length of the signing_canister_id and · denotes blob concatenation.

The key only depends on the signing_canister_id and a canister-chosen seed. No information about the subnet is used. In fact, we will be moving the Internet Identity canister to a new subnet soon, which is only possible due to the described property.

@LightningLad91

Do you have a reference for doing this? I’m still learning the ins/outs of Motoko. I thought only external actors could create ingress messages.

I don’t, unfortunately. It’s a mess, since you have to first encode the argument as Candid, then you have to assemble the ingress message as CBOR and compute the request id. I was saying that it’s possible, not that it’s easy…

@LightningLad91

So does this mean that the canister itself would not be submitting the neuron management calls to the NNS?

Well the canister can use the HTTP request API to make a query call to itself. And then it could use the HTTP request API to submit the request to the boundary node. So once we have HTTP queries, the canister can do this.

But yeah, all this wouldn’t be necessary if canisters could control neurons directly.