Date: Mon, 12 Aug 2019 08:05:53 +0000
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
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
Precedence: list

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