The Lightning Network -- The inward capacity problem -- An explanation & a question!

I was re-reading through this thread where a LN user reported being unable to receive his winnings after making a bet on a LN betting site, due to the lack of INWARD capacity.

This is a simplified and altered version of what happened:

• user, sargeantpepper opens a LN channel to lnbet with 1 BTC of OUTWARD capacity. I will call this channel, channel-Z.
• this means sargeantpepper can now spend 1 BTC with lnbet and potentially with many other LN nodes, by routing payments through channel-Z.
• at this moment, neither lnbet or anyone else on the LN can send sargeantpepper any funds, because:
  • channel-Z has zero inward capacity. IE the full 1 BTC is sitting on the sargeantpepper side of channel-Z. There is 0 BTC sat on the lnbet side of the channel.
  • there are no other channels open with sargeantpepper
• let us say that sargeantpepper spends 0.4 BTC on spins with lnbet and wins nothing on every bet.
• There is now 0.6 BTC sitting on the sargeantpepper side of channel-Z. There is 0.4 BTC sat on the lnbet side of the channel.
• let us say that sargeantpepper does 1 more bet. sargeantpepper bets 0.1 BTC and gets very lucky and wins 4 BTC. Yey!
• There is now 0.5 BTC sitting on the sargeantpepper side of channel-Z. There is 0.5 BTC sat on the lnbet side of the channel.
• But we have a problem: lnbet now owes sargeantpepper 4 BTC, but lnbet can only push up to 0.5 BTC to sargeantpepper.

The entire thread on r/bitcoin was pretty much people talking about all the possible ways this could be dealt with. These were the main options presented:

• sargeantpepper would use a swap provider to create ~4 BTC worth of INWARD capacity thus allowing lnbet to pay sargeantpepper via the LN (practical solution, but requires trust, adds complexity, takes time and results in a high-fee on-chain tx).
• sargeantpepper would use a submarine swap to create ~4 BTC worth of INWARD capacity thus allowing lnbet to pay sargeantpepper via the LN (not practical right now. This is a proposed future LN protocol improvement that would allow trustless swaps. It would result in a high-fee on-chain tx.)
• sargeantpepper should have kept their node online 24/7, so people would have opened new channels with sargeantpepper, thus (eventually) gaining ~4 BTC worth of INWARD capacity so that lnbet could have paid sargeantpepper via the LN (this would have been a cheap option for the sargeantpepper, but would have meant having a 24/7 LN node. Not practical for your average person.)
• Receive an onchain payment (simple and easy, but would result in a high-fee BTC fee and kinda defies the point of using the LN)

There was a 5th option which I didn't see mentioned:

• lnbet could have added funds to channel-Z via an on-chain top-up transaction. The characteristics of this would be:
  • A high-fee, on-chain tx would be required, however:
  • It would be guaranteed that lnbet could pay sargeantpepper. There would be almost no chance of routing failures because no other nodes would be involved.
  • Even though an on-chain tx was used, that money would now be sat in channel-Z and could later be cheaply spent on the LN.
  • From sargeantpepper's perspective this would be a very simple, fast and seemless solution. sargeantpepper wouldn't have to do anything. It would just work.

Is this 5th option possible with the LN or will it be possible?

Finally: this inward capacity problem is much bigger and more complicated than just the example scenario problem I gave further up. I recommend you read this to learn a bit more about it (if you're curious).

submitted by /u/hapticpilot
[link] [comments]

source https://www.reddit.com/r/btc/comments/9kk4l7/the_lightning_network_the_inward_capacity_problem/