BSIP65: Fix Locked Accounts

bsip-0061.md

@@ -0,0 +1,182 @@
+    BSIP: TBD
+    Title: Fix locked accounts with circular dependencies
+    Authors: OpenLedgerApp <https://github.com/OpenLedgerApp>
+    Status: Draft
+    Type: Protocol
+    Created: 2019-02-22
+    Updated: 2019-03-01
+    Discussion: https://github.com/bitshares/bsips/issues/94
+    Worker:
+
+
+# Abstract
+Every account has two authorities assigned: owner and active.
+
+An authority is a set of keys and/or accounts, each of which is assigned a weight.
+Each authority has a weight threshold that must be crossed before an action requiring that authority may be performed.
+The owner authority is designed for cold-storage, and its primary role is to update the active authority or to change the owner authority.
+The active authority is meant to be a hot key and can perform any action except changing the owner authority.
+
+BitShares has locked accounts with circular dependencies. Some of them are locked by mistake. So, locked accounts couldn't buy/sell their assets, make transfer and e. c.
+
+The community has had extensive discussions about how to resolve this issue:
+
+    1. To add additional functionality "avoid circular dependencies"to the nearest hard fork;
+    2. To find all locked accounts with circular dependencies and undo the last account_update operation.
+
+There are some cases that led to locked account:
+
+    - Alice updates, via account_update_operation, her active and owner authority to herself;
+    - Bob updates, via account_update_operation, his active and owner authority to a locked account;
+    - Jill updates, via account_update_operation, her active and owner authority threshold greater than a sum of authorities weights.
+
+This proposal is to implement a hard-fork that would prevent it in the future and to make posible unlock locked accounts.
+New operation unlock_account will be added, account_update_evaluator and account_create_evaluator will be modified.
+
+# Motivation
+Current BitShares implementation has no mechanism to unlock accounts and doesn't prevent the appearance of locked.
+
+There are two important objectives this proposal aims to achieve:
+
+    - to allow users to unlock their accounts;
+    - to prevent circular dependencies.
+
+This solution allows:
+
+    - to resolve user complaints;
+    - to increase confidence in BitShares.
+
+# Rationale
+## Prevent circular dependencies
+To prevent circular dependencies account evaluators should contain verificaton code that detects cycled authorities. The new function `verify_cycled_authority()` traverses down the hierarchy of accounts and checks if the transaction can be potentially signed with this account. To avoid any misunderstanding of existing authorization mechanism the `sign_state` class will be reused. Parametrizing this class with `verify_only`-flag helps to do code of `verify_cycled_authority()` simple, readable and reliable.
+
+## "Lock"-operation
+"Lock"-operation is the last *account_update_operation* that led the account to a locked state. No more operations possible on behalf of this account.
+
+## Unlocking account
+To unlock account we have to find previous *account_create_operation* (or *account_update_operation*) that changed owner or active authority. This operation will be reapplied to undo "lock"-operation if possible. See Discussion.
+
+## Fix locked accounts
+At the beginning find all locked accounts in first maintenance after hard-fork. Maybe locked accounts should be marked for unlock. Then fix them. There are two approaches here.
+
+First - automatic (unconditional)
+
+    - Find latest operation ("lock"-operation) among operations of cycled accounts. Do it for each cycle.
+    - Undo all "lock"-operations. Find previous account update/create operation that changes authorities and redo it.
+
+Second - manual (on-demand). Unlocking can be performed only by the account that performed the operation that led to the blocking, using the credentials immediately prior to blocking. That is, not all the keys from the history of this account fit. Thus, you can unlock an account that has been blocked only by mistake and only if the necessary credentials are available. Here we will avoid illegal behavior.
+
+    - New type of operation defined: unlock_account_operation { account_to_unlock : account_id_type }.
+    - Initiator (potentially *account_to_unlock*) signs the transaction using its previous authority preceding the locked state.
+    - Initiator (potentially *account_to_unlock*) pays fee for this operation.
+    - *account_to_unlock* should have sufficient balances to perform this operation.
+    - Check if *account_to_unlock* is locked in unlock_account_evaluator.
+    - Check if *account_to_unlock* is authorized to perform the operation (transaction signed with previous authority).
+    - Find previous account update/create operation that changes authorities - restore point.
+    - Undo "lock"-operation: extract owner and active authorities from restore point, update account with extracted data.
+    - Push corresponding virtual account_update_operation.
+
+# Specifications
+## Prevent circular dependencies
+```
+account_create_evaluator::do_evaluate( )
+{  ...
+   if( head_block_time() < HARDFORK_PREVENT_CYCLES_TIME )
+   {
+       graphene::chain::verify_cycled_authority( account );
+   }
+   ...
+}
+
+account_update_evaluator::do_evaluate( )
+{  ...
+   if( head_block_time() < HARDFORK_PREVENT_CYCLES_TIME )
+   {
+       graphene::chain::verify_cycled_authority( account );
+   }
+   ...
+}
+```
+```
+verify_cycled_authority( account_id )
+{
+   sign_state state( initial_parameters, verify_only=true );
+
+   GRAPHENE_ASSERT( state.check_authority(account_id), "Missing Authority" );
+}
+```
+```
+class sign_state
+{
+    sign_state( old_parameters, bool verify_only = false )
+
+    //
+    // New method added to parametrize class behaviour
+    // 'verify_only'-option helps to traverse down the hierarchy of accounts
+    //      emulating that all requested signatures are available
+    //
+    bool is_key_available(const public_key_type &key)
+    {
+        if (verify_only)
+        {
+           return true
+        }
+
+        auto pk = available_keys.find(key);
+        return (pk != available_keys.end());
+    }
+
+    //
+    // There is a small refactoring here: 
+    // allocate checking key/signature availability in a separate method
+    //
+    bool signed_by( const public_key_type& k )
+    {
+        auto itr = provided_signatures.find(k);
+        if( itr == provided_signatures.end() )
+        {
+    --      auto pk = available_keys.find(k);
+    --      if( pk  != available_keys.end() )
+
+    ++      if( is_key_available(k) )
+                return provided_signatures[k] = true;
+
+            return false;
+        }
+        return itr->second = true;
+    }
+
+    bool signed_by( const address& a )...
+
+    ...
+    bool verify_only
+}
+```
+
+# Discussion
+## Unable to unlock account
+Use case:
+
+    1) Account "Alice" delegates its authority to "Bob" - here: prior state
+    2) Account "Charlie" delegates its authority to "Alice"
+    3) Account "Alice" delegates its authority to "Charlie" (transaction was signed with Bob's private key) - here: locked state
+    4) Account "Bob" delegates its authority to "Charlie" - here: locked state
+
+To unlock "Alice" we need to reapply update operation at step 1. But "Bob" also locked, we have double lock here.
+
+# Summary for Shareholders
+We propose to develop a solution for BitShares users.
+This solution will help to avoid accidental account blocking by setting circular dependencies.
+There are similar precedents on the network, and unlocking accounts without hardfork is impossible. Thus, the account with all its balances may be blocked for a long period. Also, blocking of a lifetime member account incurs direct financial losses to the owner.
+Moreover, the solution will allow unlocking accounts that are blocked by mistake.
+The most important goal is to prevent irreversible blocking of accounts and help to regain access to the already blocked accounts and their balances.
+
+# Copyright
+This document is placed in the public domain.
+
+# See Also
+https://github.com/bitshares/bitshares-core/issues/269
+
+See *Cycles* paragraph of https://bitshares.org/technology/dynamic-account-permissions for details.
+
+More information can be found here: https://steemit.com/blockchain/@hipster/sad-story-how-i-lost-bitshares-account