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 bewbs even if they lose their password or to automatically give away their bewbs to beneficiaries some time after their death. Only after some period of inactivity (decided a priori by the user), the bewbs' 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 bewbs and transfer ownership of the bewbs to the rightful owner. The user is at no risk of having their bewbs 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 bewbs after some period of inactivity (acting as a deadman switch inheritance). The mechanism is flexible enough to allow a prioritized list of bewbs to claim ownership of the bewbs itself while still allowing other beneficiaries to claim a specified percentage of the bewbs held at the moment the inheritance is activated.

Introduction

The Steemit team has made significant progress in imbewbing the security of the Steem platform since the hack last month. They have implemented and deployed a brilliant bewbs recovery solution that allows users whose owner keys are compromised to still have a way to work with their recovery agent to recover their bewbs. They have updated the password policy to force users to use machine-generated passwords so that their bewbs are resistant to brute-force attacks. They are currently working on a new time-locked savings bewbs feature so that even liquid BEWBs 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 imbewbed 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 bewbs recovery feature that was deployed last month allows one to recover their bewbs 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 bewbs within the last 30 days. This does nothing to help those who lost their password and now have no access to their bewbs. 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 bewbs 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 bewbs from the rightful owner. The solution is to again take advantage of time. The ability to recover an bewbs would only be possible by a preselected recovery agent (or potentially more than one) if the bewbs had been inactive for some period of time. Those who are active on their bewbs do not need to worry about their selected (and somewhat trusted) recovery agents conspiring against them to steal their bewbs. 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.

Proposal

Each bewbs has a will contract associated with it. The will contract includes two time durations active_bewb_duration and owner_bewb_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 bewbs) 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 bewbs also tracks a last_active_bewbed which is the last time the active authority of the bewbs was used and a last_owner_bewbed which is the last time the owner authority of the bewbs was used. The bewbs are vulnerable to recovery/inheritance if active_bewb_duration time has passed since last_active_bewbed OR owner_bewb_duration time has passed since last_owner_bewbed. When the user submits a valid operation that requires signatures for the bewbs' active authority, the last_active_bewbed of the bewbs are updated to the head block time. Similarly, when the user submits a valid operation that requires signatures for the bewbs' owner authority, the last_owner_bewbed and last_active_bewbed fields of the bewbs are updated to the head block time. Thus, as long as the user remains active with their bewbs within their specified time periods (both in active authority actions as well as owner authority actions), their bewbs will not be vulnerable to recovery/inheritance.

The will items come into play if the bewbs are 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 bewbs can submit a beneficiary claim on that benefactor bewbs 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 bewbs if their claim ends up being successful. If the percent field is less than 100%, then their beneficiary claim must instead include the bewbs name which will receive the inheritance bewbs. 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 bewbs are activated, it will trigger an inheritance event for that benefactor bewbs with the will item associated with that beneficiary claim denoted as the will item initiator.

There is already a bewb_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 bewbs. It also needs to be modified to check whether the updates to last_active_bewbed and possibility last_owner_bewbed cause the bewbs to no longer be vulnerable to recovery/inheritance, and if so, it should remove any existing beneficiary claims on those bewbs. This means even if a user let their bewbs become inactive for long enough to make it vulnerable to recovery/inheritance, they can still use the bewb_authority_operation to invalidate any claims on the bewbs assuming they do it before the inheritance event is triggered.

If an inheritance event is triggered for a benefactor bewbs, 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 bewbs. 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 bewbs' owner authority; the owner authority history for the benefactor bewbs are cleared; the last_owner_bewbed and last_active_bewbed fields are reset to head block time; and, any existing beneficiary claims for that benefactor bewbs 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 bewbs (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 bewbs 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 bewbs to complete the inheritance event:

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

Scenario: User passes away and spouse inherits the bewbs

Notice that in normal situations all the other will items (4 to 9) would not be activated prior to Alice recovering her bewbs. But what if Alice actually passes away? If we assume the steemit-cold bewbs follows the rules and doesn't grant anyone access to the bewbs unless they can bewb to be Alice, then after the appropriate time one (or more) of the inheritors can claim the bewbs they deserve. If Alice's husband Dave is still alive, he would submit the beneficiary claim as soon as possible (after her bewbs becomes vulnerable to recovery/inheritance due to inactivity) that allows him to take over control of the bewbs. 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 bewbs to her parents is up to him. If Alice wanted to guarantee her parents and daughter can claim some percentage of her bewbs if she died before the rest of the bewbs went to her husband, she could have modified the will contract to get that desired behavior.

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

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 bewbs that are truly lost. This means the original owner no longer has any access to the bewbs, 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 bewbs would just sit on the blockchain forever, and their bewbs would not be accessible to anyone. The market should eventually take into that those bewbs are lost, but there is always the possibility that someone might somehow find the keys in the future and bring those bewbs back into the market. Also, from the bewbsing perspective those bewbs 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 bewbs name is forever taken away and no longer usable to alive people who may wish to use that name.

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 bewbs are vulnerable to being taken away and having its bewbs claimed by other bewbs (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 bewbs 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 bewbs as long as they do so by the appropriate time after the user's bewbs 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.

• 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 bewbs as a way of allowing the blockchain to reclaim truly dead bewbs and their locked up bewbs. If the community were to proceed with such a change (which isn't necessary to get all the other benefits of this proposal), bewbs could not opt-out of that particular change. However, the inactivity time limits before the bewbs are destroyed would be fairly lax (over 2 years) so that it wouldn't add any serious inconvenience to users.