From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 190C5D7F for ; Fri, 9 Aug 2019 13:35:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F7C367F for ; Fri, 9 Aug 2019 13:35:31 +0000 (UTC) Received: by mail-ot1-f53.google.com with SMTP id s20so67102848otp.4 for ; Fri, 09 Aug 2019 06:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=GVsB8pRSDPyimBXT2yIia8xS4KXF+aMCEtAYBwMUorI=; b=sTFmERbPNlNKMJ4m200Lx9u8WUEOpTN/K1Wqhp0dYk6HRu3pP+PBWY2Rk1NZzlQzLR l57vATKTmz54FswjC4kw0pxR0XiuFL/a7gVKUHdrJhcWt4M9cJihIN2eWkBXWB2D10BT qXnk3Qba5mBrS0t53Vyo0c3r4z71AGXUSGgIMdnREsuS3D7ILzBEkKy1dmnjsNah5gI1 u0TbH7tmZvl/kqCsLe33N7jkgFYDcXfLq84uMPic3eqDF9z7+3jE1C2nYtjyDMhrTRZl MHt0+0z91T/LTVqVFH2kVVy33DfOmJMc2XGTtaV1raf5e+FJ5n3+3O8SV+c94xtaCxMk OPdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=GVsB8pRSDPyimBXT2yIia8xS4KXF+aMCEtAYBwMUorI=; b=Itzmdm1rRkCw3auYhKNDcwd7IpJ5hAQoY+YxqCf0TODpNN1OnVW+UeoW65U46sE6xN G8v8QRo8NIpQeuIG6KNFz3EroZjM77H0Pe2tjkzYGQ1LPD0rkseKnnL+7pI6pB84MJDc NfyDf+4tYuTVsgDVc3kraCMDQig7ja1aI34Cmr6dfQFFLTR9660tIrjBxCN9XaiinkK9 9DtB848jV+ri40SDVk/pt5mvLI4J8MzWEfrFnsijtNQqIkEMbu4Hcu8JJyWfEBOrV6UI 49nq38yEijePTOgw7gI5nC74QG3cJ3iBxlTbFq0W62qDrC+D0soXwSiqb/beKdrlD0b5 IRug== X-Gm-Message-State: APjAAAUQ09G30p8L/OW7N8c5kMxTxFoqnIrcfeLjKTMBEAQCpVa7J/EB uAZp2gZ4gH7wrFaX1DI1WkYEKTnNbbZGgzR8wNhJWGbw X-Google-Smtp-Source: APXvYqylgFJRDJVXOgUPUPhunRrXmCs26yiETOm7GjmBgXakt/X7woLPEv5JJeXnMXKXySScSHk7F3np1rGqAwAmulk= X-Received: by 2002:aca:b485:: with SMTP id d127mr6781166oif.34.1565357730266; Fri, 09 Aug 2019 06:35:30 -0700 (PDT) MIME-Version: 1.0 From: Haoyu LIN Date: Fri, 9 Aug 2019 21:35:19 +0800 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000758090058faf3f47" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 09 Aug 2019 13:36:47 +0000 Cc: jiangshan.yu@monash.edu, runchao.han@monash.edu Subject: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 13:35:32 -0000 --000000000000758090058faf3f47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everybody! Runchao, Jiangshan (both CC'ed) and I bring up a BIP draft that describes a new opcode OP_LOOKUP_OUTPUT, which is used for mitigating the arbitrage risk in a HTLC-based Atomic Swap. The problem is called the "free premium problem", where the initiator can abort the deal (i.e. have optionality) without any penalty. See https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.h= tml and https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001= 752.html for detail. We have investigated this problem in very detail. We analysed how profitable the arbitrage can be given the default timelock setting (24/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for stock market. This can be attractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap if interested. Several studies have proposed for solving this problem e.g., http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the transaction for the premium needs to be locked with the same secret hash but with a flipped payout, i.e. when redeemed with the secret, the money goes back to Alice and after timelock, the premium goes to Bob as a compensation for Alice not revealing the secret. However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in. To solve this, the transaction verifier needs to know the status of an dependent transaction. Unfortunately, Bitcoin does not support the stateful transaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of the output=E2=80=99s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can d= ecide whether Alice or Bob should take the premium by ` OP_LOOKUP_OUTPUT OP_EQUALVERIFY`. Assume that Alice and Bob exchange asset1 and asset2, and using premium (same asset type as asset2) as the collateral. A sample premium transaction implementation of Atmoic Swap for Spot based on this opcode is: ``` ScriptSig: Redeem: 1 Refund: 0 ScriptPubKey: OP_IF // Normal redeem path // the owner of should be Alice // which means Alice has redeemed asset2 OP_LOOKUP_OUTPUT OP_EQUALVERIFY OP_DUP OP_HASH160 OP_ELSE // Refund path // the premium timelock should be expired OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG ``` We also explore the Atomic Swaps in American Call Options scenario, which is different from the Spot scenario. Alice should pay for the premium besides the underlying asset, regardless of whether the swap is successful or not. In reality, the option sellers are trustworthy - the option sellers never abort the contract. However, in Atomic Swaps, Bob can abort the contracts like Alice. To keep the Atomic Swap consistent with the American Call Options, the premium should follow that: Alice pays the premium to Bob if 1) Alice redeems Bob=E2=80=99s asset before Bob=E2=80=99s timelock, or 2= ) Bob refunds his asset after Bob=E2=80=99s timelock but before Alice=E2=80=99s timelock.= If Alice=E2=80=99s timelock expires, Alice can refund her premium back. A sample premium transaction implementation of Atmoic Swap for Option based on this opcode is: ``` ScriptSig: Redeem: 1 Refund: 0 ScriptPubKey: OP_IF // Normal redeem path // the owner of the asset2 should not be the contract // it should be either (redeemde by) Alice or (refunded by) Bob // which means Alice has redeemed asset2 OP_LOOKUP_OUTPUT OP_NUMEQUAL OP_LOOKUP_OUTPUT OP_NUMEQUAL OP_ADD 1 OP_NUMEQUALVERIFY OP_DUP OP_HASH160 OP_ELSE // Refund path // the premium timelock should be expired OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG ``` Again, please refer to https://eprint.iacr.org/2019/896 if you need more detail. The BIP draft can be found at https://github.com/HAOYUatHZ/bips/blob/bip-lookup_output/bip-lookup_output.= mediawiki To conclude, in order to avoid the risk-free optionality in Atomic Swap, we propose a new opcode OP_LOOKUP_OUTPUT, using premium to mitigate the risk of Atomic Swap both in Spot and in Option. --000000000000758090058faf3f47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everybody!

Runchao, Jiangshan (both CC'ed) a= nd I bring up a BIP draft=C2=A0that describes a new opcode OP_LOOKUP_OUTPUT= , which is used for mitigating the arbitrage risk in a HTLC-based Atomic Sw= ap.

The problem is called the "free premium problem", wher= e the initiator can abort the deal (i.e. have optionality) without any pena= lty. See https://lists.linuxfoundation.org/pipermail/lightn= ing-dev/2018-May/001292.html and https://lists.lin= uxfoundation.org/pipermail/lightning-dev/2018-December/001752.html for = detail.

We have investigated this problem in very detail. We analyse= d how profitable the arbitrage can be given the default timelock setting (2= 4/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%,= which is non-negligible compared with 0.3% for stock market. This can be a= ttractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896,= and the related code https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
Several studies have proposed for solving this problem e.g., h= ttp://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://c= oblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the t= ransaction for the premium needs to be locked with the same secret hash but= with a flipped payout, i.e. when redeemed with the secret, the money goes = back to Alice and after timelock, the premium goes to Bob as a compensation= for Alice not revealing the secret. However, this introduces a new problem= : Bob can get the premium without paying anything, by never participating i= n.

To solve this, the transaction verifier needs to know the status = of an dependent transaction. Unfortunately, Bitcoin does not support the st= ateful transaction functionalities. Therefore, we propose the new opcode: O= P_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of = the output=E2=80=99s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can d= ecide whether Alice or Bob should take the premium by `<output> OP_LO= OKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.

Assume that Alice an= d Bob exchange asset1 and asset2, and using premium (same asset type as ass= et2) as the collateral.

A sample premium transaction implementation = of Atmoic Swap for Spot based on this opcode is:

```
ScriptSig:=C2=A0 =C2=A0 Redeem: <Bob_sig> <Bob_pubkey> 1
=C2=A0 =C2= =A0 Refund: <Alice_sig> <Alice_pubkey> 0
ScriptPubKey:
= =C2=A0 =C2=A0 OP_IF // Normal redeem path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 //= the owner of <asset2_output> should be Alice
=C2=A0 =C2=A0 =C2=A0= =C2=A0 // which means Alice has redeemed asset2
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> OP_E= QUALVERIFY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 <Bob_pubkey= hash>
=C2=A0 =C2=A0 OP_ELSE // Refund path
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 // the premium timelock should be expired
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 OP_DUP OP_HASH160 <Alice pubkey hash>
=C2=A0 =C2=A0 OP_= ENDIF
=C2=A0 =C2=A0 OP_EQUALVERIFY
=C2=A0 =C2=A0 OP_CHECKSIG
```
We also explore the Atomic Swaps in American Call Options scenario, w= hich is different from the Spot scenario. Alice should pay for the premium = besides the underlying asset, regardless of whether the swap is successful = or not. In reality, the option sellers are trustworthy - the option sellers= never abort the contract. However, in Atomic Swaps, Bob can abort the cont= racts like Alice. To keep the Atomic Swap consistent with the American Call= Options, the premium should follow that: Alice pays the premium to Bob if = 1) Alice redeems Bob=E2=80=99s asset before Bob=E2=80=99s timelock, or 2) B= ob refunds his asset after Bob=E2=80=99s timelock but before Alice=E2=80=99= s timelock. If Alice=E2=80=99s timelock expires, Alice can refund her premi= um back.

A sample premium transaction implementation of Atmoic Swap = for Option based on this opcode is:

```
ScriptSig:
=C2=A0 =C2= =A0 Redeem: <Bob_sig> <Bob_pubkey> 1
=C2=A0 =C2=A0 Refund: &= lt;Alice_sig> <Alice_pubkey> 0
ScriptPubKey:
=C2=A0 =C2=A0 O= P_IF // Normal redeem path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // the owner of t= he asset2 should not be the contract
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // it s= hould be either (redeemde by) Alice or (refunded by) Bob
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 // which means Alice has redeemed asset2
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> = OP_NUMEQUAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <asset2_output> OP_LOOKUP_= OUTPUT <Bob_pubkeyhash> OP_NUMEQUAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP= _ADD 1 OP_NUMEQUALVERIFY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 &= lt;Bob_pubkeyhash>
=C2=A0 =C2=A0 OP_ELSE // Refund path
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 // the premium timelock should be expired
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
=C2=A0= =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 <Alice pubkey hash>
=C2=A0= =C2=A0 OP_ENDIF
=C2=A0 =C2=A0 OP_EQUALVERIFY
=C2=A0 =C2=A0 OP_CHECKS= IG
```

Again, please refer to https://eprint.iacr.org/2019/896 if you need more detail. The= BIP draft can be found at https://github.com/HAOYUat= HZ/bips/blob/bip-lookup_output/bip-lookup_output.mediawiki

To co= nclude, in order to avoid the risk-free optionality in Atomic Swap, we prop= ose a new opcode OP_LOOKUP_OUTPUT, using premium to mitigate the risk of At= omic Swap both in Spot and in Option.
--000000000000758090058faf3f47--