Good morning Alex,

> > 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 solutio
 n, but I haven't seen the idea mentioned before.

The issue is that it is impossible for the exchange node to determine if it is 
talking to one other entity, or several distinct self-interested entities.

If you and YAIjbOJO were distinct entities, then this issue would not happen.

Because of Onion routing and the use of pseudonymous public keys, ZmnSCPxj 
cannot determine if you and YAIjbOJO are different entities.

Thus, your proposal must work both in the case where there is multiple hop 
nodes, and in the case where you and YAIjbOJO are the same entity actually.

So let us consider the case where you are using BTC to pay a node, randomly 
named bQqZrrEM, 1.0 WJT.
You have found the below route:

you ->BTC-> ZmnSCPxj ->WJT-> YAIjbOJO ->WJT-> bQqZrrEM

Because ZmnSCPxj is an exchange node, ZmnSCPxj demands a timed commitment so 
that the payment pushes through.

Now suppose that the following sequence of events occurs.

1.  Zeus has an affair.
2.  bQqZrrEM generates a random preimage and provides the hash to you.
3.  In the domestic argument after Hera finds out about the affair, Zeus 
randomly throws a lightning bolt that by chance hits and destroys bQqZrrEM.
4.  You initiate payment starting with ZmnSCPxj.

What happens then?
If the payment does not push through, then you could instead do:

1.  you/YAIjbOJO/bQqZrrEM (really the same entity) generate a preimage and its 
2.  You delete the bQqZrrEM identity.
3.  You inititate payment starting with ZmnSCPxj

This still lets you make an American Call Option by suddenly "reviving" the 
bQqZrrEM identity later in the "exercise" branch, or deciding to not revive the 
bQqZrrEM identity in the "not exercise" branch.

On the other hand, if the payment pushes through regardless of whether or not 
bQqZrrEm survives, then in the world where bQqZrrEm dies of stray lover quarrel 
lightning bolt, YAIjbOJO gets paid and I get the money from you, and you are 
sad because you paid for something you will never get.

> If this magical atomic information swap could happen (I don't get the final 
> HTLC unless I reveal the preimage)

What mechanism creates this?
If this mechanism involves timelocks also, then what prevents the same American 
Call Option from being created using the timelock of this magic mechanism?
The timelocks could be shorter, but it is still the same riskless 
free-of-premium American Call Option, so rational entities will continuosly 
spam exchange nodes with such attempts even if the timelock is short.

Does this mechanism require that the exchange know who the final destination 
will be?
What happens if while negotiating this information, one of the intermediate 
nodes drops?

If we disallow intermediate nodes, then I know who the final destination will 
be (it will be the next hop) and I can then exercise my newfound right to 
censor transactions.

Lightning-dev mailing list

Reply via email to