Ability to renew a wallet's lifespan (extending "Expire At" date)

[polymorpher]

By default, one year worth of partial proofs are computed when a 1wallet is created. See https://github.com/polymorpher/one-wallet/wiki/Web-Client:-Data-Stored-Locally. A "root" is computed based on these partial proofs and is passed as a parameter during wallet creation. Subsequently, the root is used to validate almost every wallet operation during that one year. See https://github.com/polymorpher/one-wallet/blob/43197c70e36cb58c2884c423c1e665feff232042/wiki/protocol.pdf. Here, we refer to the one-year validity period of the wallet as its "lifespan", its creation time as "effective time".

One year is not enough for many use cases, to name a few: long-term asset storage, DAO signatory, treasury account, and many more. Naturally, there should be a way to extend the wallet's lifespan, ideally within the same smart contract (and its address). The process would be distinguishable from "Upgrade", which involves creating a new smart contract (with upgraded code) and transferring assets associated with the original smart contract to the new one. Extending the wallet's lifespan only requires reassigning the root of in the wallet's smart contract to a new value, computed using the same seed (stored on Google Authenticator or elsewhere) using a new "effective time" and lifespan. This can be achieved by adding a new type of operation in the wallet that specifically reassigning the root to a new value. The operation should require the highest level of security clearance (all composable security measures, if available) since a root can be potentially assigned to an invalid value or attacker controlled value, causing the user to lose access. In other words, this operation should make sure to the best extent possible that the operator is the user who owns the wallet and set up all the security measures associated with the wallet. From the user's perspective, this means at least the user is expected to type in their 6-digit authenticator code to complete this operation. Since the new root must be computed from the authenticator seed, the user is also expected to transmit the seed from the authenticator (for example, via QR code export and scan, similar to Restore process) to the wallet client. However, for third-party wallet apps (based on 1wallet) that have built-in authenticator mechanism and store the seed locally, the app may automate this process in the background.

Another notable benefit of adding this renewal operation is that a wallet app (using 1wallet under the hood) can initially generate a wallet with much shorter lifespan during onboarding process, and renew the wallet later. Since the computation time is linearly proportional to the lifespan parameter during the wallet creation process, this may substantially reduce user wait time and improve user experience. For example, an app can generate a wallet with only 1-month lifespan during onboarding, and only to extend its lifespan in the background after the user starts to use the wallet later.

This features is expected to be deployed within the next week (week of Nov 1, 2021). Implementing this feature requires changing the smart contract code therefore a new major version will be released (users must upgrade their wallet to use it).

[polymorpher]

The contract side is done in #178. Pending some tests and client side implementations in the same PR.

[polymorpher]

See also discussions in #179