Good morning Alex and Will, > 1. Cross-asset brokers charge a standard option premium to perform the > brokerage. I can't tell if you think this is totally broken or if it's just > sad. I don't understand lightning well enough to figure that out on my own - > could you expand more on what effects this would have?
It is quite broken. We assume generally that if a payment route fails, that the payer making the payment route loses nothing. Unfortunately, once there is a premium involved for cross-asset swaps, it implies that any failures *after* the swap will now have a cost, specifically, the premium paid. Perhaps you could inform the cross-asset broker who the ultimate payee is so it can retry failures after it on your behalf, but now the broker has the ability to censor payments to payees it does not like. > 2. Cross-asset brokers require counterparties to issue them a symmetric but > slightly more out-of-the-money call, which they can redeem in the event of a > large FX swing. This bounds their FX losses. I am uncertain what you mean exactly. Do you mean, that if you make a swap on Lightning, which *might* be a Bitcoin-to-WJT American Call Option, I will refuse to forward until I also get something that is a WJT-to-Bitcoin call option, similar to a butterfly spread? That implies that in the "normal", non-American-call-option case, the payer has the target asset, which brings up the question: why would the payer even go through the cross-asset broker in a Lightning route if the payer already has the target asset? > There’s another potential partial solution here if we can create some > cryptographic protocol for atomically swapping information. This would be > used to swap the final HTLC sig for the hash preimage, preventing the > optionality issue. This idea was inspired by a paper called “Timed > Commitments” by Dan Boneh > (https://www.iacr.org/archive/crypto2000/18800237/18800237.pdf). > > The high level idea is that each party swaps a commitment to the information > they want to atomically swap and then slowly reveal verifiable “hints” that > make it easier and easier to brute force the commitment. Each party takes > turns revealing a hint. > > The protocol to do something like this in lightning doesn’t exist afaik but > it seems feasible. This also may fail to work when there are intermediary > nodes not controlled by the two trading parties. The entire point of using HTLCs in Lightning routing is to enforce that the final payee actually gets paid, or nobody along the route gets paid. From my understanding of this, if this is used, then an intermediate node can try to brute force the preimage instead of actually bothering to forward payments or hints. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
