BSIP65: Fix Locked Accounts #149

OpenLedgerApp · 2019-02-22T15:23:00Z

For #94.

merge latest changes to openledger bsips repository Dec 2018

ryanRfox

Overall, this BSIP draft is lacking. It does not meet the expectations defined in BSIP1 - BSIP Purpose and Guidelines. As a Community Member I am unable to understand from this proposal what the problem statement is and what the proposed solution(s) will do to remedy it. This needs much more definition in all sections.

README.md

bsip-0061.md

ryanRfox · 2019-02-22T16:34:18Z

bsip-0061.md

+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:


My understanding is:

Resolving the locked accounts is unconditional for the impacted accounts (no fees, no ability to opt-out).

The hardfork will revert the most recent account update operation by performing a new account update operation to set the the account authority to be in the previous (unlocked) state.

The hardfork will also contain logic that prevents locked accounts in the future (to a depth TBD).

I don't see a need for the Manual (on-demand) section. I am open to further discussion/explanation of its utility.

See details in updated version. You are welcome to discussion.

bsip-0061.md

ryanRfox · 2019-02-22T16:52:06Z

bsip-0061.md

+
+## 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.


Please demonstrate where this depth limit is defined in the code today. I assume something like GRAPHENE_MAX_AUTHORITY_DEPTH or something. Is this parameter allowed to be changed by the Committee at this time, or hard coded and would require a distinct BSIP to change?

The example is lacking clarity for me. We have to consider both Owner and Active authorities and how they may interact, at what depths. We need to provide and example of what we can unlock (and cannot, why) and what we can prevent from being locked (and cannot, why).

Please use valid formed account names such as "alice" "bob" "charlie" etc.

See comment above.

In answer to your question, @ryanRfox, that limit is found in the committee-controlled parameters here and is used when verifying transaction authorization here. It is defaulted to 2 in the static configuration here, although that default is irrelevant by now: the committee controls the value.

bsip-0061.md

pmconrad · 2019-03-02T09:52:59Z

bsip-0061.md

+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.
+


Please add a cost/benefit discussion.
How many such locked accounts exist today, how much are the locked balances worth, and what would it cost to implement this proposal?

cost/benefit discussion?

Could you please most specific what is required here - the cost/benefit? We have put the benefits previously. Finally, it does not matter how does it costs if it influences on the Bitshares major functionality and many users faced with this issue.

How many such locked accounts exist today, how much are the locked balances worth, and what would it cost to implement this proposal?

We decided to change the search algorithm according to the comments - #94

As a result, the number of locked accounts has decreased.

List of the locked balances - https://docs.google.com/document/d/1Dmcr9QzSWnCbSKcpaN08iENJyn6AWogbKjZ_iHH4OM0/edit

We have summarised the most liquid currencies of locked accounts.

Here the list:
BTS - 1,641,712.7494
USD - 14,546.7176
BTC - 6.86072047
CNY - 16,396.3406
ETH - 0.278826
LTC - 8.60401198
DASH - 0.23722333
ICOO - 348.1812
OBITS - 3,102.1454

Total locked budget is 144,619.841 bitUSD

As you can see the total budget is huge. We offer to unlock these accounts.

Thanks. That is indeed significant.

How about taking 10% from each account as payment for the implementation? (Seriously. The accounts are locked which means a 100% loss for the owner. We're offering to return 90%.)

How about taking 10% from each account as payment for the implementation? (Seriously. The accounts are locked which means a 100% loss for the owner. We're offering to return 90%.)

It makes sense.
@pmconrad could you please share your idea of how this can be implemented in a technical way?

At unlock time, walk through the account balances and auto-transfer 10% from each non-zero balance to a specific account, e. g. committee-account. That's pretty straightforward.

The non-technical side may be more tricky. :-/

pmconrad · 2019-04-03T10:08:31Z

bsip-0061.md

+    - Push corresponding virtual account_update_operation.
+
+# Specifications
+## Prevent circular dependencies


The specification is incomplete. It does not specify the unlocking process.

Also, please keep in mind that the target audience of a BSIP consists largely of non-programmers. Code as specification is insufficient. Pseudocode is welcome for data structures etc., but logic should be describe in a human-readable way. (Some of the "Rationale" can be included in the specification.)

OpenLedgerApp · 2019-04-29T11:59:33Z

We need to determine the way how to fix locked accounts.
There are two ways:

Automatic (unconditional)
- Detect all locked accounts in first maintenance after hardfork.
- Find latest operation ("lock"-operation) among operations of cycled accounts. Do it for each cycle.
- Undo all "lock"-operations. Find previous account update/create an operation that changes authorities and redo it.
Manual (on-demand)
- Check if account is locked.
- Find latest operation ("lock"-operation) in cycle.
- Undo "lock"-operation.

Let's decide it will be automatic or manual way.

OpenLedgerApp · 2019-05-04T11:11:06Z

Due to the fact that the algorithm for finding and unlocking accounts is quite complex and will require significant costs, we suggest considering another opportunity to unlock in the near HF:

add functionality - prevent creation cycled authority
compile a list of blocked accounts, find blocking operations and previous account states
perform undo blocking operations and return the account to the previous state (hardcoded operations list)

After HF, we check if there are still blocked accounts. They may appear after adding the unlock code, but before the HF. If there are any, then add them hardcoded to the next HF.

pmconrad · 2019-05-06T13:10:22Z

IMO the algorithm for finding locked accounts is exactly as simple as detecting the lock in the first place.
Since the detection logic will have to be implemented anyway, you can simply apply it to all account_update operations:

Before the hardfork, if you detect a lock, put the account and its previous authorities into a list.
At hardfork time you can simply take the list and restore account authorities to the saved state, which unlocks them.
*After the hardfork, if you detect a lock, fail the transaction.

OpenLedgerApp · 2019-05-11T15:09:58Z

The logic of finding a blocking operation is not as simple as determining whether an account has been blocked. In addition to the fact that the account is blocked, we must find the last operation in the chain of blocked accounts that led to this state. If you perform such calculations in bitshares-core in maintenance, then you should also take into account that the history plugin may be inactive and the nodes must come to consensus even without it. Without history plugin, this is problematic. You need to build a cache of recent authority change operations during replay, which will require a large amount of additional memory.

pmconrad · 2019-05-13T12:34:17Z

The logic of finding a blocking operation is not as simple as determining whether an account has been blocked.

Yes it is. An account that is blocked cannot be updated. So a blocking operation is an account_update after which the account has been blocked.

Note that it is not necessary to find the complete original account_update that caused the lock. It is sufficient to remember the owner authority as it was before the lock, and restore that.

abitmore · 2019-06-09T11:56:56Z

@ryanRfox please assign BSIP number.

sschiessl-bcp · 2019-12-13T08:33:55Z

Massive amount of hours went into this. What is the status @OpenLedgerApp ?

OpenLedgerApp and others added 4 commits December 18, 2018 16:37

Merge pull request #1 from bitshares/master

6ba1f10

merge latest changes to openledger bsips repository Dec 2018

Merge branch 'master-bs'

7c0363d

fix locked accounts

5655920

formatting changed

3c99c15

ryanRfox suggested changes Feb 22, 2019

View reviewed changes

ryanRfox changed the title ~~Bsip fix locked accounts~~ BSIP Draft: Fix Locked Accounts Feb 23, 2019

OpenLedgerApp added 6 commits February 28, 2019 14:38

update specification: add some terms, describe manual unlock approach

6cc3a57

update rational and specifications

44b4712

update abstract, motivation, summary and see also

0ef008e

update header, remove README modifications

a52f2d1

fixed spaces formatting

7579612

fixed lists formatting

9571127