Will this still be a problem in the future?

Hi there, on a post recently made by @dalz, got me thinking about something to somehow solve the fake account mass-creation attack that invaded previously STEEM and could also take action on HIVE one day.

(credit @dalz)

Note: Would be nice to know the % distribution of how many accounts do not broadcast for a large period of time.

Don't forget that there are multiple ways of "faking" humanized account creation (even if with a secondary method to prove human behaviour). Hence thinking about a way to protect against silent mass-creation of fake accounts, something that probably is worth thinking about in the long term.

Proposed feature (takeover)

To minimize the will of "attacking" the blockchain by automatically having a bot doing account creations of either selected/random names, a new feature (function) could be added to allow users to challenge an already created account based on its inactivity and staked amount.

New functions

I am almost sure this could not be implemented with custom JSONs but that's why the discussion here. Therefore for this to happen, we need new functions on the code (and HF required):

1. broadcast_takeover_challenge (active key) - "IssuingA" account will execute this function and send a HIVE quantity above 0 to @null with the "TargetB" account to initiate the takeover process. If the sent amount (form "IssuingA") is above the sum of the current staked amount of the target account ("TargetB") plus the higher amount sent to date (while the challenge is valid) from any given Issuing account, the transaction is accepted, otherwise not. If accepted, the timestamp "TS" of the highest (in HIVE) transaction is now considered for further broadcasts of challenges or to allow another function to execute (bellow). This means that further uses of higher (HIVE) values of this function can happen at any time, and that's the idea.
2. reply_takeover_challenge (active key, and new owner key for "TargetB") - after a "T" amount of time (to be programmed) elapses from the higher HIVE challenge broadcasted (and accepted), "TS", and if the user broadcasts this transaction (only requires RC to be executed), then 3 things can happen:
   2.1. If "T" time has elapsed (from "TS") without any transaction on the blockchain from "TargetB" account, then the owner key is swapped with the new one. Not sure what to do with the recovery account in this context for the "TargetB" account. If reset to empty or maintained to allow further recovery process.
   2.2. If "T" time has NOT yet elapsed, the broadcast is not accepted.
   2.3. If "TargetB" submits a transaction before any reply_takeover_challenge is accepted, the process is reset. "TS" set to empty. Further broadcast_takeover_challenge's need to be broadcasted to initiate the process.
3. cancel_takeover_challenge (active key) - an account ("IssuingA") can cancel his challenge broadcast (but will not recover any sent HIVE to @null).
   3.1. If the "IssuingA" account was the higher HIVE challenge (and only one), then the process is cancelled ("TS" considered or set to empty).
   3.2. If the "IssuingA" account was the higher HIVE challenge and the next higher value is from "IssuingB" account, then the process is cancelled only for "IssuingA" account ("TS" considered to be the one from the broadcast_takeover_challenge from the "IssuingB" account, if not yet cancelled too).

Benefits for the blockchain

Because the process involves burning HIVE on the challenges attempts, it de-incentivises attacks to very big accounts or active ones (protecting active users from the bad intentional attempts).

Allows a process to takeover unused/inactive accounts by burning HIVE equivalent to or higher than the HIVE staked at the target account. Liquid or HBD are not considered (hence in the case of a successful takeover, won).

Due to the above, the attack from bots on mass account creation is greatly de-incentivised when no activity is involved for "T" time.

This feature it's not just useful to de-incentivise attacks, but also as a method to "recover" account names in case the person that created it does not care anymore for the account. Sort of as a "recycle" method for accounts, allowing the HIVE blockchain to self-clean in time by users.

Possible solution "bugs/failures"

Since bots create accounts based on RC (mostly), they can also trigger automatic recovery processes. Hence the discussion if the recovery account should be reset to @null on this takeover process.

The existence of this process might cause "stress" on accounts that hold lots of liquid funds and don't broadcast so much, but on the other hand, will incentivise these accounts to either move those funds to "savings" or stake.

Another worry is the accounts that are not very often used because they serve as "recovery" accounts or other purposes that sometimes serve as trigger mechanisms to other accounts. I am thinking of a way to protect these situations. Please share any ideas.

What is your view on this?

And, hey, if this is a really bad idea... then at least I wanna know why.

Who can implement it, in case it's a great idea?

I am not going to put myself up in front, to implement this sorry. Basically I would not have the time. Even if I would be able to code it. Although I could help on reviewing it, yes (but I have the feeling I would be delaying with questions/queries more than helping in any case). Maybe that would be a start for me to get further close to the code and maybe do something in the future for HIVE. For now, its just a thought running in my mind.