Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tower payments pay endpoint: WIP #257

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

orbitalturtle
Copy link
Contributor

This PR begins to add payment support to TEOS. I'm realizing I have a lot of thoughts and the project is a bit bigger than I expected. So figured I'd try to see if I can get a little feedback on the approach I'm taking before I get too far along. 🤞🏻

Approach so far:

I've started by creating a new "pay" endpoint. This will be used to grab an invoice to pay when a user needs to register or top up their account (maybe a more accurate name would just be "get_invoice" to then pay after).

The steps for a user to make a payment (for initial registration or for a top up) are:

  • Hit "pay" endpoint to grab an invoice.
  • Pay the invoice.
  • Hit "register" endpoint, where the tower will validate that the user actually paid the invoice and the user will receive the receipt for registration.

On the tower side, once a user hits the pay endpoint for the first time, the tower associates the user's provided uuid with the invoice, and stores it in memory and in the db. IMO the advantages of "one-invoice-per-user" model are that:

  • The user won't waste resources if they hit the "pay" endpoint a million times. Instead of needing to generate a new invoice for every call (clutting the tower's lightning node db and making it harder to look through listinvoices to see if a payment is indeed paid), the tower will just return the invoice the user hadn't yet paid earlier.
  • A nice side effect I guess is the user won't have to provide any sort of proof of payment to the tower. The tower will just know if the user has paid their associated invoice or not.

Future stuff: This will come in future PRs

The above all takes the endpoint logic into account. After that, we'll need to build some other things:

  • Validator - As @sr-gi and I had talked about earlier, the validator is for now behind a trait so that any lightning implementation can eventually be used to generate invoices/verify payments. At some point we'll need to implement one option (perhaps starting with CLN?) to actually allow payments.
  • Once the pieces above are in place, we'll add config options, allowing the watchtower to turn on required payments & specify the payment amount they require for how many subscription slots, etc.
  • Add the ability to make these payments in watchtower-plugin. (And perhaps some integration tests to make sure everything is working together correctly?)

@aruokhai
Copy link

In the description laid out, an implicit assumption is made, which is that a user should have an existing channel with a route of payment to the said watch tower. Such assumptions might not be expected by all users, who may prefer to use normal bitcoin transfers. Such example would be in the case of private channels amongst known participants.
I implore the consideration of normal Bitcoin transfers and also the consideration of Silent Payments which help in the case re subscription without explicitly asking for an invoice from the said watchtower.

@orbitalturtle
Copy link
Contributor Author

I think using silent payments for payments is definitely a cool idea, though not totally relevant to this particular PR. Maybe it'd be worth posting a separate issue for the use of silent payments on rust-teos in case someone wants to look into it further?

Personally I think payments to watchtowers will likely be pretty small, even when paying for thousands of slots at a time up front (see: https://gist.github.com/orbitalturtle/38ca2c6a76dd129fd1cf84b4cc3cb101). So I'm not sure small payments like that will be the best for on-chain payments with higher fees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants