path: root/ae/9a1c0b6ed84aef8cef20912900f42c0239780d

Return-Path: <runchao.han@monash.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D3009D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Aug 2019 05:46:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com
	[209.85.210.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C47486D6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Aug 2019 05:46:40 +0000 (UTC)
Received: by mail-pf1-f196.google.com with SMTP id m30so47143145pff.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 09 Aug 2019 22:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monash.edu; s=google;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=rYkjCLqg+FkJRuOoz74EGcKCv4RLOM1p82IzNcMBM60=;
	b=XFIo9iuIT+i0QjBI4mxJ/XPMCadrcmYQFJXDeIeEWrARlQu4bidjxHdcbpb2yVNxu3
	89QQKij1Ok+BhzWHQQALUKGCU+XskmVr5YC6w+FSsoKuW5akiN8crZ+UWNjE2tbl3+lG
	zIBEyHn8x74gYLHP7syAnKV8PUZZrEqV2Qjld7vq/SGAYqUm1hBuOZZMWIBy4cqvlmzI
	pxlU2cTNVxh4p0vVg7tOn+CR/IKDsYGdoJDVRw+0WCVNQGeh+M0/NXjknI89QfRoI/nL
	O5GpsXfmg+NDeN7o+zDb04Cwude8iOQuwZO6FGExAlKmoSOn1ezpFw9oqax/F/L0LzD0
	mcRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=rYkjCLqg+FkJRuOoz74EGcKCv4RLOM1p82IzNcMBM60=;
	b=lF6s8dwXUUdwYWOv9exnWQY5q9uXV0mYtBYnYra+5+LqjzO26sL0N83maZaecLM+dc
	NxSyXpmOFipQtycCCqlyO3+PLTTDdbOmLSlAheBcy4mzBysg6xJyYa8jkclBeCFT4ip5
	/uKWIvtG+cqVoGEBZQOmgXEF9ZoHkc5NwbCTLjgCdJmWSe+ZY9Csyhpr8XqB3mZY7pXz
	hqxoRzMiatQ2vRDOUQYkx8IZLCu2SnyQpAxzkxnApMpqvV6l2SIZatIwbCPtqeEWci5l
	BCd9CbEdfL8OJAHiqLmY9PD8iftbB3OXx63F7Qm8UA53Y5ZeZTS4dBKAN1ZLUvpdJGYy
	1tEQ==
X-Gm-Message-State: APjAAAUS1ek9ZX3HQEg0s1C0C9I6LQkmDSSnQn75HI1NEIrq9YmtCbH3
	TXh/DH+onf1TKz3XWUfPmVEv4Q==
X-Google-Smtp-Source: APXvYqwsVd1KqOSlaIVovHkMwv1qEG1Vd+nw+487uoM2s/AhpNKVfLK5MYlyauq37E1QUWzpF/z1yg==
X-Received: by 2002:a17:90a:a897:: with SMTP id
	h23mr6491236pjq.44.1565416000214; 
	Fri, 09 Aug 2019 22:46:40 -0700 (PDT)
Received: from dyn-49-127-6-144.its.monash.edu.au
	(dyn-49-127-6-144.its.monash.edu.au. [49.127.6.144])
	by smtp.gmail.com with ESMTPSA id
	y14sm52963384pge.7.2019.08.09.22.46.37
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 09 Aug 2019 22:46:39 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Runchao Han <runchao.han@monash.edu>
In-Reply-To: <qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com>
Date: Sat, 10 Aug 2019 15:46:35 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D380D3EA-981C-44B7-A744-7E482B2347BC@monash.edu>
References: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com>
	<qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU,
	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: Sat, 10 Aug 2019 12:38:50 +0000
Cc: "jiangshan.yu@monash.edu" <jiangshan.yu@monash.edu>
Subject: Re: [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: Sat, 10 Aug 2019 05:46:41 -0000

Hi ZmnSCPxj,

Thanks for your reply.

I agree with your opinions about OP_LOOKUP_OUTPUT.
Indeed, the pruning mechanism renders this opcode unrealistic for some =
nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of =
verifying this tx.=20

However, I=E2=80=99m concerning of some security issues of your =
mentioned protocol (Alice pays the premium contingently on Bob =
participating).
If I understand it right, Alice and Bob should create a payment channel, =
and mutually construct the funding transaction that =E2=80=9CAlice pays =
Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT=E2=80=9D, =
where the time lock is T+24.
Here, Bob is responsible for broadcasting this tx after confirming =
Alice=E2=80=99s funding transaction on BTC blockchain.
In this case, Bob can arbitrage by broadcasting this tx *after T+24*. In =
this way, Bob receives the 10,000WJT, but Alice cannot redeem =
1,000,000WJT anymore.
If the premium (10,000WJT) is also hash-timelocked, Alice can keep =
unraveling the preimage, which makes the atomic swap still premium-free.

In the original atomic swap, Bob is incentivised to broadcast his =
funding transaction, otherwise he may miss the opportunity to redeem =
Alice=E2=80=99s asset.
Also, Alice will lose nothing regardless of how Bob behaves, because =
Alice locks all her money by hashlock.
However, Alice cannot lock the premium using hashlock. This gives Bob =
opportunity to arbitrage Alice=E2=80=99s premium.

What is implied here is that, where the premium should go strictly =
depends on where Bob=E2=80=99s asset goes.
If the Bitcoin=E2=80=99s timelock can be =E2=80=9Crelative=E2=80=9D =
(e.g. the timestamp can be x+24 where x is the timestamp of the block =
with this transaction), I think this protocol works.
Unfortunately, the =E2=80=9Cx=E2=80=9D here is also an external state =
according to your definition.

In conclusion, I believe your comments on OP_LOOKUP_OUTPUT reasonable, =
but cannot make sure if the premium mechanism can be implemented by =
using HTLCs.

Thanks,
Runchao

> On 10 Aug 2019, at 12:29 am, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Haoyu LIN et al.,
>=20
>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 decide whether Alice or Bob should take the premium =
by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.
>=20
> I believe an unsaid principle of SCRIPT opcode design is this:
>=20
> * No SCRIPT opcode can look at anything that is not in the transaction =
spending from the SCRIPT.
>=20
> This issue underlies the previous `OP_PUBREF` proposal also.
>=20
> The reason for this is:
>=20
> * We support a pruning mode, where in only the UTXO set is retained.
>  If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` =
might refer to a TXO that has been spent in very early historical =
blocks.
> * The SCRIPT interpreter is run only once, at the time the transaction =
enters the mempool.
>  Thus it cannot get information about the block it is in.
>  Instead, the SCRIPT interpreter can have as input only the =
transaction that is attempting to spend the SCRIPT.
>=20
> In any case:
>=20
>> However, this introduces a new problem: Bob can get the premium =
without paying anything, by never participating in.
>=20
> Premium payment can be made contingent on Bob participating.
> Of course, it does mean the premium is paid using the destination =
coin.
> It also requires the destination coin to support SegWit.
>=20
> Let me explain by this:
>=20
> 1.  Alice and Bob agree on swap parameters:
>    * Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
>    * Alice will pay 10,000 WJT as premium to Bob.
>    * Alice will lock BTC for 48 hours.
>    * Bob will lock WJT for 24 hours.
>    * The protocol will start at particular time T.
> 2.  Alice generates a preimage+hash.
> 3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and =
timelocked at T+48 going to Alice.
> 4.  Alice presents above UTXO to Bob.
> 5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT =
premium to Bob.
> 6.  Alice and Bob generate, but do not sign, a funding transaction =
spending some of Bob coin as well as the premium coin from Alice.
>    This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
>    The hashlock branch requires not just Alice, but also Bob.
>    The timelock branch at T+24 just requires Bob.
> 7.  Alice and Bob generate the claim transaction.
>    This spends the funding transaction HTLC output and pays out =
1,000,000 WJT to Alice and 10,000 WJT to Bob.
> 8.  Alice and Bob sign the claim transaction.
>    This does not allow Bob to make the claim transaction valid by =
itself as it still requires the preimage, and at this point, only Alice =
knows the preimage.
> 9.  Alice and Bob sign the funding transaction and broadcast it.
> 10.  Alice completes the claim transaction by adding the preimage and =
broadcasts it.
> 11.  Bob sees the preimage on the WJT blockchain and claims the BTC =
using the preimage.
>=20
> If Bob stalls at step 8, then there is no way to claim the premium, as =
the funding transaction (which is the source of the claim transaction =
that pays the premium) is not valid yet.
> After step 9, Bob has been forced to participate and cannot back out =
and claim the premium only.
>=20
> This is basically this proposal: =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001=
798.html
>=20
>=20
> In addition, if you really want the premium to be denominated in BTC, =
I have a more complicated ritual: =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001=
795.html
> The described ritual only sets up the American Call Option, but by the =
time it has been set up, the premium has been paid already and the rest =
of the execution is claiming the American Call Option.
>=20
>=20
> Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
>=20
> Regards,
> ZmnSCPxj