Brechtpd
commented
3 years ago Some assumptions:
- Assumption A: This discussion only really matters when the counterfactual wallet is used a long time before being deployed, which will only be the case when the counterfactual wallet address is used for users that are exclusively on layer 2.
- Assumption B: Because the secret wallet data is stored on a phone in a very secure way theft is highly unlikely. It is therefore many times more likely that the smart wallet's main purpose is really just being able to recover the wallet after the user lost his phone, forgot his pin code or something similar.
- Assumption C: When the user first sets up the wallet and the wallet address is generated the user is unlikely to set up all his own guardians because that would make the setup process a very tedious experience, so is probably not even something that's possible in the UI to not scare users away. Even if it would be possible, the user is highly unlikely the care about security at this point because the wallet is empty or simply does not know his future guardians yet. So almost all users probably first create the wallet with just the standard centralized guardian set.
If we take the above assumptions as true then the only real purpose of the counterfactual wallets is recovery. Using the minimal config allows the wallet owner to update the guardians while still in counterfactual mode. This allows the user to move away from centralized guardians and towards actual social recovery with whatever guardians he decides as he uses the wallet. If he loses his wallet he can now user his own guardians to recover the wallet. I would say that this can potentially greatly improves the security and user friendliness of the recovery process.
I think the extended wallet config can only be seen as superior when the private key was stolen. This goes against assumption B but let's say it is indeed stolen. With the extended config approach:
- There is not really any extra security for assets on L2. With just the private key the hacker can transfer out all user assets on L2 until the real owner deploys the smart wallet and modifies the EdDSA key at which point it's almost certainly already too late.
- For assets on L1 there is only a benefit if the initial wallet config also enables a quota (and the quota is set to a value that also doesn't allow all funds to be transferred out immediately). Without the quota the hacker can still transfer out all assets immediately. Even with the daily quota the hacker can transfer out all assets without onchain price information like NFTs without any limits.
So assuming assumption A that user assets will be on layer 2, I don't see any real benefits. There could certainly be some benefits for assets on L1 though when the daily quota is enabled and set to a good value. If the theft doesn't happen immediately the best course of action could actually be the same I think with both approaches: deploying the wallet and either locking it as soon as possible and then recovering or just immediately recover if that can be done as fast as locking. The L2 EdDSA key should also be changed as soon as possible either before the recovery using a new secret or after using the new wallet owner.
I think that "best" approach really depends on how we think the counterfactual wallet will be used and for what purpose.
Currently, we only use the initial owner and salt as the input together with the wallet contract code to generate the wallet's address. I think we should improve it by hashing the entire wallet configuration into the address, especially initial guardians.
First of all, it's not hard to do at all. Secondly, this can prevent malicious operators, Loopring included, from colluding with a hacker who gained access to the initial owner's private keys. With this change, they cannot change the initial guardians.