I think using the proper hash function it would be as impossible to find a match as it is to find the key for a bitcoin address(the way metamask derives derivative addresses and they are always the same). I guess it restricts the search space a bit knowing that all the keys are knowable, but if the core crypt is good it should be at least pre-quantum secure. If we do it we might as well try for post-quantum as well.
As far as DoS, I think this can be solved by the message still containing the principal id of the canister but also having an âasâ field that is an alt id and derivation. That way we can add a msg.source : ?Principal that would be the root principal if available. That way you can still check against DoS from a canister.
I read this amazing medium post. A couple of quick statements to reinforce my learning (feel free to refute it) & then a question.
A user can manifest himself/herself as a wallet (kind of like a polymorphic function taken to extreme) when interacting with a properly constructed dapp frontend by utilizing his/her identity on that dapp.
Further there is no need to centralize any assets on wallets.(i.e. wallets are obsolete).
Are there any triplets of such dapps that are doing this today? If not, why not?
True. Actually user owned identitiy - I havenât looked into a lot may be a great idea. It will require a new protocol Frontend-to-Frontend (F2F) for communication. I was just about to propose it, I will add that case too.
Currently, dapps working this way only rely on transferring between addresses, but with this F2F protocol, there will be other signing/transactions possible. I will send you a link in DM
Hey I was wondering, the balances on the Dip20 are only stored on a single canister. I havenât done the precise math but by my estimates of the bytes in a hash of a principal it seems thereâs under a billion balances till the canister freezes at 4gb. Is there any solution to this atm?
Just wanted to add that, from a pure protocol perspective, introducing derived ids as a method of allowing a caller (either canister or user) to call canisters with different msg.caller principals seems manageable. Just like self-authenticating ids, those derived ids could be used only for making calls but not for receiving them.
It also isnât clear to me yet how implementing the mechanism in the platform instead of the application layer resolves the issues pointed out by @Sherlocked, such as:
improving security for a canister holding tokens on behalf of users â I fail to see how a platform-level and an application-level solution differ in this regard
client-side code being more cumbersome â wouldnât you (in many cases) still have to implement the computation on the client side; not necessarily when sending a message but for computing an address something has to be sent to?
There are a few possible strategies here, and it will be a fun problem to try to solve. The first one to come to mind is having a swarm that keeps the root up to date and has balances and witnesses. This would slow throughput but would give you much more space.
I think youâd want them as a secondary piece of dats(or to have a secondary piece that does hold the canisterid.
Can you give more detail on this disadvantage?
It goes beyond holding tokens and extends to all kinds of data. When you start having proxy canisters and complsable services, having data/ tokens all held by the same principal increases the risk of certain exploits.
Imagine a library management canister that helps user organize their videos on a third party video canister. If that device wants to rent/buy/snipe for a particular video it will have to do so with only one canister id. It will look to the video canister like the management canister has thousands of entries. The management canister could mange that at an application level, but a protocol pathway makes things much easier.
The most obvious example is t-ecdsa. By allowing multiple derivations a canister can securely hold balances for multiple users. If every canister only got one private key there would be a lot you could build, but it would be harder and more dangerous to do so.
Iâve been handling this with a get_invoice query that does the calculation and tells the client what address to use.
But that would only appear on the protocol layer, wouldnât it? On the application layer, one would only see a new principal that may or may not be related to any other principal.
Ok, I understand that itâs a safety mechanism when building a canister that holds permissions for multiple users. But still, this could be built as part of the application-layer protocols â and the security should be the same. (Instead of setting the derivation when sending the message, the canister would set an additional parameter in the call.)
Right, but you can do this with account ids in the same way that you can do it with derived ids.
