diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-08-09 14:29:25 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-08-09 14:29:40 +0000 |
| commit | 5b6f8025383e2b92d71abda5832d20c0f30b8e52 (patch) | |
| tree | 08b485ac6f5db0b62074bbaf4e708d81e11bfa61 | |
| parent | 8315d52e1876ebfe1fb289243054c88bd22e5851 (diff) | |
| download | pi-bitcoindev-5b6f8025383e2b92d71abda5832d20c0f30b8e52.tar.gz pi-bitcoindev-5b6f8025383e2b92d71abda5832d20c0f30b8e52.zip | |
Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
| -rw-r--r-- | 73/3c213bbc1953de3dafedb9d13b3b68bdfff5bf | 163 |
1 files changed, 163 insertions, 0 deletions
diff --git a/73/3c213bbc1953de3dafedb9d13b3b68bdfff5bf b/73/3c213bbc1953de3dafedb9d13b3b68bdfff5bf new file mode 100644 index 000000000..a761466ba --- /dev/null +++ b/73/3c213bbc1953de3dafedb9d13b3b68bdfff5bf @@ -0,0 +1,163 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DE37C77 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Aug 2019 14:29:40 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch + [185.70.40.130]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0942167F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Aug 2019 14:29:36 +0000 (UTC) +Date: Fri, 09 Aug 2019 14:29:25 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1565360973; + bh=2yTqBDY/cLGy2vM7QtI0YyPRexLTmCdeoEUcb8yLWTc=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=hrwC/3kHQQFL5SeBEi00gc0l55RVDhGjACTFBIqX/uVflp3xHCTRmR8yemRx+6Xfl + tMy+zmMST4SloIJ0tPHcYNovEwOs1FxSIH90IBkGcLuBavpaWPqjgxDKMgB5gAwFKO + 2WGVCsOopCaNF/bFRV98dpXiWDx/3FinbYiA0wZ0= +To: Haoyu LIN <chris.haoyul@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com> +In-Reply-To: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com> +References: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: "jiangshan.yu@monash.edu" <jiangshan.yu@monash.edu>, + "runchao.han@monash.edu" <runchao.han@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: Fri, 09 Aug 2019 14:29:40 -0000 + +Good morning Haoyu LIN et al., + + +> We have investigated this problem in very detail. We analysed how profita= +ble the arbitrage can be given the default timelock setting (24/48 hrs). Ou= +r 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/2= +019/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://diyhp= +l.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://c= +oblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the trans= +action for the premium needs to be locked with the same secret hash but wit= +h 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: Bo= +b can get the premium without paying anything, by never participating in. +> +> To solve this, the transaction verifier needs to know the status of an de= +pendent transaction. Unfortunately, Bitcoin does not support the stateful t= +ransaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP= +_OUTPUT. It takes the id of an output, and produces the address of the outp= +ut=E2=80=99s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide wh= +ether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <p= +ubkeyhash> OP_EQUALVERIFY`. + +I believe an unsaid principle of SCRIPT opcode design is this: + +* No SCRIPT opcode can look at anything that is not in the transaction spen= +ding from the SCRIPT. + +This issue underlies the previous `OP_PUBREF` proposal also. + +The reason for this is: + +* 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` migh= +t 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 ente= +rs the mempool. + Thus it cannot get information about the block it is in. + Instead, the SCRIPT interpreter can have as input only the transaction th= +at is attempting to spend the SCRIPT. + +In any case: + +> However, this introduces a new problem: Bob can get the premium without p= +aying anything, by never participating in. + +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. + +Let me explain by this: + +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 premi= +um 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 a= +s it still requires the preimage, and at this point, only Alice knows the p= +reimage. +9. Alice and Bob sign the funding transaction and broadcast it. +10. Alice completes the claim transaction by adding the preimage and broad= +casts it. +11. Bob sees the preimage on the WJT blockchain and claims the BTC using t= +he preimage. + +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 cl= +aim the premium only. + +This is basically this proposal: https://lists.linuxfoundation.org/pipermai= +l/lightning-dev/2019-January/001798.html + + +In addition, if you really want the premium to be denominated in BTC, I hav= +e a more complicated ritual: https://lists.linuxfoundation.org/pipermail/li= +ghtning-dev/2019-January/001795.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. + + +Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`. + +Regards, +ZmnSCPxj + |