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 30DA18DC for ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu> References: <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 , "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: 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 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