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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev