From r.pickhardt at googlemail.com Fri Mar 15 15:29:10 2019 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Fri, 15 Mar 2019 16:29:10 +0100 Subject: [Lightning-dev] Potential Privacy issue with dual funded channels Message-ID: Hey everyone, during the spec meeting we have discussed intensively about dual funded channels and potential game theory with the fees however I now believe that we missed out another important crucial part which is the privacy of the node providing liquidity. While I have not seen a concrete example for a channel establishment protocol that supports dual funded channels I have seen this proposal ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html ) for advertising channel liquidity which assumed that the `open_channel` message would be modified as follows: `open_channel`: new feature flag (channel_flags): option_liquidity_buy [2nd least significant bit] push_msat: set to fee payment for requested liquidity [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding requested at channel open ... If a node cannot provide the liquidity requested in `open_channel`, it must return an error. With such a protocol I could now (basically only at the cost of internet traffic) probe a lower bound for the amount of BTC available by a node that allows for dual funded channels and abort the channel establishing process at some time before I ever spend / lock any of my own bitcoin. As I can even participate in the peer protocol without having a single channel open this situation seems to be even more severe. I don't have a clear suggestion how to mitigate against this. One general potential idea / solution would be to make spamming / probing more expensive. For example we could require the person to open a channel first and then ask the partner to splice something in (meaning we don't allow for one tx dual funded channels). In that case the node requesting liquidity had to do an onchain tx. also the requests to splice in can be identified and the person who feels to be probed can choose to fail the channel. I am not happy with my barrier as it would still be able to relatively cheaply abuse this and we run into a whole bunch of game theory about fees again. As the lightning network seems very keen to provide strong privacy to its users (c.f.: onion routing, keeping channel balances private, encrypted transport layer,...) I thought it is worthwhile pointing out the problem with the privacy for dual funded channels even though I don't have a concrete solution yet. best Rene -- https://www.rene-pickhardt.de Skype: rene.pickhardt mobile: +49 (0)176 5762 3618 -------------- next part -------------- An HTML attachment was scrubbed... URL: