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

Corné Plooy corne at bitonic.nl
Tue May 22 14:59:08 UTC 2018


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





More information about the Lightning-dev mailing list