LSPS1: Pricing Info

[SeverinAlexB]

As discussed in todays spec meeting and previously in the Telegram group, it would be nice to retrieve pricing information within LSPS1 without creating an actual order.

The goal is to provide pricing information for

• Lightning Explorers like sparkseer for example
• Node UI to purchase a channel from a peer.

This is not so easy though because there is a tension between having a fixed price formula for Explorers/UI and the flexibility required to make custom prices.

This issue should serve as a discussion ground to get a more clear idea of what we want.

[2Fast2BCn]

The only solution I can think of is to allow node spoofing when requesting a price. But I'm totally not a fan! I would rather have a separate LSPS where you can provide some free (markdown?) text to provide meta-data about your offerings of various LSPS's together with stuff like icon, documentation url, DNS verification, ... for discoverability.

[ErikDeSmedt]

For node explorers, I agree with @2Fast2BCn that a seprate LSPS is desirable.

To enable a good user experience we LSPS1 should a client should be able to ask for prices. I want that users can use a slider to set the channel capacity and see the price immediately.

Clients could do this by spamming lsps1.create_order requests. This approach puts an unreasonable load on the LSP-server which must

• create a lightning invoice and onchain address for each order
• store the uuid of the order
• watch the onchain address for a lot of spurious orders

It is reasonable for LSP-servers to limit the amount of open orders a client can have.

I think a simple lsps1.request_quote could do the trick here. Clients should request prices using lsps1.request_quote. Only once they are reasonably confident they will actually execute the order a client should call lsps1.create_order. The LSP can limit the amount of open orders for a client.

I prefer this approach over the promise-approach that was suggested in the Telegram-group. Imho it is simpler and it provides LSP's insight in the amount of open orders. E.g: LSP's can easily set a policy to only accept new orders if the LSP has sufficient liquidity.

[2Fast2BCn]

I however would like to get rid of the implied 24 hour validity of an order. If we have separate pricing for on-chain, LN, fedi tokens, ... then those might also have different quote validity periods?

[ErikDeSmedt]

I'm a bit confused by the implied 24 hour validity period. Could you link to what part of the spec you are referring to?

I thought the server can freely choose to set the expires_at flag in the response of lsps1.create_order

[2Fast2BCn]

Oops sorry, my mistake: lsps1.get_info more than once per day. Yes, you can currently chose the expires_at. But maybe the question remains? Should we only have 1 expires_at if you support multiple payment methods with different pricing? If you really want a short expiration for LN then that might not work if you also support on-chain. I'm only bringing this up because we are about to introduce braking changes anyway.

[ErikDeSmedt]

@2Fast2BCn : What is the reason for splitting the expires_at?

In the current version the LSP-server returns both payment options for any order.

E.g: The validity of the order is

• 5 minutes for lightning payments
• 24 hours for onchain payments

Even if the client has no intention to pay over lightning. The server must store the order for at least 24 hours.

Do you get the benefits you expect in the described scenario above? Should the client signal what payment-options it intends to use?

[2Fast2BCn]

My thinking was: If the fee of one of your payment options is time sensitive (due to high volatility in one of your pricing factors) then you want a short payment window. (because 1 hour later the price might be different) If the pricing for other payment option is not time sensitive then you don't mind a longer validity timeframe.

Since we talked about other future payment options like fedi tokens I was trying to make it more flexible and future proof but maybe I'm just overthinking this?

[SeverinAlexB]

I would like to suggest a mix between Eriks lsps1.request_quote and the LSPS2 promises:

lsps1.get_pricing

Request body

{}

Response body

{
   "bolt11_prices": [
      {
         "min_initial_client_balance_sat":"20000",
         "max_initial_client_balance_sat":"2000000",
         "min_initial_lsp_balance_sat":"0",
         "max_initial_lsp_balance_sat":"2000000",
         "base_price_sat":"1000",
         "client_balance_ppm":10,
         "lsp_balance_ppm":54
      },
      {
         "min_initial_client_balance_sat":"2000000",
         "max_initial_client_balance_sat":"10000000",
         "min_initial_lsp_balance_sat":"0",
         "max_initial_lsp_balance_sat":"2000000",
         "base_price_sat":"1000",
         "client_balance_ppm":10,
         "lsp_balance_ppm":40
      }
   ],
  "onchain_prices": [...]
}

This method returns price buckets similar to LSPS2 promises so LSPs can give discounts for more liquidity. It is NOT a promise though. It's best effort. If the LSP changes them you will know when you create the order.

LSPs can still personalize the pricing. They can decrease the ppm/base_price values in case they want to give a discount to a specific node.

In practice, I strongly assume discounts will be given to either larger nodes or to nodes that already have a good partnership with the LSP. So explorers showing general prices for newcomers should be fine.

What do you think?