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 first gives her family the chance to help her recover before steemit-cold has the opportunity to do any possible mischief.

Scenario: User's password (which doesn't derive owner keys) is hacked AND they lost their offline owner keys

There is a possibility that the times stated above will be extended considerably by the same amount if a malicious attacker (Mallory) was able to get access to Alice's active keys (but not owner keys). Imagine the scenario where Mallory hacks into Alice's computer, compromises her active keys, and uses it to change all the keys (other than owner which she cannot change). Now Alice was smart enough to use a separate owner password and not keep it on her online computer (otherwise Mallory would have compromised her owner keys as well), unfortunately she was careless in properly securing her offline owner password and so she lost it. Because Alice lost the owner keys, she cannot reclaim access back to her account immediately, thus giving Mallory time to wreak havoc to her account, steal liquid and even time-locked savings funds, and power down her Steem Power to slowly steal that as well. Even worse, Mallory could keep submitting proof of active authority to the blockchain to extend the period before the account becomes vulnerable to recovery/inheritance, so that she can continue to steal as much of her Steem Power as possible. With the contract setup above, Alice would have to wait at most 6 months (on average 3 months) before her account becomes vulnerable to recovery/inheritance. At that point, she must wait 30 more days before her family can help her recover the account (or 60 more days for steemit-cold to help her recover her account if her family is unable to for some reason). Thus on average, one would expect her to lose all of here SD and liquid STEEM (whether in time-locked savings or not), and to lose approximately 16% of her Steem Power (4 months of compromise out of 2 years) in this particular situation (assuming she wasn't already powering down at the time of compromise). While that is not great, the reality is that without this will/recovery feature, Alice would have lost 100% of her funds and her account name in this scenario.

Scenario: User passes away and spouse inherits entire account with all of its funds

Notice that in normal situations all the other will items (4 to 9) would not be activated prior to Alice recovering her account. But what if Alice actually passes away? If we assume the steemit-cold account follows the rules and doesn't grant anyone access to the account unless they can prove to be Alice, then after the appropriate time one (or more) of the inheritors can claim the account/funds they deserve. If Alice's husband Dave is still alive, he would submit the beneficiary claim as soon as possible (after her account becomes vulnerable to recovery/inheritance due to inactivity) that allows him to take over control of the entire account. He could then update the will contract appropriately to reflect the changed conditions. Of course whether he updates the will to still give a fair share of Alice's portion of funds to her parents is up to him. If Alice wanted to guarantee her parents and daughter can claim some percentage of her funds if she died before the rest of the account went to her husband, she could have modified the will contract to get that desired behavior.

Scenario: User passes away and some of their specified beneficiaries in the will contract are also dead

But what if both Alice and Dave died at nearly the same time (say they died together in a car accident). Let's assume Dave has a very similar kind of will contract (except with his parents as beneficiaries instead of Alice's parents and with "dave" replaced by "alice"). In the worst case scenario (assuming no one other than the original owner had access to their account's owner keys, and assuming steemit-cold does their job properly), it would take at least 70 days for Eve to take control of Dave's account (at the cost of giving up 20% of Dave's funds to his parents) and if she submitted a beneficiary claim on the alice account using the dave account as soon as possible after getting control of the dave account, it would be at a minimum 10 days after Bob or Carol had the opportunity to submit their claims on the alice account. This means the earliest her claim as dave could be activated would be 7 days after Bob or Carol's claim would be activated (assuming they didn't waste any time submitting their claims either). So given this scenario, it would not be possible for Eve to use this mechanism to claim 100% ownership of the alice account; she would be forced to give up 20% of Alice's funds to Alice's parents as well. Due to symmetry, the same situation applies if Eve were to try to take over the alice account first to then take over the dave account. So the will contract setup above (again with the given assumptions that no one other than the original owner had access to their account's owner keys and that steemit-cold does their job properly without conspiring with anyone) ensures that the parents of the deceased have a chance to claim their fair share of the funds.

Now what if some of the other beneficiaries were also deceased? Let's take the scenario where Dave and his parents had passed away long ago. Alice's account held all the funds (including funds she claimed from her deceased husband). She had 100 STEEM and 900 SD in time-locked savings; 100 SD in her regular liquid checking account; and she had 500 million VEST. Alice didn't bother changing the will contract above even though Dave passed away: no one other than herself had access to keys for the dave account, so it was as if will item 3 had no effect. Her daughter Eve was still alive and well, and both her parents were alive. Then one day Alice was driving her father Bob somewhere and they got into a fatal car accident and both died. In this case, after the necessary amount of time passed (somewhere between 70 days and 130 days after their death), the inheritance event would be activated either by one of Carol's beneficiary claims (the one associated with will item 5 which had "carol" as the specified account in the claim) or one of Eve's beneficiary claims (the one associated with will item 6 which had "eve" as the specified account in the claim); these two beneficiary claims would be the only ones in the set PARTIAL_CLAIMS for this inheritance event. At the time of the inheritance event, there would also be another beneficiary claim (associated with will item 9) submitted by Carol and another beneficiary claim (associated with will item 7) submitted by Eve. Eve's second beneficiary claim would likely have an earlier effective_on time than Carol's second beneficiary claim, so Eve's second claim which specified a new owner authority for alice that gives Eve control would be the one selected as FINAL_INHERITOR for this inheritance event.

In this scenario, according to the rules described in the previous section, total_claim_percent would be 70% and total_percent would be 80%. The claim_percent for Carol's beneficiary claim associated with will item 5 would be 11.11%, and so 11.110 STEEM and 111.100 SD is moved from alice to carol's time-locked savings account. In addition, an inheritance object is created that is initially tied to the carol account which holds 55.55 million VEST that was taken from the alice account. The claim_percent for Eve's beneficiary claim associated with will item 6 would be 66.67%, and so 66.670 STEEM and 666.700 SD is moved from alice to eve's time-locked savings account. In addition, an inheritance object is created that is initially tied to the eve account which holds 333.35 million VEST. And finally, the owner authority of the alice account, which now holds 22.220 STEEM and 222.200 SD in the time-locked savings account and also holds 111.10 million VEST, is changed to one Eve controls. So overall, Carol gets control over 11.110 STEEM, 111.100 SD, and 55.55 million VEST from the inheritance, and Eve gets control over 88.890 STEEM, 888.900 SD, and 444.45 million VEST from the inheritance as well as the account named alice.

The flexibility and power of this proposed feature

As can be seen from the above scenarios, this will contract feature enables powerful behaviors/outcomes and incredible flexibility to the user to play with the durations, will items, waiting_periods, percents, and authorities to get intended outcomes for both recovery of their account as well as inheritance of their funds and account after their death to their intended beneficiaries.

The feature described in this proposal is flexible enough to replicate the behavior of the feature currently proposed by Steemit to recover lost accounts. The user merely has to setup their will contract to have an active_proof_duration of 60 days, an owner_proof_duration set to a ridiculously large time duration such as hundreds of years, and a single will item with the recovery agent set up as the beneficiary authority, percent set to 100%, and waiting_period set to 30 days.

Grandfathering existing users during the hardfork and opting in new users into an appropriate will contract by default

As mentioned in the introduction, there are already reported cases of users claiming they lost or forgot the password to their account, and in fact those accounts have not been active for a while. Currently, there is nothing that can be done to help these users get back access to their account even when we have a way of clearly verifying their identity (for example, by using their Reddit/Facebook link or by comparing the face of the person claiming to have lost their account to the picture they included of themselves in their introduceyourself post). But even if the feature in this proposal was implemented, it wouldn't help the existing users who have already lost access to their owner keys unless we grandfathered existing accounts into a sensible will contract.

This may be somewhat controversial since it is valid to be concerned about a will contract imposed on you that could allow a third party that you didn't select to take over your account after some period of inactivity. It is important to understand that this grandfathering step is not necessary to have any of the other benefits explained in this proposal. But I would strongly recommend doing it, in a balanced way, so that we can help those who have already been hurt by losing their password.

The way I would like to see the grandfathering step be done is by resetting the last_active_proved of every account to the head block time at the time of the hardfork and by introducing a special one-time database object for each existing account that will be activated, unless cancelled, exactly at 60 days after the time the hardfork goes through. This object acts as a pending change to the will contract for its respective account which would modify the will contract to be as follows:

 active_proof_duration = 60 days
 owner_proof_duration  = 182 days
 Will items:
  1) beneficiary_authority = {"weight_threshold":1,"account_auths":[["steem", 1]],"key_auths":[]}
     waiting_period        = 30 days
     percent               = 100%

Or better yet "steem" would be replaced by "steemit-cold" which would be Steemit's account with cold active keys for extra security.

This special 60-day pending change can be cancelled by the user at any time within the 60 days after the hardfork by either submitting any change to their will contract (which requires owner authority) or by submitting active authority proof (using the prove_authority_operation which would only require active authority). Thus, users are given 60 days after the hardfork to opt-out of this change to their existing accounts without even needing to get their owner keys out (I would expect the steemit.com GUI to have this feature to opt-out using only active authority available and ready to go by the hardfork). By doing it this way, any existing accounts that have lost their password can wait three months after the hardfork, and then Steemit may be able to help them recover ownership of their account (if they have some way of proving identity).

New accounts created by Steemit would by default be opted into a particular will contract (likely the same one as the one above) at account creation time, which would require a new account create operation. Steemit could of course also allow the user to specify a custom will contract as an advanced option during account creation. So, by default new accounts registered by Steemit after the hardfork could also be potentially recovered by Steemit if the user loses their password (unless the user later decides to change the will contract to something that does not allow Steemit to help them recover).

An additional possible change to allow the blockchain to reclaim truly lost accounts?

There is an additional change I would personally like to see, but again this is not essential to make the rest of the proposal work as described above. There will be accounts that are truly lost. This means the original owner no longer has any access to the account, and with the way the will contract is set up, no one else can help them recover it or even inherit it for themselves. These accounts would just sit on the blockchain forever, and their funds would not be accessible to anyone. The market should eventually take into that those funds are lost, but there is always the possibility that someone might somehow find the keys in the future and bring those funds back into the market. Also, from an accounting perspective those funds are still recorded in the blockchain's current_supply and virtual_supply which inflates the rewards issued by the blockchain compared to what they should be. Even worse, the account name is forever taken away and no longer usable to alive people who may wish to use that name.

I believe that there should be a blockchain-enforced time limit of inactivity before some or all of the account's funds are reclaimed by the blockchain. And eventually, if the account is inactive for long enough, all the funds of the account should be seized and destroyed by the blockchain and the account name itself should be deleted so that it is free for someone else to claim in a new account. The exact details of how this should be done and what the time frames should be can be debated and worked out. Here I will propose a fairly straightforward procedure with what I think are sensible time limits.

If it has been 2 years since the last_owner_proved of the account, the blockchain would automatically null out the posting and active authority of the account. If it has been 2.5 years since the last_owner_proved of the account, the blockchain automatically nulls out the posting, active, and owner authorities of the account (of course keeping the old owner authority in the owner authority history). And if it has been 2.5 years + 30 days since the last_owner_proved of the account, the blockchain automatically destroys all SD, STEEM, and VEST held by the account, destroys all VEST held by any inheritance objects tied to that account, removes any withdraw options being sent to that account, and erases the account name so that it can then be claimed by anyone choosing to register an account with that name in the future.

The idea behind the three stages is to give sufficient warnings to particularly careless users. A user who hasn't bothered updating the owner keys (or proving owner authority) for over 2 years has a 6 month period during which they will not be able to log in to their Steem client as they normally do (since posting and active would be nulled) but can still easily get back control of their account. This would act as a warning to them that they have to update their owner keys, and so they would have plenty of time to grab their owner keys from cold storage and do what they need to do. Even if their main password derives the owner key and their client is designed poorly to accept logins using owner key directly without complaining, there would still be a 30 day period before their account is removed during which they couldn't even log in with their password to their poorly designed Steem client. They would then hopefully have enough time within that 30 day period to use their owner-key-deriving password and work with their recovery agent to recover access to their account, which would automatically reset the timer so that they would be safe again for at least another 2 years. Normally, the user wouldn't cut it this close. Their client could bug them every time they log in to change their owner keys (or at least submit an owner authority proof) if it has been a year since the last_owner_proved of the account (or actually it would likely bug them to do that if there are less than 30 days left until time when last_owner_proved would be owner_proof_duration older than the head block time). Better clients could even send the user email and/or text reminders as appropriate so that the user makes the appropriate proofs or owner key changes even if they wouldn't normally bother logging into the client for over a year.

Conclusion

The above proposal can be summarized as follows:

• User gets to decide how inactive they need to be (both in terms of actions requiring active authority and actions requiring owner authority) before their account is vulnerable to being taken away and having its funds claimed by other accounts (beneficiaries) that they have listed a priori in their will contract. They could set up the behavior so that the security implications are no different than they are today (effectively opting out of this feature).

• The will contract can be set up so that some specified beneficiaries have time to take over the account entirely before other beneficiaries are able to. It can also be set up to allow some set of beneficiaries to make a partial claim (with percentage specified by user in the will contract) on the user's funds as long as they do so by the appropriate time after the user's account has been sufficiently inactive.

• The will contract can be changed by the user's owner authority at any time after a 30 day waiting period.

• The user would typically set up the will contract so that one or more recovery agents they selected beforehand has the ability to transfer ownership of the account to the user (after doing proper identity verification) if the account has been inactive for a sufficient amount of time. And it would also likely be set up such that if the recovery agents did not transfer ownership of the account by the specified time (likely because the user is actually dead), then other accounts specified in the will contract can inherit part of the funds in the user's account (and one of those accounts would also receive ownership of the account itself with whatever funds it had remaining after paying out the other beneficiaries).

• If existing accounts are grandfathered in appropriately, we may be able to help many of those users who have already lost access to their account because they lost or forgot their password. The annoyance to other users who wish to opt-out of that will contract is very minimal (only requires logging in to steemit.com within 60 days after the hardfork with their active key to opt-out, or alternatively they could do it via a single command in the CLI).

• As an additional optional feature (if the community chooses to adopt it through a hardfork), we could have blockchain-enforced owner inactivity time limits on all accounts as a way of allowing the blockchain to reclaim truly dead accounts and their locked up funds. If the community were to proceed with such a change (which isn't necessary to get all the other benefits of this proposal), accounts could not opt-out of that particular change. However, the inactivity time limits before the account is destroyed would be fairly lax (over 2 years) so that it wouldn't add any serious inconvenience to users.