This proposal discusses a new set of features and operations for the Steem blockchain which allows a user to either eventually regain control of their account even if they lose their password or to automatically give away their funds and account to beneficiaries some time after their death. Only after some period of inactivity (decided a priori by the user), the account's owner authority can be changed by a preselected set of recovery agents that the user trusts to do proper identity verification on those claiming to own the account and transfer ownership of the account to the rightful owner. The user is at no risk of having their account seized as long as they remain active within the time periods they specify in their will contract. The mechanism also allows a set of beneficiaries that are set up beforehand by the user to claim the account and its funds after some period of inactivity (acting as a deadman switch inheritance). The mechanism is flexible enough to allow a prioritized list of accounts to claim ownership of the account itself while still allowing other beneficiaries to claim a specified percentage of the funds (SD, STEEM, and Steem Power) held in the account at the moment the inheritance is activated.

Introduction

The Steemit team has made significant progress in improving the security of the Steem platform since the hack last month. They have implemented and deployed a brilliant account recovery solution that allows users whose owner keys are compromised to still have a way to work with their recovery agent to recover their account. They have updated the password policy to force users to use machine-generated passwords so that their accounts are resistant to brute-force attacks. They are currently working on a new time-locked savings account feature so that even liquid STEEM and SD can be protected from hacks (assuming the user detects the attack and responds appropriately within 3 days). I have made additional suggestions regarding how security could be further improved by separating out the password that derives to owner keys so that it can be securely kept offline, and adding multisig 2FA protection for active and posting authorities.

This proposal discusses another feature that I think is essential for the platform. The novel account recovery feature that was deployed last month allows one to recover their account by working with a recovery agent (that does appropriate identity verification to verify who true owner is) only if the owner also possesses the owner keys that were active for the account within the last 30 days. This does nothing to help those who lost their password and now have no access to their account or funds. We already have several reported cases of users suffering from such a situation, and there is currently no way to help them. Many would like to see a feature that can help the true owner recover their account even if they lost their password. But this is a tricky problem, since that feature could also be used by malicious actors to steal the account from the rightful owner. The solution is to again take advantage of time. The ability to recover an account would only be possible by a preselected recovery agent (or potentially more than one) if the account had been inactive for some period of time. Those who are active on their accounts do not need to worry about their selected (and somewhat trusted) recovery agents conspiring against them to steal their account. And of course this feature would be optional. Those who do not want to worry about this potential vulnerability could disable it and take on the responsibility of ensuring their password/keys are never lost as they do today.

Steemit is already working on such a feature but in my opinion their approach is not flexible enough. The approach I will discuss in this proposal gives the user more choice regarding how recovery can occur and by whom. But it also adds an additional feature that is not at all discussed in Steemit's proposal which I think is a very important feature to have on this platform: inheritance. People have earned tokens worth a considerable amount of money. It would be shame if that would die along with the original owner. It is possible to set up keys and owner authorities in such a way to allow beneficiaries to take over the account after the user's death, but the process requires some trust that the beneficiaries do not conspire against you to steal one's account before their death (it also requires a lot of trust, and likely lawyers, if you wish to divide the funds between multiple parties rather than just giving the whole account to a particular person who may not even be alive at that point). Ideally, we would like a blockchain feature designed particular for this purpose. The reader will see that the will / inheritance feature of this proposal is merely an extension of the feature to allow a user to recover an account after losing their password.

Proposal

Each account has a will contract associated with it. The will contract includes two time durations active_proof_duration and owner_proof_duration as well as a list of zero or more items (but with a maximum blockchain-imposed limit on the number of items allowed). Each will item specifies a beneficiary using the beneficiary_authority field, as well as a waiting_period time duration (for which the blockchain enforces a minimum of 30 days) and a percent field accepting percentage values between 0% and 100%. The user can use their owner authority to change any of the parameters of their will contract (including adding and removing will items) by submitting the appropriate change operations to the blockchain and waiting 30 days for them to be activated unless they were cancelled (again by owner authority of the account) prior to the time of activation. The blockchain tracks the number of will items of a will contract and will prevent adding a new will item to a will contract if it would cause the number of will items to exceed the blockchain-enforced limit (this is for performance reason). The blockchain also tracks a field total_percent in the will contract that is the sum of the percent fields for all will items in the will contract for which the percent field is strictly less than 100%. A change to the will contract is not allowed if it would cause the value of total_percent to exceed 100%.

Each account also tracks a last_active_proved which is the last time the active authority of the account was used and a last_owner_proved which is the last time the owner authority of the account was used. The account is vulnerable to recovery/inheritance if active_proof_duration time has passed since last_active_proved OR owner_proof_duration time has passed since last_owner_proved. When the user submits a valid operation that requires signatures for the account's active authority, the last_active_proved of the account is updated to the head block time. Similarly, when the user submits a valid operation that requires signatures for the account's owner authority, the last_owner_proved and last_active_proved fields of the account are updated to the head block time. Thus, as long as the user remains active with their accounts within their specified time periods (both in active authority actions as well as owner authority actions), their account will not be vulnerable to recovery/inheritance.

The will items come into play if the account is inactive enough to be vulnerable to recovery/inheritance. A user that can satisfy the beneficiary_authority of a will item in the will contract of some benefactor account can submit a beneficiary claim on that benefactor account if it is in a state of being vulnerable to recovery/inheritance. The type of beneficiary claim they can submit is dependent on what the corresponding percent field is for the will item their claim corresponds to. If the percent field is exactly 100%, then the beneficiary claim must include a new owner authority to eventually replace the owner authority of the benefactor account if their claim ends up being successful. If the percent field is less than 100%, then their beneficiary claim must instead include an account name which will receive the inheritance funds. The beneficiary claim can be cancelled by the beneficiary_authority that submitted it at any time. It can also be replaced (in the case where percent is 100%) to include a new owner authority to replace the old one in the beneficiary claim. There can only be one beneficiary claim associated per will item at any given time. As soon as a valid beneficiary claim is submitted to the blockchain, it starts a timer that will go off on the time effective_on (the timer is not reset if the beneficiary claim is replaced) which will activate that claim. The effective_on time is waiting_period (the one corresponding to the associated will item) duration added to the head block time of the block including the beneficiary claim. When the first beneficiary claim associated with a benefactor account is activated, it will trigger an inheritance event for that benefactor account with the will item associated with that beneficiary claim denoted as the will item initiator.

There is already a prove_authority_operation that exists on the blockchain. It needs to be modified so that it can work even if there are no active or owner challenges on the account. It also needs to be modified to check whether the updates to last_active_proved and possibility last_owner_proved cause the account to no longer be vulnerable to recovery/inheritance, and if so, it should remove any existing beneficiary claims on that account. This means even if a user let their account become inactive for long enough to make it vulnerable to recovery/inheritance, they can still use the prove_authority_operation to invalidate any claims on the account assuming they do it before the inheritance event is triggered.

If an inheritance event is triggered for a benefactor account, its behavior depends on the percent field of the will item initiator of that inheritance event. It also depends on whichever other pending beneficiary claims exist on the blockchain associated with that benefactor account. If the percent field of the will item initiator is 100%, then the behavior is straightforward: the new owner authority in the beneficiary claim associated with the will item initiator replaces the benefactor account's owner authority; the owner authority history for the benefactor account is cleared; the last_owner_proved and last_active_proved fields are reset to head block time; and, any existing beneficiary claims for that benefactor account are removed.

If the percent field of the will item initiator is instead less than 100%, then the behavior is considerably more complicated. At the time of the inheritance event, the blockchain looks for any beneficiary claims associated with the benefactor account (including the one associated to the will item initiator) that have a percent field that is strictly less than 100%. The beneficiary claims are included in a set denoted PARTIAL_CLAIMS. The blockchain also looks for any beneficiary claims associated with the benefactor account that have a percent field exactly equal to 100%. Of these found beneficiary claims, the blockchain selects the beneficiary claim with the earliest effective_on time and denotes that beneficiary claim FINAL_INHERITOR. The sum of the percent fields of beneficiary claims in set PARTIAL_CLAIMS (which is denoted total_claimed_percent) cannot exceed total_percent which in turn cannot exceed 100% because of the blockchain restriction described earlier. So, we know that 0% < total_claim_percent <= total_percent <= 100%. The blockchain then calculates a claim_percent for each beneficiary claim in set PARTIAL_CLAIMS as follows: claim_percent = percent / (100% + total_claim_percent - total_percent) (where percent is the percent field of the will item associated with the beneficiary claim).

The blockchain then does the following to the benefactor account to complete the inheritance event:

1. It pulls out all funds in the account's time-locked savings accounts immediately. It cancels any power downs / advanced withdraw options.
2. It then distributes the respective claim_percent fraction of the liquid STEEM and SD funds to the time-locked savings accounts of the accounts specified in the beneficiary claims in set PARTIAL_CLAIMS. It then moves all the remaining liquid STEEM and SD funds of the benefactor account to the account's own time-locked savings account.
3. It then creates an inheritance object associated to each account specified in the beneficiary claims in set PARTIAL_CLAIMS and adds to each inheritance object a certain amount of VEST taken from the benefactor account (calculated using claim_percent fraction of original VEST amount held by the benefactor account).
4. It then changes the owner authority of the benefactor account to the one specified in the FINAL_INHERITOR beneficiary claim, then clears the owner authority history for the benefactor account, and then the last_owner_proved and last_active_proved fields of the benefactor account are reset to head block time.
5. And finally, any existing beneficiary claims for that benefactor account are removed.

Each inheritance object is tied to a specific account (originally the one it was created for during the inheritance event). It holds a certain amount of VESTs that can be withdrawn using the same advanced withdraw options available to the VEST holdings of regular accounts (however VEST cannot be added into the inheritance object and they cannot be withdrawn as STEEM into the inheritance object but instead only to a separate account). The VESTs in the inheritance object do not count towards the voting power of the account they are tied to. The owner authority of the account that the inheritance object is tied to can submit a cancellable operation that after 30 days changes the account name that the inheritance object would be tied to. If the last of the VESTs in an inheritance object have been converted to withdrawn STEEM, the inheritance object is automatically removed from the database. The typical idea is for the beneficiaries to each setup the withdraw options of the inheritance objects they inherit shortly after inheritance to automatically move the Steem Power from the inheritance object to their own account over the course of two years. However, they could also just sell the entire inheritance object to a buyer (by using the mechanism to change the account it is tied to) at a discounted price if they are in desperate need for liquid money. Although this mechanism allows VESTs to be a little more divisible and transferable, the important powers VESTs give to accounts (specifically curating power) still takes 2 years to fully transfer over to a new account. These mechanisms are interesting however for people who wish to sell their account name quickly (2 months rather than 2 years) without being forced to also sell the VESTs held with the account; they would of course still need to wait 2 years before they can realize the full curation power of the VESTs that they kept. In the future, it could potentially be possible to simply merge all of the VESTS in an inheritance object into an existing account after waiting the appropriate amount of blockchain-enforced time (assuming the implications for potential games on curation rewards and other vulnerabilities are properly thought through for enabling such a feature).

Typical usage of the feature

The best way to see how this feature would work is to go through a typical setup and various scenarios. User Alice might set up her will contract (after a 30 day waiting period) as follows:

Will contract for alice:
 active_proof_duration = 60 days
 owner_proof_duration  = 182 days
 Will items:
  1) beneficiary_authority = {"weight_threshold":4,"account_auths":[["bob", 1], ["carol", 1], ["dave", 2], ["eve", 2]],"key_auths":[]}
     waiting_period        = 30 days
     percent               = 100%
  2) beneficiary_authority = {"weight_threshold":1,"account_auths":[["steemit-cold", 1]],"key_auths":[]}
     waiting_period        = 60 days
     percent               = 100%
  3) beneficiary_authority = {"weight_threshold":1,"account_auths":[["dave", 1]],"key_auths":[]}
     waiting_period        = 67 days
     percent               = 100%
  4) beneficiary_authority = {"weight_threshold":1,"account_auths":[["bob", 1]],"key_auths":[]}
     waiting_period        = 70 days
     percent               = 10%
  5) beneficiary_authority = {"weight_threshold":1,"account_auths":[["carol", 1]],"key_auths":[]}
     waiting_period        = 70 days
     percent               = 10%
  6) beneficiary_authority = {"weight_threshold":1,"account_auths":[["eve", 1]],"key_auths":[]}
     waiting_period        = 70 days
     percent               = 60%
  7) beneficiary_authority = {"weight_threshold":1,"account_auths":[["eve", 1]],"key_auths":[]}
     waiting_period        = 80 days
     percent               = 100%
  8) beneficiary_authority = {"weight_threshold":1,"account_auths":[["bob", 1]],"key_auths":[]}
     waiting_period        = 90 days
     percent               = 100%
  9) beneficiary_authority = {"weight_threshold":1,"account_auths":[["carol", 1]],"key_auths":[]}
     waiting_period        = 90 days
     percent               = 100%

So what does the above contract setup mean? First, it means that Alice's account is safe as long as she both does something to prove active authority with span between such events no greater than 60 days (this can be easily satisfied by making a transfer once a month) and does something to prove owner authority with a span between such events no greater than 182 days (this can be satisfied by either updating owner keys or just making an owner proof once every quarter).

Scenario: User loses their password

But what if she loses her password and wants to recover her account? She can simply wait up to 90 days (minimum of 30 days; depends on last_active_proved value at the time she realizes she lost her password) and then she can work with her family to recover access to her account. Her husband Dave can work with either their daughter Eve or both of Alice's parents, Bob and Carol, to change the owner authority of the alice account to keys that Alice controls. Alternatively if Dave is unavailable for some reason, she can work with both of her parents and her daughter to recover access to her account. Of course it is possible that her family might conspire against her to steal her account and funds, but it is unlikely since she trusts her family and also no one person alone can do so with the way the contract is set up. If for some reason she is unable to work with her family to regain access to her account, she could wait an additional 30 days (one can assume she requested the steemit-cold recovery account to submit a beneficiary claim at the same time her family did as soon as her account became vulnerable to recovery/inheritance as a backup to not delay any further) and instead rely on her selected recovery agent to restore access to her account (after she submits necessary proof of ID). The steemit-cold account would be an account run by professionals that have a good reputation so she wouldn't be too worried about them just stealing her account; nevertheless to be extra cautious, with the way she set up the will contract, she