Change Details

When loading a proof in the wallet that created it, if the master key is one the auxiliary private keys, we can find the private key from the deserialized public key instead of making the user paste the key. This used to work with the assumption that we always use index 0 to derive the key for proofs. It was broken with D14603 when we made the program not reuse keys. Fix it by scanning up to 20 recently used auxiliary keys. Introduce a `StorageKeys` class to avoid repeating (and possibly mistyping) the storage keys and their default values.

When loading a proof in the wallet that created it, if the master key is one the auxiliary private keys, we can find the private key from the deserialized public key instead of making the user paste the key. This used to work with the assumption that we always use index 0 to derive the key for proofs. It is broken after D14603 which broke this assumption: the program now does not necessarily suggests key from index 0 when the user generates a second proof or uses keys for other purposes (delegations...) Fix it by scanning up to 20 recently used auxiliary keys. Introduce a `StorageKeys` class to avoid repeating (and possibly mistyping) the storage keys and their default values.

When loading a proof in the wallet that created it, if the master key is one the auxiliary private keys, we can find the private key from the deserialized public key instead of making the user paste the key. This used to work with the assumption that we always use index 0 to derive the key for proofs. It was broken with D14603 when we made the program not reuse keys.is broken after D14603 which broke this assumption: the program now does not necessarily suggests key from index 0 when the user generates a second proof or uses keys for other purposes (delegations...) Fix it by scanning up to 20 recently used auxiliary keys. Introduce a `StorageKeys` class to avoid repeating (and possibly mistyping) the storage keys and their default values.