<div dir="ltr"><div style="color:rgb(33,33,33);font-size:13px">Happy new year lightning-dev!</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">This topic is my main area of research at moment so I&#39;m really happy to see a thread about it. In general I agree with ZmnSCPxj&#39;s analysis and conclusions. I&#39;d like to add a couple of ideas to this discussion and would greatly appreciate some early peer review on them :)</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">HTLCs as American call options</div><div style="color:rgb(33,33,33);font-size:13px">=========================</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">I think the &quot;option problem&quot; 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:</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">&gt;1.  You provide me a hash of some secret preimage that only you know.</div><div style="color:rgb(33,33,33);font-size:13px">&gt;2.  You make an HTLC on the Bitcoin blockchain.</div><div style="color:rgb(33,33,33);font-size:13px">&gt;The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.</div><div style="color:rgb(33,33,33);font-size:13px">&gt;3.  I make an HTLC on the WJT blockchain.</div><div style="color:rgb(33,33,33);font-size:13px">&gt;The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">If we take this protocol and draw out its abstract functionality we get:</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time period `Eb` + `Ea`</div><div style="color:rgb(33,33,33);font-size:13px">2. *Make expiring offer* Bob makes an offer of asset `B` which expires at time `Eb`</div><div style="color:rgb(33,33,33);font-size:13px">3. *Take offer* Alice may take the offer up until time `Eb`</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">As has been pointed out, Alice has an &quot;option&quot; for the duration of `Eb` (and she didn&#39;t pay a premium). This is because Bob made her an offer he cannot cancel (an offer you can&#39;t cancel but has an expiration is basically the definition of being short an option contract).</div><div style="color:rgb(33,33,33);font-size:13px">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&#39;s how centralised exchanges work.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">Therefore, the ideal abstract functionality we want is:</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`</div><div style="color:rgb(33,33,33);font-size:13px">2. *Take Offer* Bob can take the offer (if Alice hasn&#39;t already cancelled it) and get `A` in exchange for `B`.</div><div style="color:rgb(33,33,33);font-size:13px">3. *Cancel Offer* If Bob hasn&#39;t taken the offer, Alice may get back `A` by cancelling the offer</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">I developed the protocol below which comes pretty close to realising this.</div><div style="color:rgb(33,33,33);font-size:13px">Let </div><div style="color:rgb(33,33,33);font-size:13px">- α and β and be two bitcoin-like blockchains</div><div style="color:rgb(33,33,33);font-size:13px">- Alice own asset `A` on the α blockchain and `C` on the β blockchain</div><div style="color:rgb(33,33,33);font-size:13px">- Bob own asset `B` on the β blockchain</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual)</div><div style="color:rgb(33,33,33);font-size:13px">2. Alice creates a partial β blockchain transaction by signing one input and one output (using SIGHASH_SINGLE for example):</div><div style="color:rgb(33,33,33);font-size:13px">   - The input is the asset `C`</div><div style="color:rgb(33,33,33);font-size:13px">   - The output is a HTLC which gives `B` and `C` to herself with the secret or gives them both to Bob on timeout</div><div style="color:rgb(33,33,33);font-size:13px">  She sends this partial transaction to Bob. (This gives us the &quot;Make Offer&quot; functionality)</div><div style="color:rgb(33,33,33);font-size:13px">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 &quot;Take Offer&quot; functionality)</div><div style="color:rgb(33,33,33);font-size:13px">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 &quot;Cancel Offer&quot; functionality)</div><div style="color:rgb(33,33,33);font-size:13px">5. If the &quot;Take Offer&quot; transaction is confirmed on β, Alice must unlock the HTLC before the timeout or Bob will gain `C` AND get back `B`.</div><div style="color:rgb(33,33,33);font-size:13px">6. Once she reveals the secret, she both gets back `C` and gains `B` on β.</div><div style="color:rgb(33,33,33);font-size:13px">7. Bob can now take `A` on α in the usual manner now that he has learned the secret.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">Bob is not guaranteed to get `A` after he &quot;takes&quot; the offer but he is guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` is Alice&#39;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.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">I believe this shows that HTLCs do not in cause options but rather uncancelable offers + uncollateralized HTLCs cause the option problem. </div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">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&#39;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.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">Cross Asset Payments Don&#39;t Make Sense</div><div style="color:rgb(33,33,33);font-size:13px">====================================</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">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.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">But this doesn&#39;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*.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">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!</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">*I don&#39;t know much about non-native assets on Bitcoin and their suggested integration with LN so I&#39;m just guessing here.</div><div style="color:rgb(33,33,33);font-size:13px"><br></div><div style="color:rgb(33,33,33);font-size:13px">All the best for 2019,</div><div style="color:rgb(33,33,33);font-size:13px">Lloyd</div><div style="color:rgb(33,33,33);font-size:13px">\n</div></div>