BitShares Forum
Main => Technical Support => Topic started by: hadrian on July 01, 2015, 08:10:55 pm
-
edit: This is resolved - bytemaster says the "one transaction per period length" restriction was removed a while ago. The documentation is out of date.
Looking here (https://bitshares.org/technology/recurring-and-scheduled-payments/) on bitshares.org:
After a user grants the withdrawal permissions, the authorized account is allowed to make one transfer per period of an amount up to the limit.
Is there any reason for restricting it to one transfer? If there's no good reason, this is sub-optimal because it unnecessarily rules out certain use cases.
This is the list of properties for recurring payments on bitshares.org (https://bitshares.org/technology/recurring-and-scheduled-payments/):
A withdrawal permission includes following properties:
- Start Date
- End Date
- Withdrawal Limit per Period
- Period Length (i.e. 1 month)
If it's not a mammoth technical problem, it would be a significant improvement to add:
5. Maximum Number of Transactions per Period (from 1 to unlimited)
I'm assuming there must be a good reason for the restriction, and if this is the case, can someone tell me what it is?
I also assume that it's obvious why adding the "max. no. of transactions" variable would be better, but if this isn't the case I could elaborate with some examples...
-
If the number of transactions was set from 1 to X, then you could use it for microtransactions.
The user could fund their account, and then the merchant could take small bits when needed for microtransactions.
-
If the number of transactions was set from 1 to X, then you could use it for microtransactions.
The user could fund their account, and then the merchant could take small bits when needed for microtransactions.
Exactly - this is a good example. We're missing a great deal of functionality if this isn't implemented.
A shopper could have a debit card linked to a BitShares account. This "number of transactions" variable would allow someone to go shopping.
There are loads of other scenarios where this would be crucial...
Clarification is needed from someone to indicate whether or not BitShares 2.0 will be able to do this. And if not, why not?
-
What amount of flexibility is allowed in the "Period Length" ? If it could be set to 1 hour I don't see a major issue. What about 1 a day?
Granted, micropayment remittances are a great idea to help many people in underdeveloped locations like Africa, so we shouldn't unnecessarily restrict trade.
As BM is fond of pointing out, it's just a matter of making sure the costs are covered to support the infrastructure. Difficult to see how that would be calculated for micropayments, where you need to keep transaction fees extremely low.
-
What amount of flexibility is allowed in the "Period Length" ? If it could be set to 1 hour I don't see a major issue. What about 1 a day?
If there is only one transaction allowed per period then there is a problem balancing two trade-offs:- If the period is long, there is no flexibility to allow for (even slightly) irregular payments. You must know that for the whole span, one payment will be required, and no more.
- If the period is made shorter, this somewhat allows for unpredictably spaced payments. BUT there is a security risk as the payments can quickly stack up because of the short period.
In the debit card example in my post above, you may wish to buy something from a shop for $100 dollars, then 10 minutes later buy something elsewhere for $10. If the permissions allow $150 per hour and your card is stolen it could be very expensive ($3600 lost per day). If, however the permissions were set at $150 per day, you would, in this scenario, be unable to buy the second item (because you're restricted to one transaction per period).
THE FIX: If you could specify max. number of transactions per period you could set $150 per day with unlimited number of transactions. This would fix the problems and you could go shopping.
Another example:
Adam wants to allow his daughter Becky limited access to recurring payments from his BitShares account. Becky is moving out of the family home and Adam wishes her to have money available in case of emergency. If the period length is set as 1 month with $300 allowed, Becky could have two emergencies in a month and be unable to get access to money to cover the second emergency (even if she'd only taken $60 for the first emergency). If Adam sets the period length at 1 day the amount would have to be proportionately higher, say $100 (because $10 perhaps wouldn't cover an emergency). Then Becky could go out and spend $100 per day, costing Adam $3000 in a month.
THE FIX: Have the ability to set the period length at 1 month, the max. amount at $300, and the max. number of transactions at >1
-
The one per-period limit was removed long ago. Looks like we have some old documentation floating around. You can withdraw up to the limit per period.
-
The one per-period limit was removed long ago. Looks like we have some old documentation floating around. You can withdraw up to the limit per period.
So the "limit" parameter is a limit on the number of payments in a period and not the amount of payments? The docs are not very clear at all on this. Remittances are a very important feature so hopefully the docs will get updated soon. The docs that were rolled out on 6/8 might be "old" to the devs but as far as the world is concerned they're only a few weeks old.
-
You can withdraw X amount of asset Y every period Z
-
The one per-period limit was removed long ago. Looks like we have some old documentation floating around. You can withdraw up to the limit per period.
So the "limit" parameter is a limit on the number of payments in a period and not the amount of payments? The docs are not very clear at all on this. Remittances are a very important feature so hopefully the docs will get updated soon. The docs that were rolled out on 6/8 might be "old" to the devs but as far as the world is concerned they're only a few weeks old.
Yeah the protocol is still in flux we will need to update the website after the code is frozen.