2022/07/20 11:00 UTC - LSP Spec Meeting
Video of call: https://drive.google.com/file/d/1F_wO_XzQcSKGTPhBGnbWRWeoSMtmNiHx/view?usp=sharing
Attendees:
Christian Decker, Alex G, John Carvalho, Zero Fee Routing, Yaacov Slama, Reza Bandegi, Severin Buhler, Pavel Nikolov, Nick Slaney ...Others?
Notes by Pav Nikolov:
LSP takes payments on behalf of users
Christian looked on Matt's proposal - trade off looks symmetric with what we have with the pre-payment. One side is trusted either way - if we do a post payment we trust the trustee of the channel
it may be possible to have a post payment to trust the user to some extend. According to CD, we can't make this atomic.
Sevi - have a 3rd party between user and LSP - release the secret as soon as the LSP releases the 0 conf channel and seize the transaction.
CD - We still have trust in the system. LSP is exposed to attacks hence it should be trusted party.
JC - JIT method means payment can come through and recipient may not know of that and LSP can keep it. LSP puts in a position of custody of a 3rd party payment -
CD - we will always have trust in the system.
NS - the payment secret is different from the pre-image - doesn't give you ability to unlock HTLCs
CD - payment secret is only necessary for the LSP to create the last hope for the incoming payment - not gives ability for LSP to pull funds. Essentially LSP aggregating "anonymous" HTLCs and creating smaller HTLCs going over 0 conf channel over new onion - definitely has downsides
you do-lose information that may be in the onion. It does not give the privilege to pull incoming payment for LSP.
LSP has to trust the recipient to accept payment, once channel is opened - disable that channel until another incoming payment has paid for that channel, so you can't use it otherwise.
Sevi - attack vector vulnerability - disabling channel isnt enough - competitor / State level attacker, LSP can open a lot of channels and LSP lose a lot of funds
CD - that issue will exist in any JIT interception. Is it valuable to try interception method which has implementation and technical challenges or embrace the issue of trust - make it explicit instead so the recipient post-pays for the channel we open.
Yaacov - what is the value of channel if not used to receive money. Need of a channel is to receive money, interception is the right time to have channel.
CD - we still open channel on demand, as we did before. Recipient approaches LSP - if you see this payment hash, opene a channel to me, intercept method, we reduce amount, in post-payment we forward entire amount, don't do anything until we are paid. We don't mix incoming payment with renumeration of LSP. Embracing this trade-off with interceptions, Only serves to hide the weakness.
ZFR - likes this solution. Not implement this JIT method if you don't want to risk spending a lot of on-chain funds. Same trade with LSP has with intercept and reduce amount way, but you save a lot of technical work
JC - JIT only works if you trust user
Yaacov - both options need to trust the user. 2 solutions - its not complicated to create onion and send to user, more natural to see new channel as a fee than post-payment. If payee accepts original amount, no need to create new onion.
CD - C-L enforce the amounts in the HTLCs, you cannot mark invoice paid from plugin.
Yaacov - if invoice with smaller value, Replace onion on recipient side. Technically this is easy to do. Channel creation as a fee, not payment. Payee needs to know they pay more fees for the first one (as a fee).
CD - interception gives LSP more control, but post-payment method will work as interception method. Either you have funds or not.
NS - we should have options, it would be good to have post-pay option too.
Yaacov - it is in production with Breeze and working on doing it with Greenlight.
ZFR: Both options are OK and LSP decides. Nick - how we do interception method, do we try Matt C's version.
Nick: 2 invoices (Breez) is implemented
RB - John Cantrell's pull request - unified channel request API, has normal channel request + JIT - is that a good starting point?
ZFR - likes it NS - likes it JC - use that as starting point .
MPP discussion? CD - is pretty trivial. If we allow this collecting of HTLCs up to the desired amount, there shouldn't be no issue. Not sure if its in the spec yet. It's OK to start with a single part payment.
NS - end-to-end onion being the solution to go
RB - interception method exploit that Sev mentioned, limit in API to how many channels LSP should open. Channel request API (unified) doesn't have that in there.
ZFR - we should add it. CD - its an HTP based protocol, return error 500 and you are ok.
Sevi - post payment is easy to attack, even if you have limit as Reza proposed or DDOS attack, continuosly open and fail 5 channels. Not sure how to mitigate the costs for the LSP
CD - assuming non-rational attacker. External payoff, well behaved users will not be able to get the service. If we assume competitor just attacking, we have mechanism to attack them too - HTLCs can be held and kill their channels.
put a disclaimer for JIT method, Breez is doing now, we should support it. CD - this is why I want to differentiate between rational and non-rational actor.
LSP in case of an attack can switch to a fall-back method. CD - only one that exists is pre-payment method, which is way less useful to people we are trying to on-board.
ZFR: the paying person to have 1 invoice - part of it goes to LSP and part to the recipient. Is there a way to standardize and merge 2 separate invoices to 1. Is that viable?
CD: comes down to how much info you want to give to the sender.
Nick - can we add a field to the invoice, to tell the sender in the Onion, make the instruction to the 2nd to last HTLCs to have x amount and last HTLC this amount.
CD: putting stuff in the invoice, you may end up generating a ton of invoices before getting paid.
get approval for the "alpha spec" - for the Pull request from John Cantrell https://github.com/BitcoinAndLightningLayerSpecs/lsp/blob/cf83ed9d2ca1b77748374ccf81c280f92dc652cb/channel-request.md
Next call - Action Steps please review prior next call, so we have 1st version that we are working on
Get the basics agreed on, and then start adding more features. API related to market places LSP vs WLS - clarity around that
Nick to throw some ideas in the chat.