Recurrent transfers feature

added Review label

added 16 commits

c9191ca2...f8409240 - 8 commits from branch master
423484b2 - wip
840fff46 - working recurrent_transfer mvp op
dda21013 - recurrent transfer object as a hive_object
c76a6f7f - moved the recurrent_transfer_object away from the account object
aa8d8c08 - compiling with per block conversion + account history vop
9b4965a6 - nal working mvp
8732cf98 - Added hf25 asserts and self review fixes
48ec785a - set minimum recurrence to 24 hours

Compare with previous version

marked as a Work In Progress from 423484b2

General note to missing functionality:

account related APIs response shall be optionally filled with set of recurring transfers defined for it, or new dedicated API shallbe added like list_recurring_transfers etc.
cli_wallet shall be extended also by functions to list, remove recuring transfers
how we can prevent scam in case when someone is selling account with scheduled tranfser(s) clearing the account balance... As far as we know, EOS plans to remove similar feature just because of reason pointed above...

There is no new unit test created to cover all execution paths, including negative cases when limits are exceeded.

added To Do label and removed Review label

basic_tests/chain_object_size shall be also extended by new data structures to control changes of their size in the future.

@ABW @bwrona Another consideration is what do we do with RC ?

We don't want an user to be able to create recurrent transfers and then let those take chain resources when the originating user ran out of rc. Few paths were discussed:

pay all the rc costs upfront and add an "end_date" to the recurrent transfers
let it be as is with a high cost to make the recurrent payment op but not end date
Figure a way to charge rc as we go
disable the recurrent transfer if the user has failed to fill payment more than x times

I think the end_date is preferable. Even from the user point of view. Of course recipients would prefer if people that lost interest in their work and/or Hive altogether and forgot to cancel recurring tranfers were drained from all their funds :o)

I've never used Patreon-type services, but I'd assume there is time limit where you have to refresh the setting. If not directly in the service, then it would be related to card expiration date.

Anyway, from sender point of view it is safer to have end date. Also as chain safety consideration that solution is preferred. It is easier to estimate cost of something finite than something that can stay in chain state forever.

As for RC cost, since it is not consensus it is mostly guesswork (I'm not even "in depth" familiar with RC mechanisms). I'd make it on pair with escrow transfers or even more costly, but that will depend on whether we will have end date or not. Without end date such transfers can stay active forever (like escrows) but on top of RAM they also require handling, which calls for more cost, with end date (let's say max one year) we can make the cost a lot lower, something between cost of regular transfer and escrow.

We should for sure have an end date. The big question I have is whether it's possible to charge rc as we go or not. I think this method is preferable if it's possible, from a usability standpoint. But if it's too much trouble, we can charge for it all upfront (but this limits the usage to users with sufficient RC to pay in one go).

unmarked as a Work In Progress

added 2 commits

25a0f0cf - consecutinve failed transfers result in deletion of the recurrent transfer
d8e1d547 - Some review fixes, added end_date and suppression of a recurrent payment if...

Compare with previous version