Variable refund_delay chosen by the user

[eosauthority]

Some users need extra security on cold wallets, they would like to hold funds as staked for longer than the fixed 3 days. Example, stake for 7, 14 or 30 days. Even if the private keys are lost, unstaking should only happen within the specified time period.

This ticket is intended to gather ideas and get input on what the potential pitfalls are before we attempt to code it.

• We could let users specify how long they intend to wait for unstaking while they stake the tokens. If they don't specify anything, the default 3 days apply.
• This probably has to be a system contract update to enforce these rules.
• Can we try any other ideas to delay or defer transaction?

This video explains the idea https://www.youtube.com/watch?v=bfaFkYXxDAo

[arhag]

@eosauthority:

My opinion on the matter is to allow the user to force unstaked tokens to go to a specified account other than self to enable other contracts (like a bank contract) to provide whatever customizable security the user wants.

There should be a separation of concerns between the mandatory delays for unstaking required by the system contract due to concerns of abusing (multiple spending) network and CPU resources and any additional delays or restrictions that the users wishes to adopt for the purposes of security.

One of the challenges is going to be how to secure the action that changes which account unstaked tokens are redirected to. It wouldn't matter how secure the bank contract is if a simple undelayed action could change where the unstaked tokens were directed to so that they go directly to the thief. But it is also essential for the user to be able to change this so they aren't locked into any one contract to provide their security.

So perhaps there would just need to be a reasonable delay enforced (30 days?) for changing the target account. Alternatively, the action could have no delay and instead rely on the permission system to add delays. But then that requires using deferred transactions which have no guarantee of successful retirement. It would be very frustrating if the user created an input transaction delayed for 30 days and then after waiting 30 days it ended up expiring or failing, forcing them to create another delayed transaction and wait another 30 days. Turns out deferred transactions aren't as useful as we initially thought.