Good morning Cezary,

An issue is that this potentially leaks private information.  If I request you 
to fund 1BTC and you accept, then I close the channel, then I request you to 
fund 2BTC and you decline, then I have a good guess, that your funds are 
between 1 BTC to 2 BTC.

There are ways to mitigate this but are not perfect.

In addition, it is important always, that the initiator of the action should be 
the one to pay for fees onchain, for both the opening transaction and the 
unilateral close transactions.

An obvious attack vector is to launch several hundred Lightning nodes, tie up 
your onchain funds into channels, then permanently take my hundred nodes 
offline.  The victim would then have to wait for some time (the `to_self_delay` 
parameter that I specified) to access  the funds.

The above attack is greatly mitigated by requiring that the initiator of the 
dual-sided channel pay a fee, based on the capacity requested from the 
initiatee, and the `to_self_delay` the initiator requests, to the initiatee, 
via the `push_msat` or similar mechanism.  So, the first state of the new 
channel would not equal what each participant puts in, but is skewed to the 
initiatee, in order to reduce the above tie-up attack.  Any node that wishes to 
*accept* dual-funding requests (i.e. potential initiatees) would have to set 
some feerate in terms of millisatoshi per satoshi-block, which is multiplied 
with the initiator `to_self_delay` and the capacity requested from the 
initiatee, then divided by 1000 to get the fee required for the initiator to 
pay the initiatee to perform dual-funding (and the initiator will also still be 
the one paying for all the onchain fees on top of that).

The privacy leakage can be mitigated by requiring that the initiator always put 
up greater than or equal capacity it requests from the initiatee.  The 
initiator would be required to provide proof that it owns some onchain UTXOs 
that in total equal or exceed the capacity it will put in, and those UTXOs are 
the only ones that can be used by the initiator, to fund the channel (even in 
single-funding the opening side has to provide the transaction that will fund 
the channel, and the UTXOs it owns can be found by looking up the funding 
transaction on the blockchain, so this is not a worse privacy loss for the 
initiator).  This mitigation is imperfect as a rich entity could still probe a 
much-less-rich entity for how much it owns onchain (and so, I am uncertain how 
valuable this mitigation will be in practice; in addition some might not 
particularly care if their financial information is thus exposed, preferring to 
earn from routing fees and dual-funding fees).

So, roughly speaking, I think the implementation will be that the channel will 
have a starting state that will put a little more money into the initiatee 
side, and the initiator always has to put up some amount of funds (and more 
likely will be required to put up greater than or equal to what it requests 
from the initiatee).

The details might be hashed out in November lightning-dev summit, and then 
implementation will take perhaps a year or more after that.

--

For myself, I think dual-funded channel, is not so important.

Consider that the initiator may need to put up funds at least equal to the 
capacity it requests to the other side, in order to mitigate the privacy 
leakage above, and pay fees anyway, in order to get incoming capacity.  Now 
consider instead an alternate solution: off-to-onchain swap.  Create a single 
channel to anywhere on the network, then use an off-to-onchain swap service 
(which will charge fees for the service that are slightly more than onchain 
fees involved) to move the funds on that channel back onchain.  You can then 
repeat this process with "the same" funds to get more incoming capacity, paying 
fees each time.

This alternate solution, has the advantage that (1) it can in theory be 
implemented today, although I am unaware of any good trustless off-to-onchain 
swap services today, and (2) you can keep repeating it with "the same" onchain 
funds, getting incoming capacity from multiple points on the network, until the 
service runs out of onchain funds to swap with you or you believe you have 
enough incoming capacity.

In short: the common complaint, that you can only easily get incoming capacity 
equal to what you spend, can be taken advantage of, by spending your (offchain) 
Bitcoin to buy (onchain) Bitcoin.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 10 September 2018 20:30, Cezary Dziemian <cezary.dziem...@gmail.com> 
wrote:

> Hi,
>
> 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?
>
> Cezary
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to