diff options
author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-08-12 08:05:53 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-08-12 08:06:05 +0000 |
commit | 933bc3c94a276d34ca6178bdfe1aac20f0cdacc8 (patch) | |
tree | f4c4cc8ba025ffe9073def277ec4112cadee5c5e | |
parent | 91e778abc882eeec596021f7299b9894a7422c7c (diff) | |
download | pi-bitcoindev-933bc3c94a276d34ca6178bdfe1aac20f0cdacc8.tar.gz pi-bitcoindev-933bc3c94a276d34ca6178bdfe1aac20f0cdacc8.zip |
Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
-rw-r--r-- | bb/4464f493e51bb8666b0246c0a728c32b96244a | 199 |
1 files changed, 199 insertions, 0 deletions
diff --git a/bb/4464f493e51bb8666b0246c0a728c32b96244a b/bb/4464f493e51bb8666b0246c0a728c32b96244a new file mode 100644 index 000000000..747e328d0 --- /dev/null +++ b/bb/4464f493e51bb8666b0246c0a728c32b96244a @@ -0,0 +1,199 @@ +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 30DA18DC + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 12 Aug 2019 08:06:05 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch + [185.70.40.136]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40B312C6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 12 Aug 2019 08:06:02 +0000 (UTC) +Date: Mon, 12 Aug 2019 08:05:53 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1565597159; + bh=F8C1l39rZkf56mrqj+B/UHLiPd7K4ecy8WL6aNGmpJQ=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=oanAx4fwRRs7x8Hkx2y8fALbNDc2Kd/UYgnEFNRhc4iXM7uEE7upuj6qPqkywu+tm + Ju5CCmzcmofRxjqfM0t5Jc8cr7czYI94dPvJA8Kn4XRMQUgd5Dxvi9Rj9Hoqb+ZhwI + Qg49SSFElbk7R4vNCkESM12O+3sfG/G1Nj7uN51U= +To: Runchao Han <runchao.han@monash.edu> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <OLQmXBBI4kc9mkjbpr92bKp3UFhmg7ZtTn-m_VNinXNDT4CYz9Jf45gpSfxmkzXQLJfchMk7AaqEjbEor-ZJ02xrd_0yb2MOekXfRyovj6U=@protonmail.com> +In-Reply-To: <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu> +References: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com> + <qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com> + <ADA03200-1EED-4EAD-B320-3F2034F00954@monash.edu> + <aJ7usJIj2_reg-36SKEUDRApK8AhsIm2esl-I1CJSxs8cZACAmuR0X1bBNDK_zlDOUlzUWD2n2pCnbYx20Jg8kvAyryKZ9mqe0OH2J0QivY=@protonmail.com> + <CABnocSBSKsmWeRCOZE6DHwPXc2rucQGkHvjd+wJ+9JAJOT5=QQ@mail.gmail.com> + <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu> +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: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + "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: Mon, 12 Aug 2019 08:06:05 -0000 + +Good morning Runchao, + + +Sent with ProtonMail Secure Email. + +=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= +ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 +On Monday, August 12, 2019 11:19 AM, Runchao Han <runchao.han@monash.edu> w= +rote: + +> Good morning ZmnSCPxj, +> +> Sorry for the ambiguity of my last email. It was Sunday and I wrote it in= + 1 min on my bed. Let me elaborate what we are thinking of here. +> +> ## Analysis on the protocol from Fournier et al. +> +> In this protocol, Bob participates in the swap following the steps below: +> +> 1. Alice and Bob creates a payment channel on WJT blockchain. +> 2. Bob creates the WJT transaction using the joint account of Alice and B= +ob, including 1) Bob's input of 1,000,000 WJT, 2) Alice=E2=80=99s input for= + the 10,000 WJT premium. This transaction should be signed by both Alice an= +d Bob in order to be valid. +> 3. Bob signs the WJT transaction and sends the WJT transaction to Alice. +> 4. Alice signs this WJT transaction. At this stage, Alice has both the va= +lid BTC transaction and the valid WJT transaction. +> 5. Alice broadcasts both the BTC transaction and the WJT transaction. + +Incorrect. + +The order is below. +I add also the behavior when the protocol is stalled such that a step is no= +t completed. + +1. Alice broadcasts and confirms a BTC transaction paying an HTLC, hashloc= +k Bob, Timelock Alice. + * Alice is initiating the protocol via this step, thus non-completion o= +f this step is simply not performing the protocol. +2. Alice informs the BTC transaction to Bob. + * If Alice does not perform this, Bob does not know it and Alice locked= + her own money for no reason. +3. Alice and Bob indicate their inputs for the WJT-side funding transactio= +n. + * If Alice does not perform this, it aborts the protocol and Alice lock= +ed her own money for no reason. + * If Bob does not perform this, it aborts the protocol and Bob turns do= +wn the opportunity to earn 10,000 WJT (opportunity cost). +4. Alice and Bob exchange signatures for the WJT-side claim transaction wh= +ich spends the funding transaction via the hashlock side and gives 1,000,00= +0 WJT to payout to Alice and 10,000 WJT premium to Bob. + Order does not matter as funding tx is still unsigned. + * If Alice does not perform this, it aborts the protocol and Alice lock= +ed her own money for no reason. + * If Bob does not perform this, it aborts the protocol and Bob turns do= +wn the opportunity to earn 10,000 WJT (opportunity cost). +5. Bob provides signatures for the WJT funding tx, + * If Bob does not perform this, it aborts the protocol and Bob turns do= +wn the opportunity to earn 10,000 WJT (opportunity cost). +6. Alice signs WJT funding tx and broacasts and confirms. + * If Alice does not perform this, Bob invalidates the transaction by sp= +ending any of his inputs. + * Alice has an option here, but a very short option: up until Bob gro= +ws tired of waiting. + Bob can make this timeout arbitrarily small, without requiring inpu= +t from Alice. + What value would there be in a 1-second option, even gotten for fre= +e, when Alice has spent fees on the BTC-side transaction in the first place= +? +7. Alice completes the claim transaction and broadcasts. + * If Alice does not perform this, Bob simply waits out the timelock and= + recovers his funds plus premium. +8. Bob spends the BTC HTLC via the hashlock path. + * If Bob does not perform this, Bob has given money for free to Alice. + +Thus I do not believe this is needed for blockchain-layer atomic swaps. + +For Lightning-layer atomic swaps, the solution requires that two hashes be = +used on the WJT side, and is largely the above protocol in very broad strok= +es. +Unfortunately, using two hashes instead of one leaks to intermediate hops t= +hat the payment involved a cross-currency swap, thus undesirable. + + + +> +> In a word, Bob is responsible for preparing the WJT transaction, while Al= +ice is responsible for preparing the BTC transaction and broadcasting both = +transactions. +> +> Here, if Bob stalls, nothing will happen, because Bob cannot spend the 10= +,000 WJT premium without Alice=E2=80=99s signature. +> If Alice stalls, you are saying that Bob can spend the input of 1,000,000= + WJT so he does not lose any money. +> +> I have 3 questions on this scheme. +> +> First, I=E2=80=99m not sure how do you define =E2=80=9CAlice stalls= +=E2=80=9D. In this case, Alice can stall by 1) withhold the WJT tx, or 2) b= +roadcast BTC/WJT funding txs but withhold the preimage. +> If 2), this protocol is okay. But what about 1) i.e. Alice withholds the = +WJT tx? Here, Bob cannot do anything except for closing the payment channel= + and quit. + +Yes. + +> +> Second, I=E2=80=99m not sure whether Bob can spend his money in this paym= +ent channel while the payment channel is still valid. +> In Bitcoin, Bob needs to close the payment channel and get back his money= + first, then he can spend the money. + +Depends on how the payment channel is implemented. +If you do something like send transactions spending the internal state outp= +uts, then ratifying this later by performing a transaction cut-through to d= +erive the next state update, then it is no different from blockchain layer. +Of course, if you postulate the non-cooperation of Alice in this, there is = +indeed a need to close unilaterally. +But this is the same as any non-cooperation in any channel system: that is = +the entire point why you have unilateral closes. + +> +> Third, let=E2=80=99s optimistically assume Bob can close this payment cha= +nnel without Alice=E2=80=99s consent. + +Every payment channel system worth consideration today has a unilateral clo= +se. +There is no need for optimism. + +> Now he decides to close this channel if Alice does not broadcast the WJT = +tx all the time. +> Alice does not need to pay for the premium if she withholds the WJT tx. I= +f Alice decides not to proceed this swap, Bob should close this channel and= + get back 1,000,000 WJT. However, Bob cannot get the 10,000 WJT premium. + +And this time frame can be made arbitarily small by Bob by simple threat of= + unilateral close, thus not making it an option for Alice. + +Regards, +ZmnSCPxj + + |