rust-teos
rust-teos copied to clipboard
talaia-labs
Paid subscriptions and topups
Currently the tower service is offered for free. However, the goal is integrate BOLT11 invoices in the response of the register message as a payment wall if subscriptions are being offered for a fee.
The current approach allows the user to hit the /register endpoint for free, adding DEFAULT_SLOTS to the current user's available_slots and reseting the subscription expiry to current_block_height + DEFAULT_SUBSCRIPTION_DURATION.
However, with the introduction of paid subscriptions storage over time has to be priced. The user should be able to add more slots to the current subscriptions (add slots), extend the subscription time period (add time) or do both at the same time (add slots + time).
Subscription top-ups should no leak information about the current state of the subscription to prevent probing. This may require splitting the top-up endpoint from the register one, and require a signature from the user in order to top-up. Furthermore, the behaviour over several requests to /register over an already registered id should be also defaulted (to add extra slots for example).
I think this is pretty hard, but I've added it so SoB just in case someone wants a challenging summer :P
DISCLAIMER
This is a Summer Of Bitcoin (SOB) project. If you're considering tackling this but you are not part of SOB, please leave it until SOB is over. After that, feel free to jump in.
Hi! So I'm Ready to take this challenge in the summer. I drafted the proposal too! Really it requires critical thinking.
@sr-gi Pricing strategy: Initially we can have some base fixed predefined Tiers and custom tier which will behave same when user topup (Pricing strategy has to research we can have a small survey I hope it will help) Predefined Tiers: The tower service can offer a set of predefined tiers with fixed prices for subscription time and some slots. For example: Tier 1: $5 for a 1-month subscription and 100 slots Tier 2: $10 for 3 months subscription and 250 slots Tier 3: $20 for 6 months subscription and 500 slots
Custom Pricing: To increase subscription time only: $0.01 per additional day
To increase appointment slots only: $0.005 per additional slot
This custom pricing can be used in top-up.
so now user have registertower <tower_id> <whichtier>
if user forget add 2nd argument which we know what it is...we can show all tier in CLI. with all details.
What are your views??
The idea of fixed tiers and custom ones is ok, but some research is due to know what may make sense.
In order for this to be profitable (and usable) we need to know what are the expected costs for hosting the expected amount of data during the expected time. Also, we need to check (if the is any available source) what is the average value transfer for a lightning payment over time.
If we pride things to low, the tower won't make any profit, it we price it to high, the user won't use the service, since it will be spending too much for the tower service proportionally to the value transferred.
On the other hand, there's DoS prevention. We don't want to allow the user to add slots (or time) one by one. This has two issues: first, it requires makes the tower have to deal with way more requests to update subscriptions, also, it makes the user not really commited. One of the reasons why the tower defines an initial time + slows way higher than one is to prevent sybil attacks.
All in all, yes, this may be a viable solution, but it really need to be backed up by research
@sr-gi I agree with your points. Conducting research to determine the expected costs for hosting the expected amount of data during the expected time is important in order to establish profitable pricing tiers. It's also important to take into account the average value transfer for a lightning payment over time, to ensure that the pricing is not too high for users.
Regarding the custom pricing for increasing subscription time and appointment slots, I agree that it's important to prevent sybil attacks and limit the number of requests to update subscriptions. Perhaps a minimum amount of time or slots that can be added at once can be set to prevent users from adding them one by one.
Overall, conducting research and setting reasonable pricing tiers is crucial for the success of the tower service. I'll do research and will add to my proposal thanks!!
One more thing just came to mind to add here: I think we have to improve our CLI too. if I am not wrong. user cannot see what method he can use for tower service which is mentioned here https://github.com/talaia-labs/rust-teos/tree/master/watchtower-plugin. like as help command.
One more thing just came to mind to add here: I think we have to improve our CLI too. if I am not wrong. user cannot see what method he can use for tower service which is mentioned here https://github.com/talaia-labs/rust-teos/tree/master/watchtower-plugin. like as help command.
Sorry but I don't understand what you mean. Can you clarify?
One more thing just came to mind to add here: I think we have to improve our CLI too. if I am not wrong. user cannot see what method he can use for tower service which is mentioned here https://github.com/talaia-labs/rust-teos/tree/master/watchtower-plugin. like as help command.
Sorry but I don't understand what you mean. Can you clarify?
sure! I just mean for the tower we have a help command...to get all services that the tower owner has like as gettowerinfo. but if we see client part if I'm not wrong there is nothing. like as help command ?
For the only client we have atm, which is the CLN plugin, the help command is provided by CLN, so we don't need one.
got that!! I was trying out figure how to inform users about pricing strategy through CLI. Ok this does not matter that much! I am trying to focus on other stuff related to the project. Thanks
Going to start working on this project this week :)
Will team up! Hope to complete this soon :)
I finally had a chance to write up some thoughts about some considerations re: watchtower fees if anyone has a chance to take a look :) https://gist.github.com/orbitalturtle/38ca2c6a76dd129fd1cf84b4cc3cb101 @mariocynicys @sr-gi