René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-15 📝 Original message: Hey everyone, during the ...
📅 Original date posted:2019-03-15
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/6ff1782a/attachment.html>;
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/6ff1782a/attachment.html>;