Both-side funded channels
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 1 the initiator requests to the initiatee, via the
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.
to_self_delayis the number of blocks that the other node’s to-self outputs must be delayed, using
OP_CHECKSEQUENCEVERIFYdelays; this is how long it will have to wait in case of breakdown before redeeming its own funds. see BOLT-02
push_msatis an amount of initial funds that the sender is unconditionally giving to the receiver. see BOLT-02
Support us and the authors of this article by donating to the following address:3KaMycU6Y7MdeXDMcH9yBVnCHC7ZJ8yu1Q
Comments powered by Talkyard.