{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-01-02\n📝 Original message:\nHappy new year lightning-dev!\n\nThis topic is my main area of research at moment so I'm really happy to see\na thread about it. In general I agree with ZmnSCPxj's analysis and\nconclusions. I'd like to add a couple of ideas to this discussion and would\ngreatly appreciate some early peer review on them :)\n\nHTLCs as American call options\n=========================\n\nI think the \"option problem\" is actually caused by protocols using HTLCs in\na naive way rather than the use of HTLCs themselves. Consider the atomic\nswap protocol described in the OP:\n\n\u003e1.  You provide me a hash of some secret preimage that only you know.\n\u003e2.  You make an HTLC on the Bitcoin blockchain.\n\u003eThe value of this HTLC is `P`, the hash is the hash you gave above, and\nthe timelock is `E` + 1 day.\n\u003e3.  I make an HTLC on the WJT blockchain.\n\u003eThe value of this HTLC is 1, the hash is the hash you gave, and the\ntimelock is `E`.\n\nIf we take this protocol and draw out its abstract functionality we get:\n\n1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time\nperiod `Eb` + `Ea`\n2. *Make expiring offer* Bob makes an offer of asset `B` which expires at\ntime `Eb`\n3. *Take offer* Alice may take the offer up until time `Eb`\n\nAs has been pointed out, Alice has an \"option\" for the duration of `Eb`\n(and she didn't pay a premium). This is because Bob made her an offer he\ncannot cancel (an offer you can't cancel but has an expiration is basically\nthe definition of being short an option contract).\nIn order to remedy this, the party that makes the offer must be able to\ncancel their offer at any point after they have made it (before the\ncounterparty has taken it). This should be intuitive because it's how\ncentralised exchanges work.\n\nTherefore, the ideal abstract functionality we want is:\n\n1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`\n2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled\nit) and get `A` in exchange for `B`.\n3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by\ncancelling the offer\n\nI developed the protocol below which comes pretty close to realising this.\nLet\n- α and β and be two bitcoin-like blockchains\n- Alice own asset `A` on the α blockchain and `C` on the β blockchain\n- Bob own asset `B` on the β blockchain\n\n1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per\nusual)\n2. Alice creates a partial β blockchain transaction by signing one input\nand one output (using SIGHASH_SINGLE for example):\n   - The input is the asset `C`\n   - The output is a HTLC which gives `B` and `C` to herself with the\nsecret or gives them both to Bob on timeout\n  She sends this partial transaction to Bob. (This gives us the \"Make\nOffer\" functionality)\n3. If Bob wants to accept the offer, he adds asset `B` to another input of\nthe transaction and posts it to β. (This gives us \"Take Offer\"\nfunctionality)\n4. If Alice wishes to cancel the trade before Bob has confirmed this\ntransaction she double spends the `C` output and then reclaims `A` on α\nafter the timeout. (This gives us the \"Cancel Offer\" functionality)\n5. If the \"Take Offer\" transaction is confirmed on β, Alice must unlock the\nHTLC before the timeout or Bob will gain `C` AND get back `B`.\n6. Once she reveals the secret, she both gets back `C` and gains `B` on β.\n7. Bob can now take `A` on α in the usual manner now that he has learned\nthe secret.\n\nBob is not guaranteed to get `A` after he \"takes\" the offer but he is\nguaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously,\n`C` is Alice's collateral for the trade. Bob should only take the offer if\nhe wants `A` more than `B` and if he is sure that the value of gaining `C`\nwill be greater than any loss he could experience from `B` depreciating\nrelative to `A` during the execution of the protocol.\n\nI believe this shows that HTLCs do not in cause options but rather\nuncancelable offers + uncollateralized HTLCs cause the option problem.\n\nI think this protocol works in payment channels in the case that Alice and\nBob have direct channels to each other. The issue is that if Alice decides\nshe wants to cancel at the same time Bob decides he wants to take it you\nhave to go to the blockchain to resolve the issue (which will be rather\narbitrary). CJP's idea of having a 3rd party who is trusted simply to\ncompute the outcome of a offer (cancelled or taken) in layer 2 networks\nseems like a promising direction because this would avoid on-chain\nresolution in this case.\n\nCross Asset Payments Don't Make Sense\n====================================\n\nAs ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and\nthe other party receiving it as asset `B` with some exchange node in the\nmiddle doing a conversion is unsound given what we are able to construct in\nLightning.\n\nBut this doesn't necessarily mean that Lightning has to be single asset.\nTheoretically, a single two-party channel could record multiple asset types\nwith a state transaction that has distinct outputs for different\nasset-type/party combinations. This would allow you to buy an amount of the\ndesired asset in one of your channels by simply doing a state update where\nyou lose `A` in exchange for `B` with your direct peer (no HTLCs needed).\nYou can then just send `B` normally to the receiver. This is not quite as\ngood as a cross asset payment but it could still be useful*.\n\nQuite simply, if you want to send someone asset `A` but they want to\nreceive asset `B` then just buy asset `B` with asset `A` and then send `B`\nto them!\n\n*I don't know much about non-native assets on Bitcoin and their suggested\nintegration with LN so I'm just guessing here.\n\nAll the best for 2019,\nLloyd\n\\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190102/5adacabb/attachment-0001.html\u003e"}