Omar Shibli [ARCHIVE] on Nostr: đź“… Original date posted:2019-03-15 đź“ť Original message: Hello Rene, Sorry for ...
đź“… Original date posted:2019-03-15
đź“ť Original message:
Hello Rene,
Sorry for hijacking this thread, but I would suggest another route to
tackle privacy and liquidity issues in general.
At the moment, it seems that there are no taking advantage of off-chain
settlement protocols, the idea is based on Schnorr signatures. The general
theme is build programable multi sig contracts based on aggregation of
signatures.
It's very powerful, and simple model, that will allow variety of
funding combinations.
The general diagram:
N inputs -> M outputs , N = a1s1 + a2s2 ... , M = b1s2 + b2s2
... (simplified incomplete formulas for clarity)
a1 - input amount , s1 - signature.. same to b1, b2....
The main advantage of this communication method that all transactions could
be done offline with trusted Oracle, optionally all data could be blinded
from oracle PoV for optimal privacy and maximal effect principle of least
authority through minimal visibility to third party participants.
Regards,
Omar
On Fri, Mar 15, 2019 at 6:29 PM lisa neigut <niftynei at gmail.com> wrote:
> 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
>>
> _______________________________________________
> 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/8761f6a8/attachment.html>;
đź“ť Original message:
Hello Rene,
Sorry for hijacking this thread, but I would suggest another route to
tackle privacy and liquidity issues in general.
At the moment, it seems that there are no taking advantage of off-chain
settlement protocols, the idea is based on Schnorr signatures. The general
theme is build programable multi sig contracts based on aggregation of
signatures.
It's very powerful, and simple model, that will allow variety of
funding combinations.
The general diagram:
N inputs -> M outputs , N = a1s1 + a2s2 ... , M = b1s2 + b2s2
... (simplified incomplete formulas for clarity)
a1 - input amount , s1 - signature.. same to b1, b2....
The main advantage of this communication method that all transactions could
be done offline with trusted Oracle, optionally all data could be blinded
from oracle PoV for optimal privacy and maximal effect principle of least
authority through minimal visibility to third party participants.
Regards,
Omar
On Fri, Mar 15, 2019 at 6:29 PM lisa neigut <niftynei at gmail.com> wrote:
> 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
>>
> _______________________________________________
> 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/8761f6a8/attachment.html>;