How to provide liquidity on the bitcoin lightning network for incoming payments
If you intend to spend 1 BTC from a lightning payment channel, you can just fund it with 1 BTC. The counter-party would have to fund his own outgoing channel with his counter-party, but that is another problem. That should allow you to spend up to 1 BTC on the lightning network.
Initially, you cannot receive any money in that channel, because all the money in the channel is yours to begin with.
Still, as you spend money from it, you can start receiving money in it. Imagine that you have spent 0.7 BTC from this channel. That should allow you to receive 0.7 BTC from other people all over the lightning network into that channel.
Hence, lightning payment channels from which you have spent money could actually be valuable because you can use them to receive money in. Therefore, you may want to avoid closing them. Still, this is not completely up to you, because your counter-party may also close the channel.
Now imagine that you now need a new channel were you can receive up to 10 BTC of incoming payments?
First thing, you fund a channel for 10 BTC, with the counterparty funding 0 BTC.
Unfortunately, all the money in the channel is simply yours. So, redistributing the money between yourself and your counter-party will never increase your own balance.
Therefore, you need to get rid of the money in the payment channel -- without losing it -- in order to make space for incoming payments.
How do you do that?
There may be more than one way to do that. The following way should work too.
You find a counter-party who wants your 10 lightning BTC in exchange for around 10 on-chain BTC. You carry out an atomic swap with him. So, now you have an empty channel, ready to receive 10 BTC.
Your counter-party however, now has a fuller payment channel. Is this a problem?
Yes, if he intends to receive money into that channel.
No, if he intends to spend money from that channel.
Therefore, net receivers and net spenders on the lightning network will need a marketplace to swap on-chain and lightning funds with each other. Otherwise, net receivers of lightning funds will increasingly have difficulty receiving funds.
There is, of course, a small problem with this strategy: you already need money to receive new money, and your very first incoming payment will have to be on-chain. Still, from a small, initial payment you can snowball your channels. With 1 BTC on-chain, you can create as many empty channels able to receive 1 BTC as you need. Just lather, rinse, and repeat the procedure described above.
Another minor issue is that a spending channel can be created with just one on-chain transaction, while a receiving channel will have to be created with two on-chain transactions.
At this point, we still urgently need to discuss the specifics of the actual smart contracts required to carry out atomic swaps between lightning and on-chain funds.
Like all atomic swaps, everything will obviously again revolve around pay-against-preimage-disclosure.
We can reasonably assume that the pre-funding of incoming payment channels will soon jump to the forefront once the lightning network really goes live. We must arrange a method to fund empty channels on the lightning network, that can receive money. Otherwise, the entire thing will begin to stall.
Therefore, we need a self-atomic marketplace for atomic swaps between lightning and on-chain funds.
If anybody is interested in joining in and work on the nitty-gritty details of the implementation of such self-atomic marketplace, feel free to let me know at [email protected].
If you just want to build it by yourself, also good, because that would spare me from having to work on it. It would allow me to just complain about this future problem without having to actually do something about it, and let someone else do the hard work instead of me! ;-)