[Lightning-dev] Preventing delay abuse in a Lightning-based peer-to-peer exchange

[ZmnSCPxj]

Good morning Corne,

It seems to me that exchange delay abuse and the loop attack in the other thread have the same attack vector, namely delaying up to just before the delay period before responding.  So mitigations for one should apply as mitigations of the other.

Regards,
ZmnSCPxj


​Sent with ProtonMail Secure Email.​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On May 22, 2018 10:59 PM, Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Hi,
> 
> Lately I've been thinking about de-centralized crypto/crypto exchange
> 
> ("atomic swap") on the Lightning network. In my view, the main problem
> 
> is that participants can delay transactions (up to HTLC time-out, which
> 
> can be quite long), in order to speculate on exchange rate changes. I've
> 
> been looking for several approaches to deal with this problem.
> 
> The first approach[1] is not really interesting anymore in my opinion,
> 
> since I now favor the second approach. In essence, the first approach
> 
> let a latency monitor service monitor latencies in transactions; this
> 
> data can then be used as a source of information for building reputation
> 
> of market participants. Dealing with reputation in a community of
> 
> easily-created pseudonyms has its own set of issues. I did some analysis
> 
> on this and identified some problems.
> 
> The second approach[2] doesn't need a reputation network: the trading
> 
> parties delegate the job of executing the Lightning transaction to a
> 
> trusted third party. The trading parties don't need to trust each other,
> 
> and they only need to trust the third party to not cooperate with the
> 
> other trading party to perform the delay attack. This is not a perfectly
> 
> trust-free decentralized design, but there is no need for the trusted
> 
> party to have a monopoly, and compared to traditional exchanges, a lot
> 
> is gained: the trusted service provider can not steal customers' funds,
> 
> and unless it puts special requirements on performing its service, its
> 
> customers can remain anonymous, and it doesn't know which asset is traded.
> 
> It may not be needed to let a single Lightning node have channels for
> 
> the different cryptocurrencies: you can also have one node for each
> 
> currency, and let higher-level exchange software do the forwarding. In
> 
> that case, you wouldn't gossip the cross-currency link on Lightning
> 
> either: the exchange market has its own gossip mechanisms (the details
> 
> are still not worked out).
> 
> I doubt decentralized Lightning-based exchange will be competitive for
> 
> very high-frequency or high-volume needs, but for casual use by people
> 
> who are already on Lightning it might have some use. At least it gets
> 
> rid of the need for exchanges with large amounts of stored crypto
> 
> assets, which are a very attractive target for hackers.
> 
> CJP
> 
> [1] A trusted latency monitor service, for preventing abuse in a
> 
> Lightning-based peer-to-peer exchange,
> 
> https://bitonic.nl/public/latencymonitor.pdf
> 
> [2] Preventing transaction delays with a Lightning routing service, for
> 
> preventing abuse in a Lightning-based peer-to-peer exchange,
> 
> https://bitonic.nl/public/slowdown_prevention.pdf
> 
> Lightning-dev mailing list
> 
> Lightning-dev at lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev