ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-28 📝 Original message: Good morning Alex, > > Do ...

📅 Original date posted:2018-12-28
📝 Original message:
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 solution, 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 hash.
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.


Regards,
ZmnSCPxj