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 7D3009D for ; 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 ; Sat, 10 Aug 2019 05:46:40 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id m30so47143145pff.8 for ; 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 In-Reply-To: Date: Sat, 10 Aug 2019 15:46:35 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ZmnSCPxj , Bitcoin Protocol Discussion 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 ` OP_LOOKUP_OUTPUT 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