Can I ask - does enabling canisters to transfer ICP effectively enable neuron transfer, as well?
Namely, is the ability to transfer ICP required to stake ICP in a neuron? Meaning that canisters that hold ICP could now also stake ICP in a neuron, where they might not have been able to before?
If so, then one could create a canister, send ICP to that canister for it to stake in a neuron, then reset the canister’s controller, effectively transferring the neuron, right?
Nope, canisters are not allowed to be controlled by neurons for this very reason. It’s a separate check:
Would this check be removed at the same time?
(Note that these checks are just snakeoil, as canisters can control self-authenticating principals via canister signatures or via the new ECDSA key feature under discussion; it’s just a bit more cumbersome to implement that.)
Is there any documentation or example code on how to do that?
No. Figuring that out is part of the “capture the IC token” challenge. In all variants it requires an untrusted external component that bounces requests from the canister back via the HTTP interface (it’s only needed for lifeness). And we still need the “canister signatures from non-root-subnet canisters are accepted” feature or the “canisters can do ECDSA signatures” feature to land.
I just hope I’ll never have to explain how to do this to anyone, because the fact that it’s conceptually possible but cumbersome means the restriction in th code above is not effective, just annoying, and that hopefully suffice to get this restriction removed.
Edited Post:
Responses from @JensGroth and @nomeata have alleviated my concerns expressed here. I have no more hesitation on this proposal based on information available today and clarification offered by experts on this topic.
Original Post:
@diegop @JensGroth
I have no idea how to vote on this proposal. I support the developers and changes that will meet their needs, but I also expect Dfinity to protect the safety and security of the network and to anticipate/comply with traceability needs. Does Dfinity need more time to review and develop a better solution on this proposal?
I really don’t want a proposal implemented that Dfinity believes will create or expose vulnerabilities, especially if it will be difficult to roll back and relies on warnings not to transfer too much ICP. I fully believe that this issue needs to be addressed, but I don’t want to rush to an inferior implementation if you just need more time to develop a better proposal.
I don’t really understand the hesitation. Of course, trusting ICP to be held by a canister is risky, in case of bugs in the canister, or the IC, or other things. But so is moving your valuable business logic or data to a canister! Or your Bitcoins (via the parallel ECDSA support). What makes “transfering” ICP so much more critical than all the other possible use cases for canisters?
(This assumes that the worry is all about canisters doing the wrong things with their ICPs, but not the security of the ICP system itself. The ledger will not care if calls come from users or canisters, and work just fine, I’m confident.)
So… reproducing the build necessitates the trust path to source and revision, which conceivably would be part of the developer offering. Also conceivable that developer will make best efforts to educate and illustrate.You would think I would have seen it’s just a fractal of your Dockerized build example. Idiosyncratic aspects (flag/architecture/time etc…) that might cause verification to fail can be tweaked with ‘developer cooperation’.
With that said, do you have any concerns re: Quis custodiet ipsos custodes? beyond some future articulated best practices?
Another question - Does this comment still hold true? send_pb isn’t compatible with Motoko.
What is keeping candid compatible ledger functions from being deployed? This seems super simple and straight forward. Other rust canister speak candid just fine.
My biggest hesitation to enabling canisters to transfer ICP would be in de facto also enabling neuron transfer, if this is in fact an unavoidable consequence, per the exchange above between you and @wang. This hesitation is rooted in the security risks of neuron transfer suggested in this thread here, for example.
Neuron immobility is currently at the heart of the model of secure good governance underpinning the IC as a whole. (Other risks of enabling canisters to transfer ICP seem more or less limited to particular potentially insecure or malicious canisters, and mitigations seem possible, based on the discussion so far.)
Wrt application subnet vs system subnet. On a system subnet, we only have a controlled set of canisters running (governance, ledger,…). On an application subnet we have arbitrary canisters running. So the added concern is whether there’d be any way a malicious canister that could break out of Wasm and start executing arbitrary code and interfering with other canisters on the same subnet. Not that we’re aware of a way to do this, but nonetheless we are planning sandboxing canisters in separate processes in the future to mitigate the potential risk.
We are planning to have a bug bounty program.
Node shuffling, not sure it gives so much in our system, one risk being accidentally shuffling a subnet into a bad node configuration.
Yes, I was thinking of the risk of escaping the Wasm runtime.
Agree with your wish for tooling to understand the deployment of canisters: can it be updated, what are properties of the subnet it runs on, etc. Happy whether it comes from the foundation or the broader community.
We’re not planning to enable canisters to stake neurons. You’re correct that if we did, then indeed one could transfer neurons via transferring controllers.
Nope, we’re not planning to let canisters control neurons. Agree with your in-principle analysis but in either case I think it would be best to take one step at a time.
I see very little chance of the proposal creating or exposing any new vulnerabilities of the IC. My own concern is more about increasing adversarial incentives.
As @nomeata says in his reply, users may already have value in the canister logic today. But ECDSA signatures are not there yet, and putting ICP in canisters may add value beyond what is currently in canister logic today, so I think the proposal makes application subnets juicier targets.
Threshold ECDSA and related ideas will take months to implement. Also, due to the greater simplicity of native ICP handling, it is easier to analyze from a security perspective.
Make sense with a schedule like that. I think this is the first we’ve heard that the signature stuff is months out.
Yes, sorry, I put the timeline of “months” friday evening PST.
Based on the questions on this thread, I will push back voting 1 more day to September 15th to give people the ability to dive deep. If people want more time, we can do that, but hopefully, 1 day is enough.