summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZmnSCPxj <ZmnSCPxj@protonmail.com>2019-08-12 08:05:53 +0000
committerbitcoindev <bitcoindev@gnusha.org>2019-08-12 08:06:05 +0000
commit933bc3c94a276d34ca6178bdfe1aac20f0cdacc8 (patch)
treef4c4cc8ba025ffe9073def277ec4112cadee5c5e
parent91e778abc882eeec596021f7299b9894a7422c7c (diff)
downloadpi-bitcoindev-933bc3c94a276d34ca6178bdfe1aac20f0cdacc8.tar.gz
pi-bitcoindev-933bc3c94a276d34ca6178bdfe1aac20f0cdacc8.zip
Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
-rw-r--r--bb/4464f493e51bb8666b0246c0a728c32b96244a199
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
+
+