Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CF91C2C for ; Mon, 12 Aug 2019 10:02:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A909987D for ; Mon, 12 Aug 2019 10:02:40 +0000 (UTC) Received: by mail-pf1-f181.google.com with SMTP id q139so1155643pfc.13 for ; Mon, 12 Aug 2019 03:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monash.edu; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4QYhHUG0OuebgFZtEAKkjU0Ibqh2Gp6JLlfWXCKed+g=; b=SrCKH/DL92h3VD4xWPKhb1IP1OdaXlyvlVZLnkfYIy1jGxTuoHitb1e/hSGST9USTH w4kEa8NVexU4kkrHTd/dfbBh5CDzPNRsMGI968q1eRdpcznTow7ZlKVaRgzE/xeL1J2G UpJ5i9YIyD6fB2P7jBN6w526TId0xN2JltCeFYkktO0yJoFbjX3ObRV/MYHMoiOuLUnh YrtwIR2Zupcnu7lAhjo2no+MyszOiE3+6IBJr86mxifeHydK3wf0GYbrYTODRQxOjK3T fTe6oJix4OZw5MW2wwypYfC7isEnGwEYXwulitvl0tWlKFuYu1fL3u0Svn7ST3Jfbz47 aoqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4QYhHUG0OuebgFZtEAKkjU0Ibqh2Gp6JLlfWXCKed+g=; b=KZZiU2SMGAuIDfsNJ0Xl4oVJIcj4yJab3rWDA4Q0dKd824c9E4JRyIhsYRd0TEJX7t 3qrCWSp/UxCE7HjSs+IKv/lbk/R8+wxEyxK+bOYXvYEI7vh8o6RbMm2UZz9mh7nZH23n plt2OuHJQ/MIJCrjpYfK/MwOEU8v6SJoDiyKRnS4emdhJnPbi0pl1UtVovLHqCaVnDdP SC4CX+tmnpKKfutf7hoCdgMWT7qmfHbVj2GhOdwCr+zsW9YwyzR6rVInvcaLCGRwo7Pr PUdddpDNaiE08sHje5L7DJdtUroPDFRXa9RMq0jKtXsj2Bl1mvSxdsFBat2FmnDX2Apj t0nA== X-Gm-Message-State: APjAAAWx9owi4t4ci9cQXbG1YIuZkGc6VmrLH0lcqiZhFgv0c/2Md6Ry LNxB9d8mKvCGrClCszxY5gB/Sg== X-Google-Smtp-Source: APXvYqy5VIJfEw24maD5gdNuhFWqALDqvX4cLA3vJ1ExpK3qAWg6AZ8ljEFs9X3EeoaJk0Z/ypcAVA== X-Received: by 2002:a17:90a:3be5:: with SMTP id e92mr2634306pjc.86.1565604160138; Mon, 12 Aug 2019 03:02:40 -0700 (PDT) Received: from [10.0.0.4] ([149.167.146.137]) by smtp.gmail.com with ESMTPSA id v145sm8884374pfc.31.2019.08.12.03.02.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 03:02:39 -0700 (PDT) From: Runchao Han Message-Id: <419535C8-DE1D-425B-A38C-4196607E43D3@monash.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_24A2BD3F-7E81-463A-8647-9155232E151D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 12 Aug 2019 20:02:33 +1000 In-Reply-To: To: ZmnSCPxj References: <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu> X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 13 Aug 2019 02:14:06 +0000 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 10:02:42 -0000 --Apple-Mail=_24A2BD3F-7E81-463A-8647-9155232E151D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi ZmnSCPxj, Thanks for your explanation. It=E2=80=99s comprehensive. I think our disagreement is on the step 6. In step 6, - Alice can publish or withhold the WJT tx - Bob can wait or unilaterally close the WJT payment channel I see the following things: First, both Alice and Bob can do something on the WJT blockchain at this = stage. What will happen if they publish txs simultaneously? For example, Alice publishes WJT tx while Bob publishes the tx closing = the channel. Second, will the concurrent txs introduce some attacks? I guess = concurrent-while-conflicting txs lead to highly unpredictable = behaviours. For example, Alice or Bob uses high tx fee to bribe miners to accept = her/his tx, in order to gain some advantage on the concurrent txs? Also, the =E2=80=9Cwhale transaction=E2=80=9D works here. Will this = introduce some double-spending variants? Third, assume Bob doesn=E2=80=99t wait any more and closes the channel. = In this case, Bob cannot get the premium. This is not consistent with the original American Call Option, in which = Bob should still get the premium. To conclude, I find this protocol highly depends on the implementation = of the payment channel as well as the expertise of participants (Alice = and Bob) c.f. relatively low usability. We may need a suitable payment channel implementation here. What=E2=80=99s= your opinion on the payment channel suitable for this scenario? Sincerely, Runchao > On 12 Aug 2019, at 6:05 pm, ZmnSCPxj wrote: >=20 > Good morning Runchao, >=20 >=20 > Sent with ProtonMail Secure Email. >=20 > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =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 = > wrote: >=20 >> Good morning ZmnSCPxj, >>=20 >> 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. >>=20 >> ## Analysis on the protocol from Fournier et al. >>=20 >> In this protocol, Bob participates in the swap following the steps = below: >>=20 >> 1. Alice and Bob creates a payment channel on WJT blockchain. >> 2. Bob creates the WJT transaction using the joint account of Alice = and Bob, 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 and 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 valid BTC transaction and the valid WJT transaction. >> 5. Alice broadcasts both the BTC transaction and the WJT transaction. >=20 > Incorrect. >=20 > The order is below. > I add also the behavior when the protocol is stalled such that a step = is not completed. >=20 > 1. Alice broadcasts and confirms a BTC transaction paying an HTLC, = hashlock Bob, Timelock Alice. > * Alice is initiating the protocol via this step, thus = non-completion of 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 = transaction. > * If Alice does not perform this, it aborts the protocol and Alice = locked her own money for no reason. > * If Bob does not perform this, it aborts the protocol and Bob = turns down the opportunity to earn 10,000 WJT (opportunity cost). > 4. Alice and Bob exchange signatures for the WJT-side claim = transaction which spends the funding transaction via the hashlock side = and gives 1,000,000 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 = locked her own money for no reason. > * If Bob does not perform this, it aborts the protocol and Bob = turns down 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 down 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 spending any of his inputs. > * Alice has an option here, but a very short option: up until Bob = grows tired of waiting. > Bob can make this timeout arbitrarily small, without requiring = input from Alice. > What value would there be in a 1-second option, even gotten for = free, 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. >=20 > Thus I do not believe this is needed for blockchain-layer atomic = swaps. >=20 > 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 strokes. > Unfortunately, using two hashes instead of one leaks to intermediate = hops that the payment involved a cross-currency swap, thus undesirable. >=20 >=20 >=20 >>=20 >> In a word, Bob is responsible for preparing the WJT transaction, = while Alice is responsible for preparing the BTC transaction and = broadcasting both transactions. >>=20 >> 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. >>=20 >> I have 3 questions on this scheme. >>=20 >> 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) broadcast 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. >=20 > Yes. >=20 >>=20 >> Second, I=E2=80=99m not sure whether Bob can spend his money in this = payment 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. >=20 > Depends on how the payment channel is implemented. > If you do something like send transactions spending the internal state = outputs, then ratifying this later by performing a transaction = cut-through to derive 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. >=20 >>=20 >> Third, let=E2=80=99s optimistically assume Bob can close this payment = channel without Alice=E2=80=99s consent. >=20 > Every payment channel system worth consideration today has a = unilateral close. > There is no need for optimism. >=20 >> 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. If 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. >=20 > 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. >=20 > Regards, > ZmnSCPxj --Apple-Mail=_24A2BD3F-7E81-463A-8647-9155232E151D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = ZmnSCPxj,

Thanks for = your explanation. It=E2=80=99s comprehensive.

I think our disagreement is on the step = 6.
In step 6,

- Alice can publish or withhold the WJT = tx
- Bob can wait or unilaterally close the WJT = payment channel

I see the following things:

First, both Alice and Bob can do = something on the WJT blockchain at this stage. What will happen if they = publish txs simultaneously?
For example, Alice = publishes WJT tx while Bob publishes the tx closing the = channel.

Second,= will the concurrent txs introduce some attacks?  I guess = concurrent-while-conflicting txs lead to highly unpredictable = behaviours.
For example, Alice or Bob uses high tx = fee to bribe miners to accept her/his tx, in order to gain some = advantage on the concurrent txs?
Also, the =E2=80=9Cw= hale transaction=E2=80=9D works here. Will this introduce some = double-spending variants?

Third, assume Bob doesn=E2=80=99t wait any more and closes = the channel. In this case, Bob cannot get the premium.
This is not consistent with the original American Call = Option, in which Bob should still get the premium.

To conclude, I find this = protocol highly depends on the implementation of the payment channel as = well as the expertise of participants (Alice and Bob) c.f. relatively = low usability.
We may need a suitable payment = channel implementation here. What=E2=80=99s your opinion on the payment = channel suitable for this scenario?

Sincerely,
Runchao

On 12 = Aug 2019, at 6:05 pm, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

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 Message =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> wrote:

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 Bob, 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 and 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 valid 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 not completed.

1.  Alice broadcasts and = confirms a BTC transaction paying an HTLC, hashlock Bob, Timelock = Alice.
   * Alice is initiating the protocol via this = step, thus non-completion of 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 transaction.
   * If Alice does not perform this, it aborts = the protocol and Alice locked her own money for no reason.
   * If Bob does = not perform this, it aborts the protocol and Bob turns down the = opportunity to earn 10,000 WJT (opportunity cost).
4.  Alice and Bob exchange = signatures for the WJT-side claim transaction which spends the funding = transaction via the hashlock side and gives 1,000,000 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 locked her own money for no reason.
   * If Bob does = not perform this, it aborts the protocol and Bob turns down 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 down 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 spending any of his inputs.
     * = Alice has an option here, but a very short option: up until Bob grows = tired of waiting.
       Bob can make this = timeout arbitrarily small, without requiring input from Alice.
       What value would = there be in a 1-second option, even gotten for free, 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 = strokes.
Unfortunately, = using two hashes instead of one leaks to intermediate hops that the = payment involved a cross-currency swap, thus undesirable.




In a word, Bob is responsible for preparing the WJT = transaction, while Alice 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) broadcast 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 payment 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 outputs, then ratifying this = later by performing a transaction cut-through to derive 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 channel without Alice=E2=80=99s consent.

Every payment channel system worth consideration today has a = unilateral close.
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. If = 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

= --Apple-Mail=_24A2BD3F-7E81-463A-8647-9155232E151D--