Summary

The current system for freezing EOS accounts in response to ECAF Arbitrator emergency orders is broken as evidenced by the loss of 11,295 EOS this week. ECAF takes an extraordinary step to break its normal silence on matters of implementation policy to publicly request BPs to replace the current, unfit for purpose, blacklist method for freezing accounts with the use of eosio.sudo/eosio.wrap.

The blacklist

In EOS claimants have the possibility to request an emergency freeze of their EOS accounts in response to a loss of control of their account or the funds contained within (such as a result of hacking, phishing etc). Claimants typically do this by filing an Arbitration case with the EOS Core Arbitration Forum (ECAF) and requesting emergency protection.

An ECAF Emergency Arbitrator will review the case and if they find it has merit order the Block Producers (BPs) to freeze the account(s). This is where ECAF’s responsibility for the immediate order ends: the separation of powers in EOS means that the implementation of ECAF Arbitrator’s emergency freeze orders are left to the BPs.

Typically ECAF does not publicly comment on the implementation methods chosen by BPs to enact these emergency freezes. However, events over the last week leave us with no choice but to do so.

Emergency freezes are currently implemented using a so-called blacklist. This involves all 21 active BPs maintaining a table listing accounts that are not allowed to perform outgoing transfer operations. By its nature the blacklist is fragile; if even one BP misses updating its blacklist table then the alleged hacker can still make transactions from the account. This can happen for a multitude of very benign reasons e.g. a BP may have applied the blacklist to its main server but missed to apply it to the backup servers.

11,295 EOS lost

On Friday 12th October ECAF received two filings alleging phishing of their private keys from an allegedly fake ‘EOSBlack’ website. The website had allegedly taken the claimant’s private keys and used those to drain the claimant’s liquid EOS and commenced unstaking of the remaining EOS. In total around 11,295 EOS was at risk. The claimants requested an emergency freeze of their accounts before the 3 day unstaking period elapsed.

This was the perfect situation for an emergency freeze; a majority of tokens staked, a clear 3 days to apply an emergency freeze, plus fast and responsive claimants. Upon review of the cases the Emergency Arbitrator ordered the accounts frozen:

https://eoscorearbitration.io/wp-content/uploads/2018/10/ECAF-Order-of-Emergency-Protection-2018-10-12-AO-014.pdf
https://eoscorearbitration.io/wp-content/uploads/2018/10/ECAF-Order-of-Emergency-Protection-2018-10-13-AO-015.pdf

This was communicated to BPs through on chain communication from ECAF’s EOS account plus by adding the frozen accounts to a blacklist smart contract that is monitored by BPs: https://bloks.io/account/theblacklist

All of this took place with at least 24 - 48 hours left before the first tokens were unstaked. Ample time for a blacklist to be applied.

Unfortunately, the assets were still able to be transferred out to exchanges long after the emergency order was issued.

It is frustrating for ECAF to see its hard work go to waste. But even more importantly there are real people behind each one of those accounts. People who thought their accounts were safe but may now have lost a significant part of their savings as a result.

What next?

There has been debate within ECAF as to whether we should stop processing emergency freezes until this situation can be resolved. For now, we will not do that as we have a duty to serve the claimants.

This is not the first or even second time this has happened. It is actually the third. Enough!

We see no reason for BPs to continue using a system for freezing accounts that has been shown to be so utterly unfit for purpose. BPs can use other methods to achieve the same in a much more robust way, for example by using the eosio.sudo/eosio.wrap function to nullify the account keys (with 15/21 consensus) thus ensuring that accounts are frozen until such a time as an Arbitrator can make a final ruling.

Alternatively, if BPs insist on continuing to use the fragile blacklist to freeze accounts then let them sign up to a service agreement specifying the maximum time to apply a freeze order. And to agree that once 15/21 have applied a freeze order then any subsequent transactions in breach of the order are the responsibility of the BP that executed the transaction.

Thank you,
ECAF
https://eoscorearbitration.io/