đź“… 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>;
Omar Shibli [ARCHIVE] /
npub1pc…rcqst
2023-06-09 12:54:35
in reply to nevent1q…2jlp
Author Public Key
npub1pcahv5ukvgeh99knz2yrdd2sku460cqme8qu49xqz88hrtsfu0sskrcqstPublished at
2023-06-09 12:54:35Event JSON
{
"id": "8eef66175f4b4fbd6ac265e6f9eb9701251e5a4b5c480035a0910ab69baa3c44",
"pubkey": "0e3b76539662337296d3128836b550b72ba7e01bc9c1ca94c011cf71ae09e3e1",
"created_at": 1686315275,
"kind": 1,
"tags": [
[
"e",
"bf77d3a31d2700cc6805a6adbfa7d197d7e8abb608cfd401ecd34df6b1148b94",
"",
"root"
],
[
"e",
"ccfb34fe029bb4a0f974942a2d015d102c435e3327c8d9e663162afc740ca865",
"",
"reply"
],
[
"p",
"804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a"
]
],
"content": "📅 Original date posted:2019-03-15\n📝 Original message:\nHello Rene,\n\nSorry for hijacking this thread, but I would suggest another route to\ntackle privacy and liquidity issues in general.\n\nAt the moment, it seems that there are no taking advantage of off-chain\nsettlement protocols, the idea is based on Schnorr signatures. The general\ntheme is build programable multi sig contracts based on aggregation of\nsignatures.\n\nIt's very powerful, and simple model, that will allow variety of\nfunding combinations.\n\nThe general diagram:\n\nN inputs -\u003e M outputs , N = a1s1 + a2s2 ... , M = b1s2 + b2s2\n... (simplified incomplete formulas for clarity)\n\na1 - input amount , s1 - signature.. same to b1, b2....\n\nThe main advantage of this communication method that all transactions could\nbe done offline with trusted Oracle, optionally all data could be blinded\nfrom oracle PoV for optimal privacy and maximal effect principle of least\nauthority through minimal visibility to third party participants.\n\nRegards,\nOmar\n\n\n\n\n\n\n\n\n\nOn Fri, Mar 15, 2019 at 6:29 PM lisa neigut \u003cniftynei at gmail.com\u003e wrote:\n\n\u003e Hello Rene,\n\u003e\n\u003e This is a legitimate concern. Thank you for raising it.\n\u003e\n\u003e I have three suggestions for how to mitigate this. The first is to return\n\u003e a non-specific error message which, while in the aggregate might be used to\n\u003e approximate a nodes’ uncommitted balance, would at least offer plausible\n\u003e deniability to the exact cause for the failure.\n\u003e\n\u003e The second proposal is in a similar vein. A node might add a privately\n\u003e held randomization vector, which would return an error to any open channel\n\u003e request with probability p. Thus an attacker wishing to ascertain a nodes\n\u003e balance would not know with any certainty if the request they sent failed\n\u003e because of a lack of available liquidity or for some other non-related\n\u003e reason.\n\u003e\n\u003e Finally, and perhaps most compellingly, rather than return an error, the\n\u003e open channel should always succeed, but for any value at or below the\n\u003e requested liquidity amount. The opening channel balance agreed upon between\n\u003e the two nodes would then be adjusted to reflect the “correct” amount of\n\u003e push_msat for the actual amount of funding_satoshi contributed by the\n\u003e accepter (i.e. zero if the accepter node sends accept_channel2 with a\n\u003e funding_satoshi balance of zero). If the amount of liquidity offered up by\n\u003e the accepter is unacceptable to the opener, then they may choose to fail\n\u003e the channel opening negotiation.\n\u003e\n\u003e This third proposal, combined with a randomization vector (i.e with\n\u003e probability p you always offer an amount less than the proposed amount)\n\u003e would remove some of the certainty around a nodes unconfirmed balance. As\n\u003e with channel balances, however, there is always the possibility of a\n\u003e probabilistic attack i.e. lots of open channel requests sent over a short\n\u003e period of time that would give an attacker a reasonable approximation of\n\u003e your nodes available balance. A node could mitigate this by including an\n\u003e exponential backoff for open channel requests from any one node,\n\u003e essentially rate limiting the number of open channel requests that it will\n\u003e accept from a single peer, or peers globally.\n\u003e\n\u003e A node may also choose to set a policy around what it considers reasonable\n\u003e liquidity requests from a peer (i.e. no more than 0.05 BTC from any peer),\n\u003e which would further limit their exposure on the upper end of information\n\u003e gathering.\n\u003e\n\u003e Finally, as this liquidity feature is optional, any node who is truly\n\u003e interested in preserving the privacy of their funds may continue to\n\u003e establish channels the old fashioned way, i.e. via out of band negotiation\n\u003e with other, trusted node operators.\n\u003e\n\u003e Cheers,\n\u003e Lisa\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hey everyone,\n\u003e\u003e\n\u003e\u003e during the spec meeting we have discussed intensively about dual funded\n\u003e\u003e channels and potential game theory with the fees however I now believe that\n\u003e\u003e we missed out another important crucial part which is the privacy of the\n\u003e\u003e node providing liquidity.\n\u003e\u003e\n\u003e\u003e While I have not seen a concrete example for a channel establishment\n\u003e\u003e protocol that supports dual funded channels I have seen this proposal (\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html\n\u003e\u003e ) for advertising channel liquidity which assumed that the `open_channel`\n\u003e\u003e message would be modified as follows:\n\u003e\u003e\n\u003e\u003e `open_channel`:\n\u003e\u003e new feature flag (channel_flags): option_liquidity_buy [2nd least\n\u003e\u003e significant bit]\n\u003e\u003e push_msat: set to fee payment for requested liquidity\n\u003e\u003e [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding\n\u003e\u003e requested at channel open\n\u003e\u003e\n\u003e\u003e ...\n\u003e\u003e\n\u003e\u003e If a node cannot provide the liquidity requested in `open_channel`, it must\n\u003e\u003e return an error.\n\u003e\u003e\n\u003e\u003e With such a protocol I could now (basically only at the cost of internet\n\u003e\u003e traffic) probe a lower bound for the amount of BTC available by a node that\n\u003e\u003e allows for dual funded channels and abort the channel establishing process\n\u003e\u003e at some time before I ever spend / lock any of my own bitcoin.\n\u003e\u003e\n\u003e\u003e As I can even participate in the peer protocol without having a single\n\u003e\u003e channel open this situation seems to be even more severe.\n\u003e\u003e\n\u003e\u003e I don't have a clear suggestion how to mitigate against this. One general\n\u003e\u003e potential idea / solution would be to make spamming / probing more\n\u003e\u003e expensive. For example we could require the person to open a channel first\n\u003e\u003e and then ask the partner to splice something in (meaning we don't allow for\n\u003e\u003e one tx dual funded channels). In that case the node requesting liquidity\n\u003e\u003e had to do an onchain tx. also the requests to splice in can be identified\n\u003e\u003e and the person who feels to be probed can choose to fail the channel. I am\n\u003e\u003e not happy with my barrier as it would still be able to relatively cheaply\n\u003e\u003e abuse this and we run into a whole bunch of game theory about fees again.\n\u003e\u003e\n\u003e\u003e As the lightning network seems very keen to provide strong privacy to its\n\u003e\u003e users (c.f.: onion routing, keeping channel balances private, encrypted\n\u003e\u003e transport layer,...) I thought it is worthwhile pointing out the problem\n\u003e\u003e with the privacy for dual funded channels even though I don't have a\n\u003e\u003e concrete solution yet.\n\u003e\u003e\n\u003e\u003e best Rene\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e https://www.rene-pickhardt.de\n\u003e\u003e\n\u003e\u003e Skype: rene.pickhardt\n\u003e\u003e\n\u003e\u003e mobile: +49 (0)176 5762 3618\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/8761f6a8/attachment.html\u003e",
"sig": "21318b2fe67319f7b4d7714b6667ad3ec4b61015aa70bbf9047ce8076ea7f2db765009547dcde7bce22d02e6a308b213fa3980faaa3fcb9c7e401f361ea42b44"
}