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>
Cc: "jiangshan.yu@monash.edu" <jiangshan.yu@monash.edu>
Subject: Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
Precedence: list

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