LSAT and liquidity management (noob question)

[t-bast]

This is a very high-level question to understand how the end-to-end flow fits with lightning (not really, the real reason is that I wanted to hijack issue number 1 😈 - EDIT: damn I only got number 5, even though I can't see any closed issue).

Let's imagine that an API proposes metered access via LSAT. Users that want access to that API will either need a direct channel or a route where none of the intermediate hops require a base fee, right? Otherwise the cost of the routing fees would very likely exceed the cost of the LSAT.

If we take the option of having a direct channel to the API provider, that channel will likely be quite unidirectional (the user will be making payments, but not the other way around). Once it's depleted on the user's end, the user loses access to the API. That means users need to proactively manage liquidity to make sure they're always able to pay for their LSATs, right?

[bucko13]

For LSATs, depending on the specific implementation of the API at least, the validity of the token is not determined by the liquidity of the channel but only on the single payment that is associated (an association that is created atomically) with a single payment. You could have an open-ended LSAT made with a small payment that is good indefinitely, regardless of the state of the channel that created it. This is also what allows for eventual marketplaces where LSATs can be traded, bought, and sold. If LSAT validity depended on channel liquidity of the channel that made the purchase, then there would be no market for them since you'd have to take it on faith that the person transferring it to you would maintain their channels. With your example, you could create protocols that don't make the payment system too cumbersome where maintaining channel balance isn't all that important, either through different pricing schemes, service level tiers, expiration times, etc. Of course Looping In also helps solve the hypothetical you present too.

Using caveats on the macaroon you can add all sorts of other restrictions on the LSAT that are separate from the node but that still add limits to its use. The LSAT playground has a demo where there is an expiration time on the LSAT (good for about 40 seconds). Another example listed in these docs is different tier levels. Another would be dependent on a third party node validating the request (kind of like OAuth), as described here and here.

I think the idea of routing fees being greater than the cost of the LSAT itself is definitely something to consider but is also not necessarily inherent to the protocol since not all LSATs have to inherently be that small, just a single sat or similarly small micropayment. You could have a subscription service for example where you sell LSATs which provide 1 month of access to a newspaper site or other API, for a couple of dollars. In this case, the fees relative to the price should be pretty small and so could be made through more complex routes.

Anyway, all of that is just a long way of saying that there's a lot of flexibility that macaroons and the LSAT specific protocol afford you that there are ways to make the issue of disproportionate fees and channel liquidity much less of an issue.

Hope that helps!

[t-bast]

Thanks, my key take-away from your answer is mostly that LSAT will generally not be used with micro-payments to avoid running into this liquidity mess, is that correct?

[bucko13]

As it's an open-source protocol, that's entirely up to those that implement it! Depending on the use case it can be and it could make sense. In other cases where you don't expect much liquidity between participants, you might not use LSATs at all or use bigger payments that are expiration/time-based. In the Loop example described in the docs, it's not a concern even though you're making a micro-payment because that payment happens once to establish service level and then can be re-used for all future interactions with the Loop service.

Chainpoint is an example of an implementation that does use it for more frequent micro-payments, where the LSAT is used as a single-use token using a novel HODL invoice protocol not described in this repo. This works for this particular use case because there is an assumption of both a high likelihood of short routes and well-funded channels (with Loop support for when liquidity is needed) and so this is less of concern. You can learn more about how that works in this post under the section titled "Machine-to-Machine Payments in Chainpoint".