path: root/5b/86275b55149cab53bb6a7ccbe8e1b17bb14226

Return-Path: <chris.haoyul@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 190C5D7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Aug 2019 13:35:31 +0000 (UTC)
Received: by mail-ot1-f53.google.com with SMTP id s20so67102848otp.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <chris.haoyul@gmail.com>
Date: Fri, 9 Aug 2019 21:35:19 +0800
Message-ID: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 `<output> OP_LOOKUP_OUTPUT
<pubkeyhash> 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: <Bob_sig> <Bob_pubkey> 1
    Refund: <Alice_sig> <Alice_pubkey> 0
ScriptPubKey:
    OP_IF // Normal redeem path
        // the owner of <asset2_output> should be Alice
        // which means Alice has redeemed asset2
        <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> OP_EQUALVERIFY
        OP_DUP OP_HASH160 <Bob_pubkeyhash>
    OP_ELSE // Refund path
        // the premium timelock should be expired
        <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_DUP OP_HASH160 <Alice pubkey hash>
    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: <Bob_sig> <Bob_pubkey> 1
    Refund: <Alice_sig> <Alice_pubkey> 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
        <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> OP_NUMEQUAL
        <asset2_output> OP_LOOKUP_OUTPUT <Bob_pubkeyhash> OP_NUMEQUAL
        OP_ADD 1 OP_NUMEQUALVERIFY
        OP_DUP OP_HASH160 <Bob_pubkeyhash>
    OP_ELSE // Refund path
        // the premium timelock should be expired
        <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_DUP OP_HASH160 <Alice pubkey hash>
    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

<div dir=3D"ltr">Hi everybody!<br><br>Runchao, Jiangshan (both CC&#39;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.<br><br>The problem is called the &quot;free premium problem&quot;, wher=
e the initiator can abort the deal (i.e. have optionality) without any pena=
lty. See <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-d=
ev/2018-May/001292.html">https://lists.linuxfoundation.org/pipermail/lightn=
ing-dev/2018-May/001292.html</a> and <a href=3D"https://lists.linuxfoundati=
on.org/pipermail/lightning-dev/2018-December/001752.html">https://lists.lin=
uxfoundation.org/pipermail/lightning-dev/2018-December/001752.html</a> for =
detail.<br><br>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&#39;s totally risk-free. Please refer to our paper <a href=
=3D"https://eprint.iacr.org/2019/896">https://eprint.iacr.org/2019/896</a>,=
 and the related code <a href=3D"https://github.com/HAOYUatHZ/fair-atomic-s=
wap">https://github.com/HAOYUatHZ/fair-atomic-swap</a> if interested.<br><b=
r>Several studies have proposed for solving this problem e.g., <a href=3D"h=
ttp://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/">h=
ttp://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/</a=
> and <a href=3D"https://coblox.tech/docs/financial_crypto19.pdf">https://c=
oblox.tech/docs/financial_crypto19.pdf</a>. 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.<br><br>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 `&lt;output&gt; OP_LO=
OKUP_OUTPUT &lt;pubkeyhash&gt; OP_EQUALVERIFY`.<br><br>Assume that Alice an=
d Bob exchange asset1 and asset2, and using premium (same asset type as ass=
et2) as the collateral.<br><br>A sample premium transaction implementation =
of Atmoic Swap for Spot based on this opcode is:<br><br>```<br>ScriptSig:<b=
r>=C2=A0 =C2=A0 Redeem: &lt;Bob_sig&gt; &lt;Bob_pubkey&gt; 1<br>=C2=A0 =C2=
=A0 Refund: &lt;Alice_sig&gt; &lt;Alice_pubkey&gt; 0<br>ScriptPubKey:<br>=
=C2=A0 =C2=A0 OP_IF // Normal redeem path<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 //=
 the owner of &lt;asset2_output&gt; should be Alice<br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 // which means Alice has redeemed asset2<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 &lt;asset2_output&gt; OP_LOOKUP_OUTPUT &lt;Alice_pubkeyhash&gt; OP_E=
QUALVERIFY <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 &lt;Bob_pubkey=
hash&gt;<br>=C2=A0 =C2=A0 OP_ELSE // Refund path<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 // the premium timelock should be expired<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 &lt;locktime&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 OP_DUP OP_HASH160 &lt;Alice pubkey hash&gt;<br>=C2=A0 =C2=A0 OP_=
ENDIF<br>=C2=A0 =C2=A0 OP_EQUALVERIFY<br>=C2=A0 =C2=A0 OP_CHECKSIG<br>```<b=
r><br>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.<br><br>A sample premium transaction implementation of Atmoic Swap =
for Option based on this opcode is:<br><br>```<br>ScriptSig:<br>=C2=A0 =C2=
=A0 Redeem: &lt;Bob_sig&gt; &lt;Bob_pubkey&gt; 1<br>=C2=A0 =C2=A0 Refund: &=
lt;Alice_sig&gt; &lt;Alice_pubkey&gt; 0<br>ScriptPubKey:<br>=C2=A0 =C2=A0 O=
P_IF // Normal redeem path<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // the owner of t=
he asset2 should not be the contract<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // it s=
hould be either (redeemde by) Alice or (refunded by) Bob<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // which means Alice has redeemed asset2<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 &lt;asset2_output&gt; OP_LOOKUP_OUTPUT &lt;Alice_pubkeyhash&gt; =
OP_NUMEQUAL<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;asset2_output&gt; OP_LOOKUP_=
OUTPUT &lt;Bob_pubkeyhash&gt; OP_NUMEQUAL<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP=
_ADD 1 OP_NUMEQUALVERIFY<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 &=
lt;Bob_pubkeyhash&gt;<br>=C2=A0 =C2=A0 OP_ELSE // Refund path<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 // the premium timelock should be expired<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 &lt;locktime&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP<br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 OP_DUP OP_HASH160 &lt;Alice pubkey hash&gt;<br>=C2=A0=
 =C2=A0 OP_ENDIF<br>=C2=A0 =C2=A0 OP_EQUALVERIFY<br>=C2=A0 =C2=A0 OP_CHECKS=
IG<br>```<br><br>Again, please refer to <a href=3D"https://eprint.iacr.org/=
2019/896">https://eprint.iacr.org/2019/896</a> if you need more detail. The=
 BIP draft can be found at <a href=3D"https://github.com/HAOYUatHZ/bips/blo=
b/bip-lookup_output/bip-lookup_output.mediawiki">https://github.com/HAOYUat=
HZ/bips/blob/bip-lookup_output/bip-lookup_output.mediawiki</a><br><br>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.<br></div>

--000000000000758090058faf3f47--