Way back in May 2020

In the long long ago of the hostile takeover.
I discovered a terminology dubbed "reset account" in the Hive API.
This was much different from, and not to be confused with, "recovery account".

Of course when I tried to actually use this feature I got an error.

Leading me to wonder: why is this feature still disabled?
It's already programmed into the network; baked into the cake.
Just flip a switch and let it happen already!

Difference between reset and recovery.

Recovery accounts are one of Hive's coolest features. Even if a bad actor steals our account and transfers all the liquid assets, it can still be recovered along with all the non-liquid (locked) assets. Because of the way Hive works many of us are highly incentivized to lock the majority of our stake. Even in the worst case scenario, the theft of our private key, we can still recover and live to see another day.

The problem with the recovery process is that it only works to thwart bad actors. It does not help mitigate user error and the personal loss of private keys. This is where a reset option would be very useful, as an account reset does not require an old private key like recovery does. I have at least two personal friends that I signed up to Hive who misplaced their keys and lost their account in this way.

They simply didn't care to keep their private keys safe and secure. Why? Because their accounts are worth very little, and there is a WEB2 expectation that even if a password gets lost someone should be able to reset it. We have this functionality ready to go and it just sits disabled. Why?

---

The most obvious reason why reset accounts are not allowed on Hive is that they introduce a novel attack vector into the ecosystem. Let's assume an account was inactive for 60 days but they hadn't actually lost their keys. If this person had a reset account active then this account would have the authority to change the owner key and could theoretically steal it from them.

While it seems like the odds of something like that happening are low, especially when concerning significant sums of money, it is still bound to happen to someone. The question then becomes: does the reset feature do more harm than good? Certainly I would argue that this is not the case and we should at least test the feature before throwing the baby out with the bathwater.

Recovery accounts, on the other hand, are set up in a very impressive way that adds zero additional attack vectors into the system. A recovery account could never steal the account they are supposed to be recovering... unless they had already stolen it previously or started colluding with someone who did. How is this possible?

Recovery process on Hive:

1. The person who had their account stolen has 30 days to post an operation to the chain using an owner-key that used to be valid. This operation indicates the account has been stolen and signals a new public-key to the blockchain requesting that the owner-key be changed to it.

2. The owner-key will only be modified to the new public-key on-chain if and only if the recovery account signs it using their active key. In this regard we can think about account recovery on Hive as a layer-zero solution that exists off-chain. The recovery account has a duty to make sure that the entity that issued the request is the true owner of the account. This could be accomplished in a myriad of ways including, but not limited to, WEB2 confirmation (Discord/Twitter/Facebook), email/password logins, or simply calling your friend on the phone.

Because recovery requires access to an old key it is implied that this feature can only help the network and not hurt it. No bad actors were supposed to ever have access to that password in the first place, and if recovery should fail it wouldn't be due to adding extra risk to the platform. It's actually quite an elegant solution.

Unfortunately there are many changes that could be made to Hive that would completely destroy the usefulness of account recovery.

1. The first one I can think of is the ability to powerdown instantly with a penalty being applied to the principal amount. This function has been pitched more than a few times. A bad actor would take this deal every time, drain the account completely, and leave the true owner with an empty husk with no stake left.

2. The second way to undermine account recovery is by removing the reward pool. This is an idea that keeps getting pitched during bear markets even though the math of it all doesn't seem to add up and basically kills the core function of the entire network. There will actually be a big "town hall" discussion revolving around this topic in two weeks at the very beginning of next month.

Definition of inactive

Circling back to reset accounts, it's also a little unclear as to what "inactive" means on a technical level. Many have posited that an account would not be considered inactive if they gave posting key authority to an upvote train that signed operations on their behalf. I personally think that's a big assumption to make, and even if it was true we could just change the definition of "activity" to mean the operation was signed with a base key rather than a granted authority.

Opt in

It should also be noted that all reset accounts are @null by default, meaning that one must purposefully allow a reset account to exist if they so choose. Again with these kinds of mechanics in play it's difficult to see why the function would be disabled.

Wrench attacks

In theory a reset account could create an incentive to kidnap someone for 60 days if the reset account was the kidnapper or colluding with said bad guys. Obviously that would be a pretty suboptimal experience, but again if there was really that much money on the line reset accounts shouldn't be used in that situation and the user in question should employ other security measures. The reset feature makes a lot more sense for small new accounts that expect a WEB2 experience.

---

There's also the possibility that the creator of a new account would set themselves as reset account in addition to being auto recovery. In fact this is to be expected for the achievement of a WEB2 experience. It could be argued that this is too much power to give a single centralized agent.

However this would basically be preying on new users who don't know any better and could be spotted by more savvy users quite quickly. It seems unlikely that anyone would risk their reputation in this way on the off-chance that a new user stacked a bunch of stake and then decided to disappear for 2 months.

Conclusion

In my option enabling the opt-in reset function on Hive is a necessary step going forward given the adoption of new users. I have personally already witnessed two close friends misplacing their keys and losing their accounts forever simply because they assume it isn't that big of a deal. Now all nodes on Hive will forever track those lost accounts in the database for little reason even if they contain zero value. All I can say is that the optics appear to be quite frustratingly wasteful. New users should have more get-out-of-jail free cards especially when just starting out in low-stakes mode.

Hive has a lot of advantages over other chains and many of those advantages are derived from our unique form of explicit accounting. As a network we have to expend a little bit more computing power keeping track of account metadata. This allows us to do cool things like having a readable usernames that can accept money directly, changing our keys, building reputation, and recovering accounts. I see little reason to deny adding a 60-day inactive reset option considering all the work for it has already been completed in a hardfork long past.