Pending Earnings

Create a Lightning invoice for 0.00415010 tBTC or less to claim article's pending earnings.

Make sure the node requesting payment is the one you specified when creating the article.
Cancel
Please pay to the node whose key you set when you published?
Oops, this invoice is for too much: use a smaller value?
Payout Failed :( Try again?
This doesn't look like a normal invoice. Try a different one?

THOUGHTS ON LIGHTNING AND THE LIQUIDITY PROBLEM

I've been trying to wrap my head around the issue of liquidity in lightning channels. Currently, despite having enormous amounts of fun opening channels with the 1.3 tBTC I received from a faucet, I've noticed I'm not able to receive anything through any of these channels. As would obviously be the case, all of the channels are one-side and I am the only owner of any coins in the channels, until, of course, I spend them somewhere.

It may just be a problem that will be solved in some other way, but presents an interesting bootstrapping stage of LN. To begin with, the short term could lead to the dreaded "hub and spoke" architecture. And although I don't find this particularly disastrous (it doesn't present many opportunities for control or hinder privacy to any significant degree), it does present points of failure regarding keeping routes available to those holding them. If such a small number of nodes represent a significant portion of the channels, it may make the network availability more unpredictable than we want. If you open a channel with another node, it is best to have nodes that offer funds to the channel from their side as well. This quickly turns into an issue connecting significant funds. If someone offers the funds up to the network at connection requests (as a merchant might), they have to risk not being able to spend but only a portion of it due to user connections being constantly switching on and off.

Before there is an enormous incentive for smaller nodes to offer liquidity up to the lightning network, the network itself will perform more weakly. Essentially, we need large sums of people spending coins on a product or service on lightning, in order to make channels balanced in such a way to present a significant number of reliable routes.

It is however, easy to mitigate the issue in the reverse, if funds are on the opposing side you can merely open a new channel and leave the other to act as a possible route for others. By opening an additional channel, you can create the circumstances equal to having balanced channels, or could send a payment from the new one, to the lopsided one, effectively creating two balanced channels in place of two lopsided. Closing it is obviously an option, but a spent channel immediately turns into liquidity for the other node, making more channels the more optimal management.

This does come back to the problem with having too many connections however. It would mean that most users, to have a reliable experience, will essentially need more coins in their wallet than they are really interested in spending at any given time, as some nodes may not be online. With just the 5 nodes I have in my wallet, 3 are currently offline, making just over .3 BTC inaccessible until I make an on-chain transaction of some sort, or until the other peers come back online.

The good thing? The lightning network becomes more useable as time goes on, more channels are created, and more coins are spent. If there is ever an issue that requires a node to shutdown close their channels though, it may take time to rebuild the channels and get a robust and liquid connection to the network restored.

This makes Lightning excellent for spending and sending payments, but a hassle for receiving them. The receiver needs to be online, which is fine for merchants, but may be frustrating for many customers or users.


Article Payment

Y'alls Peer