BSIP65: Fix Locked Accounts

[OpenLedgerApp]

For https://github.com/bitshares/bsips/issues/94.

[OpenLedgerApp]

We need to determine the way how to fix locked accounts. There are two ways: 1) 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.

  2) 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]

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: 1) add functionality - prevent creation cycled authority 2) compile a list of blocked accounts, find blocking operations and previous account states 3) 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]

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]

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]

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]

@ryanRfox please assign BSIP number.

[sschiessl-bcp]

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