Initial draft of recurring monthly withdrawals #95
Conversation
bsip-recurringmonthly.md
Outdated
| Discussion: https://github.com/bitshares/bitshares-core/issues/1208 | ||
|
|
||
| # Abstract | ||
| Recurring withdrawals can currently be defined in BitShares core with respect to any periodic interval greater than the minimum block interval (currently 3 seconds). However those intervals are not intuitive for many use cases such as intervals defined in terms of Gregorian calendar months. This BitShares Improvement Proposal describes describes possible defintions for the periodic intervals and possible implementations such that they are compatible with the existing recurring withdrawal capability. The adoption of of this proposal might increase the goods and services that are accessible through BitShares by making it easier for merchants to accept payment on an intuitive montly basis. |
There was a problem hiding this comment.
"might increase" -> "will increase"
monthly is simply what the old economy uses
|
|
||
| The specified starting date-time will serve two purposes: (1) it will define the start of the recurring authorization, and (2) will implicitly define the starting day of the month **and** the starting time in UTC within that day. | ||
|
|
||
| If the starting day of the month is derived to be on either Day 29, 30, or 31 of a month, caution must be taken because not all months in a Gregorian calendar contain these days. One simple manner of addressing this is to prohibit the selection of these days as the start of a recurring month. Another manner is to interpret such a day as beginning on the day requested **if** that Gregorian month contains that day, and otherwise to specify the prior day in the month that is present during that calendar month (for example, a start day of 31 will become 30 when the month is April). |
There was a problem hiding this comment.
I find that most other monthly periods define "end of the month" to be the 28th, which I think is sufficient.
|
|
||
| ### Caution: Possibility of Fractional Last Period | ||
|
|
||
| As in the existing definition, it is possible for the last period to be a fraction of a periodic interval due to the open-ended definition of the expiration date-time. |
There was a problem hiding this comment.
My suggestion would be to neglect fractional last periods. Only the last fully included period counts (imagine taking out your full monthly salary because someone did not look at the hour of the day).
One could think of implementing a fractional withdrawal for fractional periods, but I believe that is unnecessary as its merely a question of proper UI.
There was a problem hiding this comment.
FYI the existing implementation of recurring withdrawals allows fractional last periods.
Limitations in UI are reasonable. Should we maybe also restrict the Core from allowing fractional?
bsip-recurringmonthly.md
Outdated
|
|
||
| - a starting date-time in UTC, | ||
| - a starting day of month defined as a number between 1-28, | ||
| - a starting hour of the day in UTC defined by a number between 1 and 23 (inclusive), |
There was a problem hiding this comment.
Why not 0 in the hour?
In general: For the user the UI needs to take care of properly setting it, for the backend I think that the day and hour can be derived from the starting date-time.
|
|
||
| # Discussion | ||
|
|
||
| A design question (in contrast to the existing definition) is whether an exact quantity of periods should be explicitly defined which will result in an implied expiration date. This is related to _"Specification of Intervals"_ and _"Specification of Period Start Date-Times"_. |
There was a problem hiding this comment.
If the last fractional period is neglected, this is merely a personal choice. As for usability, anyone using the CLI will be able to handle both, for the UI it is a question of proper UX.
There was a problem hiding this comment.
Depending on how strictly the Core handles fractional periods, this specification in the UI can make a difference. My impression from your comments is that Core should be made strict to prevent fractional periods.
bsip-recurringmonthly.md
Outdated
|
|
||
| # Summary for Stakeholders | ||
|
|
||
| The ability to define recurring withdrawals in commonly recognized intervals, such as "monthly", might increase the goods and services that are accessible through BitShares by making it easier for merchants to accept payment on an intuitive montly basis. The adoption of such a feature might also increase the usage of various BitAssets including bitCNY and bitUSD. |
|
It popped up in Telegram that including an auto-payment feature would be nice to have for withdrawal feature. Meaning: Automatically transfer the maximum amount for each period to the configured receiver. What do you think? |
|
This would require additional processing on-chain. I don't see a significant advantage for users - recipients have to check for incoming funds anyway. Can someone check how often withdrawals have been used yet? We should keep an eye on the cost/benefit ratio of these things. |
|
@pmconrad One review of the blockchain operations through June 2018 indicates
|
I agree with this. Since the software does not have an architecture to process "stuff" on a timed basis (except for maintenance interval), I would also prefer not to automate things too much. One of the design principles, originally, was to have actions explicitly executed. Hence, we could as well do similar to vesting balances in that balances accumulate according to some rule (e.g. unit-step function with monthly reset) and then let users explicitly claim. |
|
Is anybody still working on this? |
Draft of recurring monthly withdrawals in response request for BSIP