<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello Rene,<div><br></div><div>Sorry for hijacking this thread, but I would suggest another route to tackle privacy and liquidity issues in general.</div><div><br></div><div>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.</div><div><br></div><div>It's very powerful, and simple model, that will allow variety of funding combinations.</div><div><br></div><div>The general diagram:</div><div><br></div><div>N inputs -> M outputs , N = a1s1 + a2s2 ... , M = b1s2 + b2s2 ... (simplified incomplete formulas for clarity) </div><div><br></div><div>a1 - input amount , s1 - signature.. same to b1, b2....</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Omar </div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 6:29 PM lisa neigut <<a href="mailto:niftynei@gmail.com">niftynei@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Hello Rene,</div></div><div dir="auto"><br></div><div dir="auto">This is a legitimate concern. Thank you for raising it.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Lisa</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev <<a href="mailto:lightning-dev@lists.linuxfoundation.org" target="_blank">lightning-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hey everyone, <div><br></div><div>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.</div><div><br></div><div>While I have not seen a concrete example for a channel establishment protocol that supports dual funded channels I have seen this proposal ( <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html" target="_blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html</a> ) for advertising channel liquidity which assumed that the `open_channel` message would be modified as follows: </div><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">`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
<br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">...</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">If a node cannot provide the liquidity requested in `open_channel`, it must
return an error.
<br></pre></div><div>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. </div><div><br></div><div>As I can even participate in the peer protocol without having a single channel open this situation seems to be even more severe. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>best Rene</div></div></div><div dir="ltr"><div dir="ltr"><div><br></div><div><br></div><div>-- <br></div><div><div dir="ltr" class="gmail-m_2234513018237646631m_4125609984216935607gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><a href="https://www.rene-pickhardt.de" target="_blank">https://www.rene-pickhardt.de</a></div><div><br></div><div>Skype: rene.pickhardt <br></div><div><br></div><div>mobile: +49 (0)176 5762 3618 </div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>