[Lightning-dev] An Argument For Single-Asset Lightning Network

Corné Plooy corne at bitonic.nl
Tue Jan 8 14:26:06 UTC 2019


ZmnSCPxj,


Without reading your proposed solution, I don't understand the problem
you describe here:

> David solution effectively makes the exchange node (OM in CJP terminology) also the RM in the route.
> However, with use of mere preimages and hashes, it is obvious that such a "loop" where the end payee (RM) is also an intermediate node, is foolish, as the end payee will simply claim the payment without letting the loop through.
> And since the payee (S in CJP terminology) is paid via the delta from its incoming to its outgoing HTLC on that loop, then if the RM is the OM then it is possible for the OM To simply steal the payment outright.
>
> (It is helpful to realize that payment routes pay not just the end payee, but all hops in the middle; thus the "real" target of the payment (the one who receives the bulk of the value) need not be at the *end* of the route)


All hops on the route are linked together the same way as hops in a
regular Lightning payment. An intermediate node who is also the end
payee, and therefore knows the preimage, can indeed shortcut the payment
by accepting the payment on the intermediate node instead of forwarding
it; this is true for all Lightning payments [*].


I think the scenario where "the bulk of the value" ends up at one or
more intermediate nodes should not typically apply here. With a
sufficiently low spread and fees, the bulk of the value should be
roughly the same on each hop. The only thing that might be stolen is in
those fees and exchange rate differences.


By design, OT will pay the fees, so its outgoing amount will be higher
than the incoming amount. RM will not want to exclude OT from its route.
If RM is OM, then RM cannot exclude OM from the route either.
Effectively, you end up with a RM-OT-RM route, which is OK if RM is OM.
Minimizing Lightning route length to minimize fees is not a bad thing.


There is a remaining issue though, that if RM is OM, then, obviously, RM
and OM can cooperate to perform a delay attack on OT. I think this is
acceptable, given that in section 4 of my paper[1] I already described
some countermeasures OT can take. I think the attack possibility is
wider: if OT and OM are anonymous / pseudonymous toward each other, then
RM can either be OM and attack OT, or it can be OT and attack OM. I
argued in section 4 that OM is more vulnerable than OT, but luckily the
assumptions to this argument do not apply anymore. OM knows the
attacker: it is RM. RM can perform a single attack on OM, and after
that, OM will refuse incoming exchange transactions that are coordinated
by RM.


So my proposal is not perfect, it does contain the trusted role RM, and
participants have to be somewhat careful which RMs they do business
with. However, it does have the benefit of de-coupling the trusted role
RM from the actual trading roles of OT and OM, so you only need to trust
a few parties and you can trade with lots of parties. Trading parties
can remain anonymous to RM, and they can hide from RM what second asset
they are trading, and to what exchange rate, so there's very little that
can be censored by RM.


CJP


[*] So it is a vulnerability for the idea where you anonymously donate
to an intermediate node by giving it a huge fee. The vulnerability does
not apply if you are the final payee, since nobody else but the final
payee can perform the attack. Other parties might control multiple nodes
on the route, but they only learn the preimage after HTLC acceptance on
all hops.


[1] https://bitonic.nl/public/slowdown_prevention.pdf





More information about the Lightning-dev mailing list