You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One issue that was not anticipated in the discussion of #171 is that users may want to recover the wallet using the last leaf computed using the old root. One fundamental guarantee of the recovery feature is that even if the user lost the authenticator, as long as they previously have set recovery address and has not lost the partial proofs (in particular, the "last leaf") stored locally on their device, they should still be able to recover the funds.
This guarantee includes the scenario which, an attacker somehow gained access to the authenticator and "extended" the user's wallet's lifespan. Since the root is replaced during this operation, the user loses access to their wallet, similar to how they lose access to authenticator. This means the user should still be able to use the Recovery feature and perform the recovery from their web client using locally stored data. Therefore, the wallet contract must store all the historical roots, and validate recovery operations not only against the current root, but also all the historical roots. The contract also needs to make sure that the leafs intended for recovery use (for any root) is "reserved" and not used for operations other than recovery. Since recovery leafs are very rare (1 per Extend operation), it would not impact wallet user experience (the user can simply wait for 30 seconds if coincidentally that they are trying to do something based on that leaf).
One issue that was not anticipated in the discussion of #171 is that users may want to recover the wallet using the last leaf computed using the old root. One fundamental guarantee of the recovery feature is that even if the user lost the authenticator, as long as they previously have set recovery address and has not lost the partial proofs (in particular, the "last leaf") stored locally on their device, they should still be able to recover the funds.
This guarantee includes the scenario which, an attacker somehow gained access to the authenticator and "extended" the user's wallet's lifespan. Since the root is replaced during this operation, the user loses access to their wallet, similar to how they lose access to authenticator. This means the user should still be able to use the Recovery feature and perform the recovery from their web client using locally stored data. Therefore, the wallet contract must store all the historical roots, and validate recovery operations not only against the current root, but also all the historical roots. The contract also needs to make sure that the leafs intended for recovery use (for any root) is "reserved" and not used for operations other than recovery. Since recovery leafs are very rare (1 per Extend operation), it would not impact wallet user experience (the user can simply wait for 30 seconds if coincidentally that they are trying to do something based on that leaf).
This is addressed in #178
The text was updated successfully, but these errors were encountered: