BSIP65: Fix Locked Accounts

bsip-0061.md

@@ -0,0 +1,169 @@
+    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).
+    - Undo "lock"-operation. See Discussion - Unlocking account.
+
+# 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
+    //
+    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());
+    }
+
+    ...
+    bool verify_only
+}
+```
+
+# Discussion
+## Unlocking account
+Operation that prior to locked state will be fully re-done. There is an option - only owner or active authorities can be restored.
+
+# Examples
+## Unlocking account using previous authority. Fully re-done operation
+There is following use case:
+
+    1) Account "Alice" was created
+    2) Account "Alice" was updated with new authorities and options (opts 1) - here: prior state
+    3) Account "Alice" was updated with new options (opts 2)
+    4) Account "Alice" was updated with new options (opts 3)
+    5) Account "Alice" was updated with new authorities - here: locked state
+
+To unlock "Alice" we need to reapply update operation at step 2. But latest account options (opts 3) at step 4 will be lost.
+
+## 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 offer to develop a solution for BitShares users.
+This solution allows unlocking accounts, which are locked by mistake.
+The most important goal is to return access to the wallets and unlock their money.
+
+# 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