From 5655920af5dbdb8c111696beb5145f6b57f5223a Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 22 Feb 2019 18:19:04 +0300 Subject: [PATCH 01/11] fix locked accounts --- README.md | 1 + bsip-0061.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) create mode 100644 bsip-0061.md diff --git a/README.md b/README.md index 43e0603..4eb0165 100644 --- a/README.md +++ b/README.md @@ -66,3 +66,4 @@ Number | Title | [58](bsip-0058.md) | Global Settlement Protection Through Price Feeding | Jerry Liu | Protocol | Draft [59](https://github.com/bitshares/bsips/issues/140) | Adjustment of MSSR and MCR Through Voting | Jerry Liu | Informational | Draft [60](https://github.com/bitshares/bsips/issues/131) | BitShares URI scheme | John Titor, Stefan Schießl, Abit More | Informational | Draft +[61](https://github.com/bitshares/bsips/pull/) | Fix locked accounts with circular dependencies | OpenLedgerApp | Protocol | Draft diff --git a/bsip-0061.md b/bsip-0061.md new file mode 100644 index 0000000..7e9bc14 --- /dev/null +++ b/bsip-0061.md @@ -0,0 +1,52 @@ + BSIP: 0061 + Title: Fix locked accounts with circular dependencies + Authors: OpenLedgerApp + Status: Draft + Type: Protocol + Created: 2019-22-02 + Updated: + Discussion: https://github.com/bitshares/bsips/issues/94 + Worker: + + +# Abstract +BitShares allow to change permissions of account A to account A. 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 + +# Motivation +We offer to develop additional functionality "Prevent to create cycled accounts". This functionality will avoid to create or update account authority with circular dependencies in the future. + +# Rationale +According to our investigation, BitShares has about 384 locked accounts with circular dependencies. Most of these accounts are locked by mistake. + +# Specifications + +## Prevent circular dependencies +We must extend create and update account evaluators adding code that detect cycled authorities and throws exception in do_evaluate() method if cycle detected. +To avoid any misunderstanding of existing authorization mechanism we propose to reuse actual code of sign_state::check_authority(). Make template class traverse_authorities_state and parametrize it with approve() method. By default approve = signed_by(), an existing method of sign_state class. We add keys_available() method to resolve signing path. So, check_authority() returns true, if signing path fully ends with existing keys. + +## Fix locked accounts +There are two approaches here: + 1) Automatic (unconditional) + - Detect all locked accounts in first maintenance after hard-fork. + - 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. + + 2) Manual (on-demand) + - Check if account is locked. + - Find latest operation ("lock"-operation) in cycle. + - Undo "lock"-operation. + +# Discussion +Should we identify authority as locked in case of cycle only? Bitshares has *max_authority_depth* parameter. So, authorities with delegetion depth > *max_authority_depth* are potentially locked. Should we prevent this? + +## Examples +Account A has key. Account B delegates it's authority to A - ok. C -> B - ok. D -> C - fail. +Transaction can never be signed by D. D exceed depth limit. Current depth limit in Bitshares = 2. + +# Summary for Shareholders + +# Copyright +This document is placed in the public domain. + +# See Also +https://github.com/bitshares/bitshares-core/issues/269 \ No newline at end of file From 3c99c15d84632008498cb612a2f53683bcf71903 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 22 Feb 2019 18:21:29 +0300 Subject: [PATCH 02/11] formatting changed --- bsip-0061.md | 1 + 1 file changed, 1 insertion(+) diff --git a/bsip-0061.md b/bsip-0061.md index 7e9bc14..5766504 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -26,6 +26,7 @@ To avoid any misunderstanding of existing authorization mechanism we propose to ## Fix locked accounts There are two approaches here: + 1) Automatic (unconditional) - Detect all locked accounts in first maintenance after hard-fork. - Find latest operation ("lock"-operation) among operations of cycled accounts. Do it for each cycle. From 6cc3a5766894ababf736eb33f133371e038e5f9c Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Thu, 28 Feb 2019 14:38:25 +0300 Subject: [PATCH 03/11] update specification: add some terms, describe manual unlock approach --- bsip-0061.md | 52 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 43 insertions(+), 9 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 5766504..4157799 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -24,25 +24,59 @@ According to our investigation, BitShares has about 384 locked accounts with cir We must extend create and update account evaluators adding code that detect cycled authorities and throws exception in do_evaluate() method if cycle detected. To avoid any misunderstanding of existing authorization mechanism we propose to reuse actual code of sign_state::check_authority(). Make template class traverse_authorities_state and parametrize it with approve() method. By default approve = signed_by(), an existing method of sign_state class. We add keys_available() method to resolve signing path. So, check_authority() returns true, if signing path fully ends with existing keys. +## "Lock"-operation +"Lock"-operation is the last *account_create_operation* (or *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 -There are two approaches here: +Firstly we need to 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: 1) Automatic (unconditional) - - Detect all locked accounts in first maintenance after hard-fork. - 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. - 2) Manual (on-demand) - - Check if account is locked. - - Find latest operation ("lock"-operation) in cycle. - - Undo "lock"-operation. + 2) 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. # 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. + +## Maximum authority depth Should we identify authority as locked in case of cycle only? Bitshares has *max_authority_depth* parameter. So, authorities with delegetion depth > *max_authority_depth* are potentially locked. Should we prevent this? -## Examples -Account A has key. Account B delegates it's authority to A - ok. C -> B - ok. D -> C - fail. -Transaction can never be signed by D. D exceed depth limit. Current depth limit in Bitshares = 2. +# 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. + +## Maximum authority depth exceeded +Account "Alice" has key authority. +Account "Bob" delegates its authority to "Alice". +Account "Charlie" delegates its authority to "Bob". +Account "Dan" delegates its authority to "Charlie". +So, we have locked account "Dan". Transactions on behalf of "Dan" will always failed due to maximum depth limit until depth limit changed by committee. Current maximum depth limit in Bitshares = 2. (to be expanded) # Summary for Shareholders From 44b471211cd4618e2bd39e8431f919ca0dc037b1 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 1 Mar 2019 17:50:05 +0300 Subject: [PATCH 04/11] update rational and specifications --- bsip-0061.md | 74 +++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 56 insertions(+), 18 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 4157799..7af91d7 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -16,22 +16,17 @@ BitShares allow to change permissions of account A to account A. See *Cycles* pa We offer to develop additional functionality "Prevent to create cycled accounts". This functionality will avoid to create or update account authority with circular dependencies in the future. # Rationale -According to our investigation, BitShares has about 384 locked accounts with circular dependencies. Most of these accounts are locked by mistake. - -# Specifications - ## Prevent circular dependencies -We must extend create and update account evaluators adding code that detect cycled authorities and throws exception in do_evaluate() method if cycle detected. -To avoid any misunderstanding of existing authorization mechanism we propose to reuse actual code of sign_state::check_authority(). Make template class traverse_authorities_state and parametrize it with approve() method. By default approve = signed_by(), an existing method of sign_state class. We add keys_available() method to resolve signing path. So, check_authority() returns true, if signing path fully ends with existing keys. +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_create_operation* (or *account_update_operation*) that led the account to a locked state. No more operations possible on behalf of this account. +"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 -Firstly we need to 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: +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: 1) Automatic (unconditional) - Find latest operation ("lock"-operation) among operations of cycled accounts. Do it for each cycle. @@ -46,13 +41,63 @@ Firstly we need to find all locked accounts in first maintenance after hard-fork - 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. -## Maximum authority depth -Should we identify authority as locked in case of cycle only? Bitshares has *max_authority_depth* parameter. So, authorities with delegetion depth > *max_authority_depth* are potentially locked. Should we prevent this? - # Examples ## Unlocking account using previous authority. Fully re-done operation There is following use case: @@ -71,13 +116,6 @@ Use case: 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. -## Maximum authority depth exceeded -Account "Alice" has key authority. -Account "Bob" delegates its authority to "Alice". -Account "Charlie" delegates its authority to "Bob". -Account "Dan" delegates its authority to "Charlie". -So, we have locked account "Dan". Transactions on behalf of "Dan" will always failed due to maximum depth limit until depth limit changed by committee. Current maximum depth limit in Bitshares = 2. (to be expanded) - # Summary for Shareholders # Copyright From 0ef008e6be9dad31ba3f8587a213b2a01066bbbd Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 1 Mar 2019 17:57:13 +0300 Subject: [PATCH 05/11] update abstract, motivation, summary and see also --- bsip-0061.md | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 7af91d7..32b9c04 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -10,11 +10,38 @@ # Abstract -BitShares allow to change permissions of account A to account A. 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 +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: + - to add additional functionality "avoid circular dependencies"to the nearest hard fork; + - 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 -We offer to develop additional functionality "Prevent to create cycled accounts". This functionality will avoid to create or update account authority with circular dependencies in the future. +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. @@ -117,9 +144,15 @@ Use case: 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 \ No newline at end of file +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 From a52f2d127c22b20373864427484e6a654c9a7349 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 1 Mar 2019 18:00:07 +0300 Subject: [PATCH 06/11] update header, remove README modifications --- README.md | 1 - bsip-0061.md | 8 ++++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 4eb0165..43e0603 100644 --- a/README.md +++ b/README.md @@ -66,4 +66,3 @@ Number | Title | [58](bsip-0058.md) | Global Settlement Protection Through Price Feeding | Jerry Liu | Protocol | Draft [59](https://github.com/bitshares/bsips/issues/140) | Adjustment of MSSR and MCR Through Voting | Jerry Liu | Informational | Draft [60](https://github.com/bitshares/bsips/issues/131) | BitShares URI scheme | John Titor, Stefan Schießl, Abit More | Informational | Draft -[61](https://github.com/bitshares/bsips/pull/) | Fix locked accounts with circular dependencies | OpenLedgerApp | Protocol | Draft diff --git a/bsip-0061.md b/bsip-0061.md index 32b9c04..36936d1 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -1,10 +1,10 @@ - BSIP: 0061 + BSIP: TBD Title: Fix locked accounts with circular dependencies Authors: OpenLedgerApp Status: Draft Type: Protocol - Created: 2019-22-02 - Updated: + Created: 2019-02-22 + Updated: 2019-03-01 Discussion: https://github.com/bitshares/bsips/issues/94 Worker: @@ -41,7 +41,7 @@ There are two important objectives this proposal aims to achieve: 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. From 7579612aac62fba7cf235ee68d8c38c13f16340f Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 1 Mar 2019 18:04:00 +0300 Subject: [PATCH 07/11] fixed spaces formatting --- bsip-0061.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 36936d1..4377ad2 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -1,5 +1,5 @@ BSIP: TBD - Title: Fix locked accounts with circular dependencies + Title: Fix locked accounts with circular dependencies Authors: OpenLedgerApp Status: Draft Type: Protocol @@ -26,7 +26,7 @@ The community has had extensive discussions about how to resolve this issue: 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. + - 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. @@ -36,11 +36,11 @@ Current BitShares implementation has no mechanism to unlock accounts and doesn't There are two important objectives this proposal aims to achieve: - to allow users to unlock their accounts; - - to prevent circular dependencies. + - to prevent circular dependencies. -This solution allows: +This solution allows: - to resolve user complaints; - - to increase confidence in BitShares. + - to increase confidence in BitShares. # Rationale ## Prevent circular dependencies @@ -101,7 +101,7 @@ verify_cycled_authority( account_id ) class sign_state { sign_state( old_parameters, bool verify_only = false ) - + // // New method added to parametrize class behaviour // @@ -146,7 +146,7 @@ To unlock "Alice" we need to reapply update operation at step 1. But "Bob" also # 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. +The most important goal is to return access to the wallets and unlock their money. # Copyright This document is placed in the public domain. From 9571127a4031a0d3b9cdb49e54b92152d78c2476 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 1 Mar 2019 18:19:28 +0300 Subject: [PATCH 08/11] fixed lists formatting --- bsip-0061.md | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 4377ad2..de55516 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -20,10 +20,12 @@ The active authority is meant to be a hot key and can perform any action except 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: - - to add additional functionality "avoid circular dependencies"to the nearest hard fork; - - to find all locked accounts with circular dependencies and undo the last account_update operation. + + 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. @@ -35,10 +37,12 @@ New operation unlock_account will be added, account_update_evaluator and account 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. @@ -53,20 +57,22 @@ To prevent circular dependencies account evaluators should contain verificaton c 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: +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. - 1) 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. - 2) 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. + - 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 @@ -128,19 +134,23 @@ Operation that prior to locked state will be fully re-done. There is an option - # 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 @@ -155,4 +165,5 @@ This document is placed in the public domain. 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 From b242bee16da18460f5fb2987322db331b4300fa4 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Mon, 25 Mar 2019 16:34:59 +0300 Subject: [PATCH 09/11] Update Summary for Shareholders --- bsip-0061.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index de55516..fc7e67b 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -154,9 +154,11 @@ Use case: 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. +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. From dce5b2eeed77d26cf2494c8ff3420fac1c921e2b Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Thu, 28 Mar 2019 18:27:05 +0300 Subject: [PATCH 10/11] sign_state extension: provide more information --- bsip-0061.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/bsip-0061.md b/bsip-0061.md index fc7e67b..1250c3a 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -110,6 +110,8 @@ class sign_state // // 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) { @@ -122,6 +124,28 @@ class sign_state 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 } From 5d807b11d45247a25218a6c929b6e822abc140b3 Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 29 Mar 2019 13:11:01 +0300 Subject: [PATCH 11/11] Update 'fix locked accounts on demand' --- bsip-0061.md | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/bsip-0061.md b/bsip-0061.md index 1250c3a..917aee9 100644 --- a/bsip-0061.md +++ b/bsip-0061.md @@ -72,7 +72,9 @@ Second - manual (on-demand). Unlocking can be performed only by the account that - *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. + - 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 @@ -152,21 +154,6 @@ class sign_state ``` # 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: