Follow up updates to the `Lightning service providers` page

[Bosch-0]

Moved from the now closed PR https://github.com/BitcoinDesign/Guide/pull/568. Will be making some follow up changes based on the below discussion.

@sbddesign

Notes from a discussion I had this morning about the LSP page. This is based on my notes -- attribute any errors in this to my own recollection or note-taking skills.

• LSPs - viewing them more specifically
  • An ISP connects you to the internet -- they provide a connection for you to send/receive packets over the internet.
    • Perhaps they offer other perks -- backup, email service, etc. But these services are not ISP services.
    • A company that provides email service doesn't become an ISP just because some ISPs offer email.
  • An LSP connects you to the Lightning Network -- they provide liquidity and channel opens so you can send and receive sats over LN.
    • Perhaps they offer other perks -- watchtowers, submarine swaps (for purposes other than channel opens), backups for your channel state, etc. But these services are not LSP services.
    • A company that provides cloud storage for backup or a watchtower doesn't become an LSP just because some LSPs also offer these services.
  • Lightning Wallet Server - an in-progress term to describe these other things.
  • A Lightning wallet uses a Lightning Wallet Server for thins like backup, maybe pathfinding, etc.
  • A Lightning wallet uses an LSP for liquidity.
• Other misc things
  • The subheadings under "Channel Opens" can be misleading
    • "Swap-In" can be used for more than just channel opens. You may want to replenish a channel or send yourself bitcoin to a channel. So it's not entirely accurate to characterize "swap-in" as solely a channel open service.
    • "Zero reserve" makes it look like this is a type of channel open technique, the way each technique has it's own subheading under "channel opens". My fix -- maybe we make this "What about channel reserve?" or something like this. Make it clear with the heading it's commentary on using zero channel reserve nad not a channel open technique.
  • Watchtowers -- not that this should go in the Guide yet, but we had an interesting chat about watchtowers
    • Google/Apple - how far from getting an exception for bitcoin and lightning protocol stuff in the same way that VoIP can? Phone should be able to do lightning stuff while locked
    • Watchtower - if phone can get around the fact that the app needs to be open in order to sync blocks or check the network, that opens the door for the user to have a watchtower running on their mobile device
      • Only a problem if user turns off mobile phone for 2 weeks -- not a problem in my country

My reply to this feedback

All very valuable feedback, thanks for this Stephen! I’m going to make a bunch of changes after this! Thank Roy for me!

“An LSP connects you to the Lightning network — they provide liquidity and channel opens so you can send and receive sats over LN.”

Really like this definition, I was going with the slightly broader one for an LSP, paraphrased from how an ISP is defined, hence why I’ve done things a little differently.

“An lightning service provider (LSP) provides services for accessing, using, or participating in the lightning network.”

Channel opens tick all three of these boxes, maybe an LSP specific service needs to meet this criteria. For example, a lightning address ticks participating and using, but not necessarily accessing, as it’s more of a quality of life service, this would be better as a lighting wallet server service as defined by Roy.

Watchtowers, backup & recovery, payment forwarding and swap-out services also seem more suitable to this lightning wallet server category. Agree that these could be defined separately.

Will clarify things on the subheadings.

"Swap-In" can be used for more than just channel opens.

Agree, will make this distinction.

Zero reserve" makes it look like this is a type of channel open technique

It's not a technique like say, a dual funded channel open is, but I would class this as a type of channel open. For an end user, defining these as types of channel opens makes more sense to me. Need to think about this one some more.

Watchtowers --

Some good points, lets hope Apple/Google get on to this asap.

[Bosch-0]

Relevant reading for this page: https://medium.com/breez-technology/get-ready-for-a-fresh-breez-multiple-apps-one-node-optimal-ux-519c4daf2536

Breez and Greenlight agree on the fundamental virtue of user sovereignty, and we ensure it together. But there is still a division of labor. For example, Greenlight provides some handy services for nodes on their servers, like encrypted backups and watchtowers. Breez powers Greenlight with its LSP backend, ensuring seamless connectivity to the network and automatically managing channels. By integrating Greenlight, Breez can continue to provide the same services we always have and more with a better UX. It’s a fundamentally different, superior architecture.

[Bosch-0]

Notes on the above article I made

I may be a little bias as I’ve been thinking about this with Zeus with its plans for a mobile run node later this year. We’ve discussed having multiple apps for different use cases similar to Breez so can see the value. But here is my thoughts, subject to change:

This is based on my belief that in the future, users will have more than one app that uses lightning. It could be the same app but different platforms (mobile + desktop). Or it could be different apps for the same, or even different, use cases (Breez for payments, BTCPay server for your store). I’m sure more use cases will become more apparent as the ecosystem expands. For either scenario, using locally run nodes with this multi-app paradigm requires a separate node to be run, and thus separate keys for each app. Running multiple nodes adds a lot of complexity, the two nodes could be out of sync across apps for example, and is an unnecessary use of resources. Managing multiple keys also makes key management more complicated. Adding friction between moving between apps also increases centralisation as users have a soft lock-in with app providers.

Backups on lightning are also a friction point for users, and I don’t have super strong thoughts around this atm with regards to Greenlight, but something you could do with this architecture is: say I lost access to my mobile app, I could use the desktop app (which has the same keys) and scan a QR code from my newly installed mobile app and recover it that way rather than re-enter my recovery phrase. This would be assuming that Greenlight is backing up the users channel states for them. With Greenlight, you can avoid these issues by using one set of keys and one (their) node across as many different apps as you want.

Here is example scenario – Say Zeus has a mobile payments app with a companion desktop app connected to a Greenlight node. Having these apps just acting as signers and not a node, they could both have a copy of the same keys, so I could fluidly switch between and use both versions of the app to make payments. This could be applied to two different apps also. Having two apps with hot keys present though would increase your attack surface, so there is trade-offs to consider.

I liken the user experience of Greenlight to external signers (hardware wallets). When using my Trezor, I’m not locked into using Trezor suite. Contrast this with a lightning wallet using a local node my keys are intrinsically tied to that wallets local node. Moving to a new wallet would require a new node and thus new keys. Greenlight enables much similar interoperability as on-chain keys / wallets. Their are some caveats to this analogy though as these two scenarios would have vastly different security models (keys are hot in lightning), something to keep in mind.

As mentioned above, I’m sure more uses for separating nodes and keys will become more apparent as the ecosystem expands. Especially as things like LSPs and lightning wallet servers (Roy’s term used in his article for non liquidity services like backups) become more common place.

[Bosch-0]

Relevant video to view - https://www.youtube.com/watch?v=jXjsxvuxByc