If a canister runs out of cycles and nobody refills it, it will finally be “garbage collected”. When a canister is finally removed, are the BTC private key also lost forever? If this is the case, maybe it would be interesting to check whether the BTC address associated with the canister contains more than 0 BTC before finally removing it? eventually, the BTC could be used to recharge the canister so canister users have always a chance to unwrap their BTC.
1 Like
from the interface specification:
Once the IC frees the resources of a canister, its id, cycles balance, and controllers are preserved on the IC for a minimum of 10 years. What happens to the canister after this period is currently unspecified.
2 Likes
So, the specifications does not specify what happens with the private keys ?
the private keys are not really stored in the canister, as long as the canister exists it can issue calls to the exposed bitcoin API to manage its funds.
i’m sure @dieter.sommer can explain this way better.
1 Like
Yes, as long as the canister exist. My question was what happens if the canister is finally removed but there is still some BTC?
Hi @ildefons
Hi all!
This is a very good question and here is an answer about what currently happens in the case a canister gets deleted.
As mentioned already by @cryptoschindler, the threshold ECDSA key is not stored by the canister, but on a threshold ECDSA subnet with many nodes. There will initially be one ECDSA master key stored there and each canister root key is derived from the master key on the fly when requesting signatures or public keys. The same is true for any key further down the derivation path. Only a canister can request signatures done by its root key or keys further down in the derivation tree. This is enforced by an access control mechanism of the ECDSA subnet.
If a canister disappears by being deleted after having run out of cycles, the ECDSA key is not deleted as it is on the ECDSA subnet, but no one can request signatures any more with this key, so essentially any BTC on a key controlled by this canister is not transferable any more. This is as it stands now.
Also note that AFAIK a canister that has run out of cycles is not immediately deleted, but after some grace period. At least this is as it is implemented now to the best of my knowledge. So this further reduces the risk that such an event happens at all.
You proposed that we check for a canister holding BTC before deleting it. Good idea principally. Unfortunately, this does not work in the general case of the key derivation we use as the canister could have used any of an infinite number of keys in its derivation tree. So it’s not possible to reliable perform such a check. One could make assumptions that canisters use keys that are “close” to their root key in the derivation tree, which might make some heuristic checks possible and often times effects, but it’s not reliable.
One can also think about a recovery procedure where the metadata of deleted canisters is used, specifically its controllers, and for example, provide a mechanism that a principal that has been a controller of the deleted canister at the time of deletion may receive the opportunity to somehow reclaim the canister’s BTC. How this would be done is completely open, e.g., by temporarily recreating the canister and allowing for this. But this is something that is not at all implemented or thought about in detail and might violate some properties we currently have, e.g., that a deleted canister principal would again be reactivated. Also, this might have other undesirable security consequences one would need to think about. This just comes from the top of my head and would need to be thought about much more in terms of implications and realizability. But in theory, the key would still be there and there may be means to recover from such a situation.
Does this help?
3 Likes
Thank you for the depth and breath of your answer. It really helps me to understand.
My initial motivation for this question came when I thought that a simple demonstrator of the Internet Computer as a master chain would be to implement a wallet able to securely hold crypto from many different chains without bridges. So, this raised question of “what happens if the entrepreneur implementing and maintaining the canister disappears the canister runs out of cycles and its finally removed after a grace period?”. You mentioned that eventually a “recovery procedure where the metadata of deleted canisters is used” but “this is not yet implemented and it maybe raise some security concerns”.
I think that this functionality is important because applications like multi-chain wallets and vaults for lending platforms and diversified treasuries will all need to implement a solution for the operational risk of “what if the founder/team goes away”. A default solution backed by Dfinity, would enable this type of canisters to emerge much more easily and the crypto community would feel a lot more comfortable using it. Widespread use of multi-chain wallets could be a first killer app and demonstrator of the Internet Computer as master chain.
Even better: because control of a canister’s id can be so valuable (ECDSA keys, ICP balances etc), canisters are never deleted by the system. As your cycle balance goes down, the canister gets frozen (doesn’t handle new calls) and later the code gets installed (to bring the memory footprint down to almost nothing), but this almost-nothing will be kept around. It includes the controllers field, and will allow the owner to revive the canister (by installing code again) and thus access keys or funds.
The cost for this “eternal” preservation of canister metadata is paid for with the canister installation fee, and assuming storage gets cheaper over time as it did so far, the math adds up.
Note that it is possible to explicitly delete a canister. Then access to funds and keys associated to the canister id cannot be recovered.
Ah, @cryptoschindler found the relevant section in the spec. Guess we weren’t quite as bold back then and defined eternity in the field of crypto to be at least 10 years.
5 Likes
Cool, was not aware that you can revive the canister, being its controller, from the metadata.
Thanks for clarifying! 
2 Likes
However, @ildefons’ scenario is still not solved by this: If the entrepreneur (=canister controller) runs away, no one can revive the canister and get the funds back.
The only solution seems to be to put such important canisters under the control of a DAO, e.g., by using the upcoming SNS.
2 Likes
Does this mean that any data that was stored in the canister before it was taken down (“installed”) can also be revived? My concern is that a canister that is taken down will have all of its files deleted.
No, code and data is lost when you run out of cycles. So pay attention to your cycle balance, keep off-chain backups, or both
1 Like
Well, if the entrepeneur runs away and people notice before it’s deleted they can start topping it up – that doesn’t require controller priviledges. But yes, anything beyond that you better only use properly governed canisters
1 Like