Cezary Dziemian raised a question on lightning-dev regarding channel funding:

About weak ago I talked with Christian Decker, and he told me, that there is plan to implement possibility of both-side funding channels. He told me, that I will be able (for example) to pay 100 sat for peer if he agreed to put some of his funds to channel. Everything in single, trustless transaction.

Do I understand this correctly? And if so, do you have any predictions when it could be implemented?

According to ZmnSCPxj, there is a potential for leaking private information to unauthorised persons. For instance it could give the person requesting for funds an idea of your wallet balance. Say they request maybe 1 BTC, which you can pay, then they request 2 BTC which you are not able to pay. It becomes obvious that you have at least 1 BTC but you don’t have up to 2 BTC to give.

The initiator of the transaction can also launch hundreds of lightning nodes then “tie up” your onchain funds into channels and take your nodes offline. The “victim” will then have no choice but to wait for some time to access the funds.

This can be solved by requiring that the initiator in the two-sided channel pay a fee determined by the capacity requested from the initiatee, and the to_self_delay ¹ the initiator requests to the initiatee, via the push_msat² or similar mechanism.

This gives initiatees the power to set some fee rates for each dual-funding request they wish to accept “in terms of millisatoshi per satoshi-block”. This is then multiplied by the initiator to_self_delay and the capacity requested from the initiatee and divided by 1000 to get the fees the initiator has to pay the initiatee to carry out a dual-funding transaction.

To solve the privacy leakage problem, the initiator should be requested to put an equal amount if not more than he is requesting from the initiatee. He will then need to prove that he owns onchain UTXOs that are equal to or more than the capacity he will put in, and that the UTXOs are the only ones he can use to fund the channel.

The method is imperfect though, because someone with a lot of UTXOs can still look up how much someone with much less has onchain.

A better solution to the above weaknesses will be “Off-to-chain-swap” which involves creating a single channel to anywhere on the network and using an off-to-chain swap service to move the funds back to onchain. The process can be repeated as many times as you wish until sufficient incoming capacity is attained, although service fees are paid every time (to the swap service) and they can be slightly higher than the onchain fees.

This “Off-to-chain-swap” solution can be implemented immediately besides the fact that it allows back and forth transactions from many different points on the network until onchain funds get exhausted or you have enough incoming capacity.

You can also spend your off-chain bitcoin to buy onchain bitcoin, thus avoiding the headache of having to spend as much as the incoming capacity you want.

The “both-side funded channel” idea will have to be implemented in the protocol at least as an optional extension as it might be challenging to coordinate between the 4 or 5 existing implementations.

It could also create the risk of centralization if it is not supported by default on most nodes as only a few nodes will enable incoming requests from outgoing capacity.

Details of the proposal will be addressed in November lightning developer summit #2.

Resources

• Discussion
• Submarine Swaps