breez lightning service providers

2021-12-12 ยท 4 min read

Source: https://medium.com/breez-technology/introducing-lightning-service-providers-fe9fb1665d5f

Requirements for mainstream #

  1. minimize onboarding friction
    1. friend asks "do you accept lightning?": 1st time inbound receive
      1. IDEAL USE CASE FOR LSPs IMO
    2. friend asks "can you pay me w/ lightning?": 1st time outbound send
      1. user onboards initial balance via fiat onramp
        1. I suppose user can just pay LSP directly huh!
      2. user already has BTC in some wallet/exchange (low probability)
  2. hide complexity from user
    1. users should not have to understand channels, channel management, HTLCs, etc...
    2. zero configuration
    3. only a single balance (should be no BTC vs LN balance distinction)
      1. See (https://blockonomi.com/submarine-swaps/)
    4. auto-rebalance channels in the background
      1. A user might have capacity spread across multiple channels (is there some way to just merge them all as more capacity is added?)
      2. Each channel might only have 20% of the total outbound capacity; we need to rebalance if the user wants to make a payment > 20% of their total capacity. (Or this is just an AMP?)
  3. predictable and low fee structure
    1. unfortunately, I think this is one downside w/ this approach.
    2. imagine user with low inbound liquidity recveives money from friend. the LSP needs on-chain TX to top up and will probably also add additional inbound capacity (to amortize) (right?). suddenly user gets "unexpected" cost, since they probably don't understand or can't see channel capacities and on-chain tx fees.

Problems #

  1. Wallet needs to be open and online in order to receive payments
  2. Recovering wallet on new device. Must ensure old Signal app/LN wallet stops running

define: LSP == Lightning Service Providers

Lightning is to LSP as Internet is to ISP

Network hub, centralizing liquidity is more efficient

See also: https://www.bitrefill.com/thor-lightning-network-channels/?hl=en and https://lnbig.com/#/open-channel

  1. LSPs front initial inbound liquidity to users
    1. currently Breez defaults to ~$50 initial inbound liquidity per user
  2. LSPs are the sole counterparty for wallet users. LSPs take on all of the complexity in managing the channel capacity, closing unused channels, fronting initial liquidity, accepting fiat to top-up channels, etc...
  3. LSPs handle ensuring connectivity and liquidity out to the rest of the LN, hiding this complexity from normal users.
  4. LSPs rebalance funds across their channels to ensure liquidity for users.
  5. LSPs can focus on reliability to ensure consistent uptime vs user-run wallets.
  6. Tbh "non-custodial" is a bit of a misdirection, since in this case the LSP controls the wallet code :p.
    1. Of course, this doesn't seem to be a problem for everyone using Venmo, Whatsapp, etc... but those also run on fiat rails, which can revert fraud.
    2. App cannot be compromised or all users' funds at risk
    3. LSP can be compromised (assuming no non-consensual send APIs exposed) without risking user funds (but can they? how are channel closes handled if we can't assume the users' LND clients are always live?).
    4. Why even bother running a whole ass LND on each user's phone and instead just do fully custodial lightning? (definitely bad optics)
    5. From SEC perspective, ideal setup has clear separation b/w LND wallet and Signal app. From UX perspective, prev. is untenable wrt. complexity. Wallet must be integrated.
  7. Most LSPs have 30 channel maintainence guarantee, may close if inactive longer.
  8. LSP needs initial fee to charge for (1) initial channel open tx, (2) capital cost, (3) channel close tx, (4) small profit. Breez was ~$1 vs $50 fronted, almost 2% fee.
  9. LSPs also can charge fee on (1) lightning txs, (2) fiat onboarding.