2022/07/06 11AM UTC - LSP Spec Meeting
Attendees: Christian Decker, Alex G, John Carvalho, Zero Fee Routing, Yaacov Slama, Reza Bandegi, Severin Buhler (lnrouter.app), Pavel Nikolov, Nick Slaney, Aljaz, Lucas Ferreira, John Cantrell Notes by Pav Nikolov
Video of call: https://drive.google.com/file/d/1yondbC7MLr7ciORNfMrfegAECtafbFyT/view
Notes: Reza provided update - opened pool request to the Group Repo https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/1/commits/86dd2da3eb15408405dde74dcd14d19727d6fcfd - converted blocktank API that covers use case what Blocktank do (channel requests) - open to suggestions and feedback.
No work done on the interception method (used by Greenlight for opening channels) - Blocktank will most likely support the method, although no work has been done yet.
Common types of API calls to be used regardless of how channels are opened - we can have feature flags on which types of channel opening it supports / fee structure etc - that can get into the "get service" end point.
Yaacov - Invited feedback for the changes on the spec (Breez) he pushed - it is in the same Github Repo? hasn't read API yet. Will try and understand it more fully and provide comments.
John - maybe easier to put things into categories so things are a bit more manageable. What would be covered under LSP etc. - open invite for both docs that Yaacov and Reza have published.
Reza - core features LSP would have get channel request will be there some LSP may not have channel request (or not be willing to sell channel on request or only interception or only swap / splicing servers) - what are the core features and what is optional.
ZFR - asking LSP about state of the channel. His work will be based on what Reza posted - good idea of how to structure the requests - ask the LSP how much to pay for the channel, how long is it going to keep it for etc.
CDecker - wondering if there is an alternative transport being the Lightning connection itself - once we create a channel there is a connection between the 2 end points - alternative transport for the protocol, which in the request one is just HTTPS - porting it back to the LN spec may be interest, provided there is appetite for it.
JCarvalho - Acinq mentioned something similar. Resulting sentiment was if you want that to be the end result, just make it.
Reza - Transport layer can support multiple (as its sending messages back and forth) and if we can define it, could be done in HTTP, up to the LSP to decide which connection they want to support. Can we use feature flags in Lightning and list those features
Decker - for CLN this is trivial - feature flags which are passed to the gossip, channel funding and you get access to the
Reza - web widget (API) if that info can be embedded into your LNode you don't need that end service info. HTTP support may be required as some of the services are front end (widget) - can be done via QR code which is static (can have parameters pre-negotiated in the QR code) - none of this exists.
CDecker - Greenlight - auto-negotiate in the background without having the user to go on a specific LSP front end and select parameters
LDK can enable similar functionality.
JCantrell: Breez current version they are not using short channel ID - Yaacov - we need to intercept because we have a payment hash. Breez generates new onion that is sent to the payee to charge the amount. If not, we can speak with the payee in order to let him know that Breez needs to decrypt the onion and encrypt it again with the new amount or let the payee do that.
Payee creates an invoice which needs to have a hint - who is deciding channel ID in the route hint - now is a dummy channel ID (breez knows what is the destination) created by the client.
Alias used by the 0-conf channel is generated once the channel is created, whatever is put there needs to be unique. You can differentiate based on the payment hash.
If you do want to agree on one - have the server generated until you are the client, it has to be unique for the server itself.
Once you see a short channel ID and look up payment hash and see if it matches previous agreed channel / peer and make future association for incoming payments (learn dynamically). Server generating the alias is consistent with the 0-conf interception
JCantrell: Fee rates between LSP and end user in terms of interception (channel request is more straightforward) Interception
Decker: If you dynamically adjust the fees depending on when the channel is open, you will no longer match the incoming payment. Related to additional invoice, and deactivation of channel until the LSP fee gets paid.
after an LSP has agreed a fee, but a certain time goes by, maybe the fee isn't acceptable anymore - abstract settlement of order and settlement of payment. perhaps add an expiry for LSP offer (LSP sets a time out) - this rate is good for the next X minutes or risk model - fee rate may change and LSP is ok to absorb (suggestion) or payment can fail
Client to renegotiate periodically when the negotiation is about to expire fees could also drop dramatically and LSP makes more money - depending on the fee model you may earn more than previously negotiated.
JCantrell: an attack, you fail payment and 0 conf channel is opened, LSP can be drained for on-chain fees.
Decker: only works if you have purely malicious attacker only, rational attacker you can prevent them getting utility from that channel - you open the channel, rejection of payment, LSP is stuck with a channel that you have to prevent payment.
LSP vs LSP - rational reason to drain their competitor? Good to be aware as a risk and how LSP can handle it.
Blocktank accept onchain btc - Blocktank support LNURL channels as well. Interception method - LSP collects payment and channel is opened Request method - customer is hoping that the LSP will open the channel
channels go wrong, LSP handle opening channel or providing refunds. when you request your channel status with the LSP - what is the status of the channel? Or if they want a refund, depending on policy - you can extend the API for them to close the channel and provide refund.
API allows the user if channel is not working or closed, they can request channel refund or reopening - reopening would require LSP to pay fees ...
We can automate refund but all liquidity that has moved towards you, you are being charged for.
Interception method - living the channel opened, no formal obligation or negotiation between the buyer. Blocktank once user requests a quote for a channel - we make a commitment for a channel to stay open for X period of time.
If we get Liquidity Ads working, we can work the same API and have LA to force the LSP to make it transparent for the user that we tried our best, we opened the channel, we won't get back our funds for 3 months and yet it closed, no refunds - leads to stale capital on chain.
Greenlight - undecided whether to have expiry channel commitments going through a simulated LQAds. If we can reduce human interaction to minimum, without exposing ourselves to constant refunds,
ZFR to add one more for his subset