EOS whitepaper walk-through: Account, Mandatory delayed actions and Account recovery.

In the last article we went over how permissions can be mapped to different accounts and actions, and how by separating permission evaluation and action logic, these processes can be run in parallel.

In this article, we'll go over how by setting a time delay in for certain actions, users can safeguard their account even if the account's private key gets comprised. This, combined with the ability to recover control over an account, provides EOS users a level of security unparalleled in the blockchain space. 

Actions with Mandatory Delay

Time is a critical component of security. In most cases, it is not possible to know if a private key has been stolen until it has been used. Time based security is even more critical when people have applications that require keys be kept on computers connected to the internet for daily use. The EOS.IO software enables application developers to indicate that certain Actions must wait a minimum period of time after being included in a block before they can be applied. During this time, they can be cancelled.

Users can then receive notice via email or text message when one of these Actions is broadcast. If they did not authorize it, then they can use the account recovery process to recover their account and retract the Action.

Time delay is useful for a number of things, but by attaching time delays to certain actions, it can become a tool for securing your funds. 

To be clear, once these transactions are received, the logic contain will still be process and the result ready to be applied. But because these actions have a time delay, they will only be applied when the specified time has arrived.

This ensures that the user has time to react to Actions being triggered on their account.

Bitcoin has something similar in its scripting language called NLockTime. But its main application is to prevent malicious miner behavior.

However, once a transaction is sent, there is no revoking it. One method is to send another transaction with no time lock and have that invalidate the previous one.

If someone's private key is comprised, there is no reason for the hacker to send a delayed transaction since he would want to move the money as quickly as possible, before the user can react.

By building time delay into specific actions, even if the account is comprised, the hacker cannot move all the funds out immediately, giving valuable time for the user to regain control of his account.

Since Actions can trigger a number events, one of them can be to send an email or sms tot the account holder. 

The required delay depends upon how sensitive an operation is. Paying for a coffee might have no delay and be irreversible in seconds, while buying a house may require a 72 hour clearing period. Transferring an entire account to new control may take up to 30 days. The exact delays are chosen by application developers and users.

For a payment application, there can be time delay set for specific thresholds. Anything under 10 dollars might not require any time-delay but for larger amounts, let's say 100,000 dollars, it might be wise to set a time-delay of a few days. The user then have the option to cancel the transaction in the intervening time.

Recovery from Stolen Keys

The EOS.IO software provides users a way to restore control of their account when keys are stolen. An account owner can use any owner key that was active in the last 30 days along with approval from their designated account recovery partner to reset the owner key on their account. The account recovery partner cannot reset control of the account without the help of the owner.

Similar to Steem, when a user registers for an account, there is usually an appointed trustee, for most people, this is usually Steemit.inc. But for those who have registered other people before, we know that as the person who register the account, we become the trustee of their account.

The trustee of the account does not have the private key or access of the account, all the trustee can do is start the recovery process of the account. At which point the user would enter the last known password. A new key is then issued and the account is back in the control of the account holder.

There is nothing for the hacker to gain by attempting to go through the recovery process because they already "control" the account. Furthermore, if they did go through the process, the recovery partner would likely demand identification and multi-factor authentication (phone and email). This would likely compromise the hacker or gain the hacker nothing in the process.

If a hacker comprises a private key, he would likely change the private key of the account, locking out the original owner. Then, when he has full control over the account, he would try to drain the account. Once the account holder is made aware of this, because of time-delayed actions that triggered a notification, the account holder would ask his recovery partner to start the process of recovering the account.

The hacker would like to try and trick the recovery partner, but he would have to provide information confirming his ownership of the account. And since he already have access to the account, there is nothing to gain in trying to trick the recovery partner. And it is unlikely this could happen unless he knows what kind of information the recovery partner requires and is able to obtain that information. 

This is much more difficult task and would likely prevent vast majority of the hacks in the cryptocurrency space. 

This process is also very different from a simple multi-signature arrangement. With a multi-signature transaction, another entity is made a party to every transaction that is executed. By contrast, with the recovery process the recovery partner is only a party to the recovery process and has no power over the day-to-day transactions. This dramatically reduces costs and legal liabilities for everyone involved. 

The recovery process is a permission action, but it is limited action. A recovery partner can only send a message to trigger the recovery process. Other than that, he cannot perform other actions on behalf of the account.

Bitcoin multi-sig wallets require both party to sign transactions, every time. Although this could prevent hackers from withdrawing the fund, it also means that every time you want to do send a transaction, you must contact the other party.

In the next article we'll go over how application logic can be run in parallel, a ground-breaking innovation in blockchain technologies.