Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-02 📝 Original message: Happy new year ...

📅 Original date posted:2019-01-02
📝 Original message:
Happy new year lightning-dev!

This topic is my main area of research at moment so I'm really happy to see
a thread about it. In general I agree with ZmnSCPxj's analysis and
conclusions. I'd like to add a couple of ideas to this discussion and would
greatly appreciate some early peer review on them :)

HTLCs as American call options
=========================

I think the "option problem" is actually caused by protocols using HTLCs in
a naive way rather than the use of HTLCs themselves. Consider the atomic
swap protocol described in the OP:

>1. You provide me a hash of some secret preimage that only you know.
>2. You make an HTLC on the Bitcoin blockchain.
>The value of this HTLC is `P`, the hash is the hash you gave above, and
the timelock is `E` + 1 day.
>3. I make an HTLC on the WJT blockchain.
>The value of this HTLC is 1, the hash is the hash you gave, and the
timelock is `E`.

If we take this protocol and draw out its abstract functionality we get:

1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time
period `Eb` + `Ea`
2. *Make expiring offer* Bob makes an offer of asset `B` which expires at
time `Eb`
3. *Take offer* Alice may take the offer up until time `Eb`

As has been pointed out, Alice has an "option" for the duration of `Eb`
(and she didn't pay a premium). This is because Bob made her an offer he
cannot cancel (an offer you can't cancel but has an expiration is basically
the definition of being short an option contract).
In order to remedy this, the party that makes the offer must be able to
cancel their offer at any point after they have made it (before the
counterparty has taken it). This should be intuitive because it's how
centralised exchanges work.

Therefore, the ideal abstract functionality we want is:

1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`
2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled
it) and get `A` in exchange for `B`.
3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by
cancelling the offer

I developed the protocol below which comes pretty close to realising this.
Let
- α and β and be two bitcoin-like blockchains
- Alice own asset `A` on the α blockchain and `C` on the β blockchain
- Bob own asset `B` on the β blockchain

1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per
usual)
2. Alice creates a partial β blockchain transaction by signing one input
and one output (using SIGHASH_SINGLE for example):
- The input is the asset `C`
- The output is a HTLC which gives `B` and `C` to herself with the
secret or gives them both to Bob on timeout
She sends this partial transaction to Bob. (This gives us the "Make
Offer" functionality)
3. If Bob wants to accept the offer, he adds asset `B` to another input of
the transaction and posts it to β. (This gives us "Take Offer"
functionality)
4. If Alice wishes to cancel the trade before Bob has confirmed this
transaction she double spends the `C` output and then reclaims `A` on α
after the timeout. (This gives us the "Cancel Offer" functionality)
5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the
HTLC before the timeout or Bob will gain `C` AND get back `B`.
6. Once she reveals the secret, she both gets back `C` and gains `B` on β.
7. Bob can now take `A` on α in the usual manner now that he has learned
the secret.

Bob is not guaranteed to get `A` after he "takes" the offer but he is
guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously,
`C` is Alice's collateral for the trade. Bob should only take the offer if
he wants `A` more than `B` and if he is sure that the value of gaining `C`
will be greater than any loss he could experience from `B` depreciating
relative to `A` during the execution of the protocol.

I believe this shows that HTLCs do not in cause options but rather
uncancelable offers + uncollateralized HTLCs cause the option problem.

I think this protocol works in payment channels in the case that Alice and
Bob have direct channels to each other. The issue is that if Alice decides
she wants to cancel at the same time Bob decides he wants to take it you
have to go to the blockchain to resolve the issue (which will be rather
arbitrary). CJP's idea of having a 3rd party who is trusted simply to
compute the outcome of a offer (cancelled or taken) in layer 2 networks
seems like a promising direction because this would avoid on-chain
resolution in this case.

Cross Asset Payments Don't Make Sense
====================================

As ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and
the other party receiving it as asset `B` with some exchange node in the
middle doing a conversion is unsound given what we are able to construct in
Lightning.

But this doesn't necessarily mean that Lightning has to be single asset.
Theoretically, a single two-party channel could record multiple asset types
with a state transaction that has distinct outputs for different
asset-type/party combinations. This would allow you to buy an amount of the
desired asset in one of your channels by simply doing a state update where
you lose `A` in exchange for `B` with your direct peer (no HTLCs needed).
You can then just send `B` normally to the receiver. This is not quite as
good as a cross asset payment but it could still be useful*.

Quite simply, if you want to send someone asset `A` but they want to
receive asset `B` then just buy asset `B` with asset `A` and then send `B`
to them!

*I don't know much about non-native assets on Bitcoin and their suggested
integration with LN so I'm just guessing here.

All the best for 2019,
Lloyd
\n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190102/5adacabb/attachment-0001.html>;