lisa neigut [ARCHIVE] on Nostr: đź“… Original date posted:2019-03-15 đź“ť Original message: Hello Rene, This is a ...
đź“… Original date posted:2019-03-15
đź“ť Original message:
Hello Rene,
This is a legitimate concern. Thank you for raising it.
I have three suggestions for how to mitigate this. The first is to return a
non-specific error message which, while in the aggregate might be used to
approximate a nodes’ uncommitted balance, would at least offer plausible
deniability to the exact cause for the failure.
The second proposal is in a similar vein. A node might add a privately held
randomization vector, which would return an error to any open channel
request with probability p. Thus an attacker wishing to ascertain a nodes
balance would not know with any certainty if the request they sent failed
because of a lack of available liquidity or for some other non-related
reason.
Finally, and perhaps most compellingly, rather than return an error, the
open channel should always succeed, but for any value at or below the
requested liquidity amount. The opening channel balance agreed upon between
the two nodes would then be adjusted to reflect the “correct” amount of
push_msat for the actual amount of funding_satoshi contributed by the
accepter (i.e. zero if the accepter node sends accept_channel2 with a
funding_satoshi balance of zero). If the amount of liquidity offered up by
the accepter is unacceptable to the opener, then they may choose to fail
the channel opening negotiation.
This third proposal, combined with a randomization vector (i.e with
probability p you always offer an amount less than the proposed amount)
would remove some of the certainty around a nodes unconfirmed balance. As
with channel balances, however, there is always the possibility of a
probabilistic attack i.e. lots of open channel requests sent over a short
period of time that would give an attacker a reasonable approximation of
your nodes available balance. A node could mitigate this by including an
exponential backoff for open channel requests from any one node,
essentially rate limiting the number of open channel requests that it will
accept from a single peer, or peers globally.
A node may also choose to set a policy around what it considers reasonable
liquidity requests from a peer (i.e. no more than 0.05 BTC from any peer),
which would further limit their exposure on the upper end of information
gathering.
Finally, as this liquidity feature is optional, any node who is truly
interested in preserving the privacy of their funds may continue to
establish channels the old fashioned way, i.e. via out of band negotiation
with other, trusted node operators.
Cheers,
Lisa
On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/29fea470/attachment-0001.html>;
đź“ť Original message:
Hello Rene,
This is a legitimate concern. Thank you for raising it.
I have three suggestions for how to mitigate this. The first is to return a
non-specific error message which, while in the aggregate might be used to
approximate a nodes’ uncommitted balance, would at least offer plausible
deniability to the exact cause for the failure.
The second proposal is in a similar vein. A node might add a privately held
randomization vector, which would return an error to any open channel
request with probability p. Thus an attacker wishing to ascertain a nodes
balance would not know with any certainty if the request they sent failed
because of a lack of available liquidity or for some other non-related
reason.
Finally, and perhaps most compellingly, rather than return an error, the
open channel should always succeed, but for any value at or below the
requested liquidity amount. The opening channel balance agreed upon between
the two nodes would then be adjusted to reflect the “correct” amount of
push_msat for the actual amount of funding_satoshi contributed by the
accepter (i.e. zero if the accepter node sends accept_channel2 with a
funding_satoshi balance of zero). If the amount of liquidity offered up by
the accepter is unacceptable to the opener, then they may choose to fail
the channel opening negotiation.
This third proposal, combined with a randomization vector (i.e with
probability p you always offer an amount less than the proposed amount)
would remove some of the certainty around a nodes unconfirmed balance. As
with channel balances, however, there is always the possibility of a
probabilistic attack i.e. lots of open channel requests sent over a short
period of time that would give an attacker a reasonable approximation of
your nodes available balance. A node could mitigate this by including an
exponential backoff for open channel requests from any one node,
essentially rate limiting the number of open channel requests that it will
accept from a single peer, or peers globally.
A node may also choose to set a policy around what it considers reasonable
liquidity requests from a peer (i.e. no more than 0.05 BTC from any peer),
which would further limit their exposure on the upper end of information
gathering.
Finally, as this liquidity feature is optional, any node who is truly
interested in preserving the privacy of their funds may continue to
establish channels the old fashioned way, i.e. via out of band negotiation
with other, trusted node operators.
Cheers,
Lisa
On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/29fea470/attachment-0001.html>;