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

[Alexander Leishman]

Hello ZmnSCPxj,

> 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?

No this isn't what I'm suggesting. Let me try to explain again. Apologies
if this isn't clear:

Let's assume only two parties are engaging in this interaction, you and me.
You offer me the WJT/BTC exchange rate from your mult-chain node and I
route an LN payment from my BTC node to my WJT node through your
multi-chain node. My understanding is that the main problem with this is
the free optionality I get when my WJT node does not return the hash
preimage immediately to you and instead waits to see if the market price
fluctuates out of my favor until option/HTLC expiry. But what if we could
atomically swap this preimage for the final HTLC you sent me? If this
magical atomic information swap could happen (I don't get the final HTLC
unless I reveal the preimage) the payment would settle immediately (in the
two party case, let's assume no other intermediary nodes). A timed
commitment approach could potentially be feasible if the time required to
brute force the commitment is longer than the life of the "option"/HTLC.
I'm not necessarily suggesting this the optimal solution, but I haven't
seen the idea mentioned before.

-Alex


On Thu, Dec 27, 2018 at 2:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181227/ea806ad1/attachment.html>