Good morning CJP, > > - No exchange: unattractive, because there is significant demand for > this. > > - Regular Lightning-based or other HTLC-like atomic swap: unattractive, > because of the exploitable "American Call Option" nature (as we both > described). May only function with a very high spread, compensating for > OM's risk. > > - Regular, centralized exchanges: current situation. Third party is > trusted with holding funds and executing trade orders. > > - My proposal: third party is trusted with executing transactions > properly (not performing the delay attack). > > - Trustless exchange: holy grail, but I don't know how to do that. > > So I don't claim my proposal is perfect, but I'd like to argue it is > the best known system because it's an improvement over the current > situation where most people use centralized exchanges, at least in > terms of trust required(*).
You may be right. I wonder however if this is a "small enough" hole that leaving it is an acknowledged security vulnerability may be better than replacing it with a trusted third party. One may compare with the SSH "trust the first pubkey, verify the second onwards" weakness, to SSL "trust the certificate authority to say whose pubkey is whose". OMs do have mitigations, specifically: (1) reducing the allowed forwarded CLTV distance and (2) increasing the bid-ask spread; perhaps that can be enough to enable a somewhat-multiasset network. > Now, if an RM can be punished, it would be even better. I was thinking in the > direction of collecting proof of misbehavior, which can then help make the RM > lose its (lucrative!) business, but I doubt this is possible. The hop node just before the RM can provide proof that it offered an HTLC and the RM allowed the HTLC offer to be made. It can provide a commitment transaction signed by itself and the RM, with that commitment transaction containing the HTLC in question. This is proof that the RM *could* pull the HTLC, but did not do so quickly enough. Since RM nodes are publicly known, perhaps we can make a different routing from S to RM, one that reveals (to hop nodes) their distance to RM, but not to S. RM nodes provide a service to the network and we can argue that the loss of their privacy here is acceptable, as long as the payee S is still able to keep its privacy, as an acceptable cost to ensuring that RM behaves honestly. If the just-before-last node (let us call this G or "guard" node) can monitor the time that RM pulls the HTLC, then it can provide proof that RM had the ability to pull the HTLC but did not do so. The G cannot attack the RM, since if G then stalls after the RM releases the preimage to it, the RM can just publish the commitment transaction with the HTLC onchain, together with the release of the preimage. In the onchain case, proof of RM malfeasance reduces to checking if the preimage appears onchain "fast enough". However, this could be attacked by stuffing blocks and increasing onchain fees, a risk whose cost the RM will pass to F and S nodes. Under Poon-Dryja, we can do: 1. After a new commitment transaction is signed, the old commitment transaction is still publishable onchain. 2. The old commitment transaction only becomes unpublishable (via punishment) if it is revoked, which is done after the new commitment transaction is signed. 3. Thus, if G node wishes to show malfeasance by RM, it must show that it revoked the commitment transaction just before that one by publishing the new commitment transaction (containing the HTLC to RM as proof that RM could have claimed but did not) onchain instead of the old commitment transaction (since what is published onchain becomes true, that is sufficient). 4. The RM must defend against the claim of malfeasance by claiming the HTLC immediately, publishing the preimage. 5. The OM must know the channel by which the RM gets paid (and thus the identity of G and RM) in order to monitor that channel and get its input asset immediately when a malfeasance claim is responded to by the RM. Under Decker-Russell-Osuntokun, we cannot perform the claim of malfeasance, and the RM defense, onchain. This is because of the CSV in-between the update and settlement transactions, which prevents timely publication of the HTLC and the preimage claiming it onchain. This is compensated for somewhat in that the signing of a new update transaction is sufficient to prevent publication (via gainsaying) of older update transactions, so we can perform the claim of malfeasance and the RM defense offchain completely. The G node publishes (via some non-blockchain protocol somehow, wave hands here) the update transaction and corresponding settlement transaction with the HTLC in question as a claim-of-malfeasance. The RM node defends against this by publishing (via some uncensorable method) the transaction that claims the HTLC with a preimage. The need for some other uncensorable method of showing the preimage is something of a problem, however; in this, Poon-Dryja is surprisingly superior due to its placement of the CSV *after* HTLCs instead of before. We can have a mostly Decker-Russell-Osuntokun network, with Poon-Dryja only between G and RM nodes, so that most users do not have to suffer the issues of Poon-Dryja for everyday usage. Note that since the path from S to RM is selected by RM, though, S must serve as G, and every node in-between that is honestly not a sockpuppet of RM should be prepared to shut down their channels immediately in case of slow response from the next node. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
