Author: Corné Plooy 2019-01-08 14:26:06
Published on: 2019-01-08T14:26:06+00:00
In this context, ZmnSCPxj is responding to a proposed solution by David that makes the exchange node (OM) also the RM in the route. However, with the use of preimages and hashes, it is vulnerable to attacks where the end payee (RM) simply claims the payment without letting the loop through. Moreover, if the RM is also the OM, then it is possible for the OM to steal the payment outright. Despite the vulnerability, all hops on the route are linked together the same way as hops in a regular Lightning payment. The bulk of the value should be roughly the same on each hop with sufficiently low spread and fees. By design, OT will pay the fees, so its outgoing amount will be higher than the incoming amount. If RM is OM, then effectively, you end up with a RM-OT-RM route, which is okay if RM is OM. However, there is still an issue where if RM is OM, then they can cooperate to perform a delay attack on OT. This is acceptable since some countermeasures can be taken by OT. Moreover, RM can either be OM and attack OT or be OT and attack OM. It is argued 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. So the proposal made by ZmnSCPxj is not perfect and contains the trusted role RM. Participants have to be careful about which RMs they do business with. Nonetheless, it has 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 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.
Updated on: 2023-06-02T16:33:58.292181+00:00