[bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Haoyu LIN]

[-- Attachment #1: Type: text/plain, Size: 4937 bytes --]

Hi everybody!

Runchao, Jiangshan (both CC'ed) and I bring up a BIP draft that describes a
new opcode OP_LOOKUP_OUTPUT, which is used for mitigating the arbitrage
risk in a HTLC-based Atomic Swap.

The problem is called the "free premium problem", where the initiator can
abort the deal (i.e. have optionality) without any penalty. See
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html
and
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
for detail.

We have investigated this problem in very detail. We analysed how
profitable the arbitrage can be given the default timelock setting (24/48
hrs). Our result shows that the profit can be approximately 1% ~ 2.3%,
which is non-negligible compared with 0.3% for stock market. This can be
attractive as it's totally risk-free. Please refer to our paper
https://eprint.iacr.org/2019/896, and the related code
https://github.com/HAOYUatHZ/fair-atomic-swap if interested.

Several studies have proposed for solving this problem e.g.,
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is
that, the transaction for the premium needs to be locked with the same
secret hash but with a flipped payout, i.e. when redeemed with the secret,
the money goes back to Alice and after timelock, the premium goes to Bob as
a compensation for Alice not revealing the secret. However, this introduces
a new problem: Bob can get the premium without paying anything, by never
participating in.

To solve this, the transaction verifier needs to know the status of an
dependent transaction. Unfortunately, Bitcoin does not support the stateful
transaction functionalities. Therefore, we propose the new opcode:
OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of
the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide
whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT
<pubkeyhash> OP_EQUALVERIFY`.

Assume that Alice and Bob exchange asset1 and asset2, and using premium
(same asset type as asset2) as the collateral.

A sample premium transaction implementation of Atmoic Swap for Spot based
on this opcode is:

```
ScriptSig:
    Redeem: <Bob_sig> <Bob_pubkey> 1
    Refund: <Alice_sig> <Alice_pubkey> 0
ScriptPubKey:
    OP_IF // Normal redeem path
        // the owner of <asset2_output> should be Alice
        // which means Alice has redeemed asset2
        <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> OP_EQUALVERIFY
        OP_DUP OP_HASH160 <Bob_pubkeyhash>
    OP_ELSE // Refund path
        // the premium timelock should be expired
        <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_DUP OP_HASH160 <Alice pubkey hash>
    OP_ENDIF
    OP_EQUALVERIFY
    OP_CHECKSIG
```

We also explore the Atomic Swaps in American Call Options scenario, which
is different from the Spot scenario. Alice should pay for the premium
besides the underlying asset, regardless of whether the swap is successful
or not. In reality, the option sellers are trustworthy - the option sellers
never abort the contract. However, in Atomic Swaps, Bob can abort the
contracts like Alice. To keep the Atomic Swap consistent with the American
Call Options, the premium should follow that: Alice pays the premium to Bob
if 1) Alice redeems Bob’s asset before Bob’s timelock, or 2) Bob refunds
his asset after Bob’s timelock but before Alice’s timelock. If Alice’s
timelock expires, Alice can refund her premium back.

A sample premium transaction implementation of Atmoic Swap for Option based
on this opcode is:

```
ScriptSig:
    Redeem: <Bob_sig> <Bob_pubkey> 1
    Refund: <Alice_sig> <Alice_pubkey> 0
ScriptPubKey:
    OP_IF // Normal redeem path
        // the owner of the asset2 should not be the contract
        // it should be either (redeemde by) Alice or (refunded by) Bob
        // which means Alice has redeemed asset2
        <asset2_output> OP_LOOKUP_OUTPUT <Alice_pubkeyhash> OP_NUMEQUAL
        <asset2_output> OP_LOOKUP_OUTPUT <Bob_pubkeyhash> OP_NUMEQUAL
        OP_ADD 1 OP_NUMEQUALVERIFY
        OP_DUP OP_HASH160 <Bob_pubkeyhash>
    OP_ELSE // Refund path
        // the premium timelock should be expired
        <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_DUP OP_HASH160 <Alice pubkey hash>
    OP_ENDIF
    OP_EQUALVERIFY
    OP_CHECKSIG
```

Again, please refer to https://eprint.iacr.org/2019/896 if you need more
detail. The BIP draft can be found at
https://github.com/HAOYUatHZ/bips/blob/bip-lookup_output/bip-lookup_output.mediawiki

To conclude, in order to avoid the risk-free optionality in Atomic Swap, we
propose a new opcode OP_LOOKUP_OUTPUT, using premium to mitigate the risk
of Atomic Swap both in Spot and in Option.

[-- Attachment #2: Type: text/html, Size: 5893 bytes --]

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj]

Good morning Haoyu LIN et al.,


> We have investigated this problem in very detail. We analysed how profitable the arbitrage can be given the default timelock setting (24/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for stock market. This can be attractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
>
> Several studies have proposed for solving this problem e.g., http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the transaction for the premium needs to be locked with the same secret hash but with a flipped payout, i.e. when redeemed with the secret, the money goes back to Alice and after timelock, the premium goes to Bob as a compensation for Alice not revealing the secret. However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
>
> To solve this, the transaction verifier needs to know the status of an dependent transaction. Unfortunately, Bitcoin does not support the stateful transaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.

I believe an unsaid principle of SCRIPT opcode design is this:

* No SCRIPT opcode can look at anything that is not in the transaction spending from the SCRIPT.

This issue underlies the previous `OP_PUBREF` proposal also.

The reason for this is:

* We support a pruning mode, where in only the UTXO set is retained.
  If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very early historical blocks.
* The SCRIPT interpreter is run only once, at the time the transaction enters the mempool.
  Thus it cannot get information about the block it is in.
  Instead, the SCRIPT interpreter can have as input only the transaction that is attempting to spend the SCRIPT.

In any case:

> However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.

Premium payment can be made contingent on Bob participating.
Of course, it does mean the premium is paid using the destination coin.
It also requires the destination coin to support SegWit.

Let me explain by this:

1.  Alice and Bob agree on swap parameters:
    * Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
    * Alice will pay 10,000 WJT as premium to Bob.
    * Alice will lock BTC for 48 hours.
    * Bob will lock WJT for 24 hours.
    * The protocol will start at particular time T.
2.  Alice generates a preimage+hash.
3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and timelocked at T+48 going to Alice.
4.  Alice presents above UTXO to Bob.
5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT premium to Bob.
6.  Alice and Bob generate, but do not sign, a funding transaction spending some of Bob coin as well as the premium coin from Alice.
    This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
    The hashlock branch requires not just Alice, but also Bob.
    The timelock branch at T+24 just requires Bob.
7.  Alice and Bob generate the claim transaction.
    This spends the funding transaction HTLC output and pays out 1,000,000 WJT to Alice and 10,000 WJT to Bob.
8.  Alice and Bob sign the claim transaction.
    This does not allow Bob to make the claim transaction valid by itself as it still requires the preimage, and at this point, only Alice knows the preimage.
9.  Alice and Bob sign the funding transaction and broadcast it.
10.  Alice completes the claim transaction by adding the preimage and broadcasts it.
11.  Bob sees the preimage on the WJT blockchain and claims the BTC using the preimage.

If Bob stalls at step 8, then there is no way to claim the premium, as the funding transaction (which is the source of the claim transaction that pays the premium) is not valid yet.
After step 9, Bob has been forced to participate and cannot back out and claim the premium only.

This is basically this proposal: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html


In addition, if you really want the premium to be denominated in BTC, I have a more complicated ritual: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
The described ritual only sets up the American Call Option, but by the time it has been set up, the premium has been paid already and the rest of the execution is claiming the American Call Option.


Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Runchao Han]

Hi ZmnSCPxj,

Thanks for your reply.

I agree with your opinions about OP_LOOKUP_OUTPUT.
Indeed, the pruning mechanism renders this opcode unrealistic for some nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of verifying this tx. 

However, I’m concerning of some security issues of your mentioned protocol (Alice pays the premium contingently on Bob participating).
If I understand it right, Alice and Bob should create a payment channel, and mutually construct the funding transaction that “Alice pays Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT”, where the time lock is T+24.
Here, Bob is responsible for broadcasting this tx after confirming Alice’s funding transaction on BTC blockchain.
In this case, Bob can arbitrage by broadcasting this tx *after T+24*. In this way, Bob receives the 10,000WJT, but Alice cannot redeem 1,000,000WJT anymore.
If the premium (10,000WJT) is also hash-timelocked, Alice can keep unraveling the preimage, which makes the atomic swap still premium-free.

In the original atomic swap, Bob is incentivised to broadcast his funding transaction, otherwise he may miss the opportunity to redeem Alice’s asset.
Also, Alice will lose nothing regardless of how Bob behaves, because Alice locks all her money by hashlock.
However, Alice cannot lock the premium using hashlock. This gives Bob opportunity to arbitrage Alice’s premium.

What is implied here is that, where the premium should go strictly depends on where Bob’s asset goes.
If the Bitcoin’s timelock can be “relative” (e.g. the timestamp can be x+24 where x is the timestamp of the block with this transaction), I think this protocol works.
Unfortunately, the “x” here is also an external state according to your definition.

In conclusion, I believe your comments on OP_LOOKUP_OUTPUT reasonable, but cannot make sure if the premium mechanism can be implemented by using HTLCs.

Thanks,
Runchao

> On 10 Aug 2019, at 12:29 am, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Haoyu LIN et al.,
> 
> 
>> We have investigated this problem in very detail. We analysed how profitable the arbitrage can be given the default timelock setting (24/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for stock market. This can be attractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
>> 
>> Several studies have proposed for solving this problem e.g., http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the transaction for the premium needs to be locked with the same secret hash but with a flipped payout, i.e. when redeemed with the secret, the money goes back to Alice and after timelock, the premium goes to Bob as a compensation for Alice not revealing the secret. However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
>> 
>> To solve this, the transaction verifier needs to know the status of an dependent transaction. Unfortunately, Bitcoin does not support the stateful transaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.
> 
> I believe an unsaid principle of SCRIPT opcode design is this:
> 
> * No SCRIPT opcode can look at anything that is not in the transaction spending from the SCRIPT.
> 
> This issue underlies the previous `OP_PUBREF` proposal also.
> 
> The reason for this is:
> 
> * We support a pruning mode, where in only the UTXO set is retained.
>  If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very early historical blocks.
> * The SCRIPT interpreter is run only once, at the time the transaction enters the mempool.
>  Thus it cannot get information about the block it is in.
>  Instead, the SCRIPT interpreter can have as input only the transaction that is attempting to spend the SCRIPT.
> 
> In any case:
> 
>> However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
> 
> Premium payment can be made contingent on Bob participating.
> Of course, it does mean the premium is paid using the destination coin.
> It also requires the destination coin to support SegWit.
> 
> Let me explain by this:
> 
> 1.  Alice and Bob agree on swap parameters:
>    * Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
>    * Alice will pay 10,000 WJT as premium to Bob.
>    * Alice will lock BTC for 48 hours.
>    * Bob will lock WJT for 24 hours.
>    * The protocol will start at particular time T.
> 2.  Alice generates a preimage+hash.
> 3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and timelocked at T+48 going to Alice.
> 4.  Alice presents above UTXO to Bob.
> 5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT premium to Bob.
> 6.  Alice and Bob generate, but do not sign, a funding transaction spending some of Bob coin as well as the premium coin from Alice.
>    This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
>    The hashlock branch requires not just Alice, but also Bob.
>    The timelock branch at T+24 just requires Bob.
> 7.  Alice and Bob generate the claim transaction.
>    This spends the funding transaction HTLC output and pays out 1,000,000 WJT to Alice and 10,000 WJT to Bob.
> 8.  Alice and Bob sign the claim transaction.
>    This does not allow Bob to make the claim transaction valid by itself as it still requires the preimage, and at this point, only Alice knows the preimage.
> 9.  Alice and Bob sign the funding transaction and broadcast it.
> 10.  Alice completes the claim transaction by adding the preimage and broadcasts it.
> 11.  Bob sees the preimage on the WJT blockchain and claims the BTC using the preimage.
> 
> If Bob stalls at step 8, then there is no way to claim the premium, as the funding transaction (which is the source of the claim transaction that pays the premium) is not valid yet.
> After step 9, Bob has been forced to participate and cannot back out and claim the premium only.
> 
> This is basically this proposal: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html
> 
> 
> In addition, if you really want the premium to be denominated in BTC, I have a more complicated ritual: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
> The described ritual only sets up the American Call Option, but by the time it has been set up, the premium has been paid already and the rest of the execution is claiming the American Call Option.
> 
> 
> Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
> 
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj]

Good morning Runchao,




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, August 10, 2019 1:44 PM, Runchao Han <runchao.han@monash.edu> wrote:

> Hi ZmnSCPxj,
>
> Thanks for your reply.
>
> I agree with your opinions about OP_LOOKUP_OUTPUT.
> Indeed, the pruning mechanism renders this opcode unrealistic for some nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of verifying this tx.
>
> However, I’m concerning of some security issues of your mentioned protocol (Alice pays the premium contingently on Bob participating).
> If I understand it right, Alice and Bob should create a payment channel, and mutually construct the funding transaction that “Alice pays Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT”, where the time lock is T+24.
> Here, Bob is responsible for broadcasting this tx after confirming Alice’s funding transaction on BTC blockchain.

No, Bob is not.

The signature exchange for the WJT-side funding tx is done by:

1. Alice waits for Bob to provide all its signatures for inputs that will fund the 1,000,000 WJT payout.
2. Alice signs its inputs that will fund the 10,000 WJT premium.
3. Alice broadacasts the completely signed funding tx.

Alice is the one responsible for broadcasting the funding tx.

If Bob stalls, it is not a Bob side option (i.e. Bob cannot stall then continue the protocol when the exchange rate moves to its favor) as Alice can refuse to sign and broadcast the funding tx once it has decided Bob is trolling it, thus Bob cannot force Alice to perform.

If Alice stalls, Bob can double-spend one of its inputs at a low feerate.
This either aborts the protocol, or if Alice then broadcasts the funding tx at the pre-agreed feerate and it is confirmed, the premium is now already paid to Bob.

Regards,
ZmnSCPxj

> In this case, Bob can arbitrage by broadcasting this tx after T+24. In this way, Bob receives the 10,000WJT, but Alice cannot redeem 1,000,000WJT anymore.
> If the premium (10,000WJT) is also hash-timelocked, Alice can keep unraveling the preimage, which makes the atomic swap still premium-free.
>
> In the original atomic swap, Bob is incentivised to broadcast his funding transaction, otherwise he may miss the opportunity to redeem Alice’s asset.
> Also, Alice will lose nothing regardless of how Bob behaves, because Alice locks all her money by hashlock.
> However, Alice cannot lock the premium using hashlock. This gives Bob opportunity to arbitrage Alice’s premium.
>
> What is implied here is that, where the premium should go strictly depends on where Bob’s asset goes.
> If the Bitcoin’s timelock can be “relative” (e.g. the timestamp can be x+24 where x is the timestamp of the block with this transaction), I think this protocol works.
> Unfortunately, the “x” here is also an external state according to your definition.
>
> In conclusion, I believe your comments on OP_LOOKUP_OUTPUT reasonable, but cannot make sure if the premium mechanism can be implemented by using HTLCs.
>
> Thanks,
> Runchao
>
> > On 10 Aug 2019, at 12:29 am, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > Good morning Haoyu LIN et al.,
> >
> > > We have investigated this problem in very detail. We analysed how profitable the arbitrage can be given the default timelock setting (24/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for stock market. This can be attractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
> > > Several studies have proposed for solving this problem e.g., http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the transaction for the premium needs to be locked with the same secret hash but with a flipped payout, i.e. when redeemed with the secret, the money goes back to Alice and after timelock, the premium goes to Bob as a compensation for Alice not revealing the secret. However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
> > > To solve this, the transaction verifier needs to know the status of an dependent transaction. Unfortunately, Bitcoin does not support the stateful transaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.
> >
> > I believe an unsaid principle of SCRIPT opcode design is this:
> >
> > -   No SCRIPT opcode can look at anything that is not in the transaction spending from the SCRIPT.
> >
> > This issue underlies the previous `OP_PUBREF` proposal also.
> > The reason for this is:
> >
> > -   We support a pruning mode, where in only the UTXO set is retained.
> >     If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very early historical blocks.
> >
> > -   The SCRIPT interpreter is run only once, at the time the transaction enters the mempool.
> >     Thus it cannot get information about the block it is in.
> >     Instead, the SCRIPT interpreter can have as input only the transaction that is attempting to spend the SCRIPT.
> >
> >
> > In any case:
> >
> > > However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
> >
> > Premium payment can be made contingent on Bob participating.
> > Of course, it does mean the premium is paid using the destination coin.
> > It also requires the destination coin to support SegWit.
> > Let me explain by this:
> >
> > 1.  Alice and Bob agree on swap parameters:
> >
> > -   Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
> > -   Alice will pay 10,000 WJT as premium to Bob.
> > -   Alice will lock BTC for 48 hours.
> > -   Bob will lock WJT for 24 hours.
> > -   The protocol will start at particular time T.
> >
> > 2.  Alice generates a preimage+hash.
> > 3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and timelocked at T+48 going to Alice.
> > 4.  Alice presents above UTXO to Bob.
> > 5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT premium to Bob.
> > 6.  Alice and Bob generate, but do not sign, a funding transaction spending some of Bob coin as well as the premium coin from Alice.
> >     This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
> >     The hashlock branch requires not just Alice, but also Bob.
> >     The timelock branch at T+24 just requires Bob.
> >
> > 7.  Alice and Bob generate the claim transaction.
> >     This spends the funding transaction HTLC output and pays out 1,000,000 WJT to Alice and 10,000 WJT to Bob.
> >
> > 8.  Alice and Bob sign the claim transaction.
> >     This does not allow Bob to make the claim transaction valid by itself as it still requires the preimage, and at this point, only Alice knows the preimage.
> >
> > 9.  Alice and Bob sign the funding transaction and broadcast it.
> > 10.  Alice completes the claim transaction by adding the preimage and broadcasts it.
> > 11.  Bob sees the preimage on the WJT blockchain and claims the BTC using the preimage.
> >
> > If Bob stalls at step 8, then there is no way to claim the premium, as the funding transaction (which is the source of the claim transaction that pays the premium) is not valid yet.
> > After step 9, Bob has been forced to participate and cannot back out and claim the premium only.
> > This is basically this proposal: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html
> > In addition, if you really want the premium to be denominated in BTC, I have a more complicated ritual: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
> > The described ritual only sets up the American Call Option, but by the time it has been set up, the premium has been paid already and the rest of the execution is claiming the American Call Option.
> > Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
> > Regards,
> > ZmnSCPxj

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Runchao Han]

[-- Attachment #1: Type: text/plain, Size: 9560 bytes --]

If I remember it right, Alice first signs the WJT transaction, sends it to
Bob, then Bob signs it and makes this transaction valid.

If so, there are two problems.
First, Bob gets the valid tx first, and he can choose not to send it to
Alice.
Second, even if Bob honestly sends Alice this tx, Alice cannot fully
control when to broadcast this to, as Bob also has this transaction.

If Bob first signs then Alice signs, Alice still has optionality, as she
can choose whether to publish this tx and preimage.

Runchao

On Sat, Aug 10, 2019 at 10:50 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Runchao,
>
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, August 10, 2019 1:44 PM, Runchao Han <runchao.han@monash.edu>
> wrote:
>
> > Hi ZmnSCPxj,
> >
> > Thanks for your reply.
> >
> > I agree with your opinions about OP_LOOKUP_OUTPUT.
> > Indeed, the pruning mechanism renders this opcode unrealistic for some
> nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of
> verifying this tx.
> >
> > However, I’m concerning of some security issues of your mentioned
> protocol (Alice pays the premium contingently on Bob participating).
> > If I understand it right, Alice and Bob should create a payment channel,
> and mutually construct the funding transaction that “Alice pays Bob 10,000
> WJT; Bob hash-timelocked pays Alice 1,000,000WJT”, where the time lock is
> T+24.
> > Here, Bob is responsible for broadcasting this tx after confirming
> Alice’s funding transaction on BTC blockchain.
>
> No, Bob is not.
>
> The signature exchange for the WJT-side funding tx is done by:
>
> 1. Alice waits for Bob to provide all its signatures for inputs that will
> fund the 1,000,000 WJT payout.
> 2. Alice signs its inputs that will fund the 10,000 WJT premium.
> 3. Alice broadacasts the completely signed funding tx.
>
> Alice is the one responsible for broadcasting the funding tx.
>
> If Bob stalls, it is not a Bob side option (i.e. Bob cannot stall then
> continue the protocol when the exchange rate moves to its favor) as Alice
> can refuse to sign and broadcast the funding tx once it has decided Bob is
> trolling it, thus Bob cannot force Alice to perform.
>
> If Alice stalls, Bob can double-spend one of its inputs at a low feerate.
> This either aborts the protocol, or if Alice then broadcasts the funding
> tx at the pre-agreed feerate and it is confirmed, the premium is now
> already paid to Bob.
>
> Regards,
> ZmnSCPxj
>
> > In this case, Bob can arbitrage by broadcasting this tx after T+24. In
> this way, Bob receives the 10,000WJT, but Alice cannot redeem 1,000,000WJT
> anymore.
> > If the premium (10,000WJT) is also hash-timelocked, Alice can keep
> unraveling the preimage, which makes the atomic swap still premium-free.
> >
> > In the original atomic swap, Bob is incentivised to broadcast his
> funding transaction, otherwise he may miss the opportunity to redeem
> Alice’s asset.
> > Also, Alice will lose nothing regardless of how Bob behaves, because
> Alice locks all her money by hashlock.
> > However, Alice cannot lock the premium using hashlock. This gives Bob
> opportunity to arbitrage Alice’s premium.
> >
> > What is implied here is that, where the premium should go strictly
> depends on where Bob’s asset goes.
> > If the Bitcoin’s timelock can be “relative” (e.g. the timestamp can be
> x+24 where x is the timestamp of the block with this transaction), I think
> this protocol works.
> > Unfortunately, the “x” here is also an external state according to your
> definition.
> >
> > In conclusion, I believe your comments on OP_LOOKUP_OUTPUT reasonable,
> but cannot make sure if the premium mechanism can be implemented by using
> HTLCs.
> >
> > Thanks,
> > Runchao
> >
> > > On 10 Aug 2019, at 12:29 am, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > > Good morning Haoyu LIN et al.,
> > >
> > > > We have investigated this problem in very detail. We analysed how
> profitable the arbitrage can be given the default timelock setting (24/48
> hrs). Our result shows that the profit can be approximately 1% ~ 2.3%,
> which is non-negligible compared with 0.3% for stock market. This can be
> attractive as it's totally risk-free. Please refer to our paper
> https://eprint.iacr.org/2019/896, and the related code
> https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
> > > > Several studies have proposed for solving this problem e.g.,
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
> and https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is
> that, the transaction for the premium needs to be locked with the same
> secret hash but with a flipped payout, i.e. when redeemed with the secret,
> the money goes back to Alice and after timelock, the premium goes to Bob as
> a compensation for Alice not revealing the secret. However, this introduces
> a new problem: Bob can get the premium without paying anything, by never
> participating in.
> > > > To solve this, the transaction verifier needs to know the status of
> an dependent transaction. Unfortunately, Bitcoin does not support the
> stateful transaction functionalities. Therefore, we propose the new opcode:
> OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of
> the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide
> whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT
> <pubkeyhash> OP_EQUALVERIFY`.
> > >
> > > I believe an unsaid principle of SCRIPT opcode design is this:
> > >
> > > -   No SCRIPT opcode can look at anything that is not in the
> transaction spending from the SCRIPT.
> > >
> > > This issue underlies the previous `OP_PUBREF` proposal also.
> > > The reason for this is:
> > >
> > > -   We support a pruning mode, where in only the UTXO set is retained.
> > >     If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as
> `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very early
> historical blocks.
> > >
> > > -   The SCRIPT interpreter is run only once, at the time the
> transaction enters the mempool.
> > >     Thus it cannot get information about the block it is in.
> > >     Instead, the SCRIPT interpreter can have as input only the
> transaction that is attempting to spend the SCRIPT.
> > >
> > >
> > > In any case:
> > >
> > > > However, this introduces a new problem: Bob can get the premium
> without paying anything, by never participating in.
> > >
> > > Premium payment can be made contingent on Bob participating.
> > > Of course, it does mean the premium is paid using the destination coin.
> > > It also requires the destination coin to support SegWit.
> > > Let me explain by this:
> > >
> > > 1.  Alice and Bob agree on swap parameters:
> > >
> > > -   Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
> > > -   Alice will pay 10,000 WJT as premium to Bob.
> > > -   Alice will lock BTC for 48 hours.
> > > -   Bob will lock WJT for 24 hours.
> > > -   The protocol will start at particular time T.
> > >
> > > 2.  Alice generates a preimage+hash.
> > > 3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and
> timelocked at T+48 going to Alice.
> > > 4.  Alice presents above UTXO to Bob.
> > > 5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT
> premium to Bob.
> > > 6.  Alice and Bob generate, but do not sign, a funding transaction
> spending some of Bob coin as well as the premium coin from Alice.
> > >     This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
> > >     The hashlock branch requires not just Alice, but also Bob.
> > >     The timelock branch at T+24 just requires Bob.
> > >
> > > 7.  Alice and Bob generate the claim transaction.
> > >     This spends the funding transaction HTLC output and pays out
> 1,000,000 WJT to Alice and 10,000 WJT to Bob.
> > >
> > > 8.  Alice and Bob sign the claim transaction.
> > >     This does not allow Bob to make the claim transaction valid by
> itself as it still requires the preimage, and at this point, only Alice
> knows the preimage.
> > >
> > > 9.  Alice and Bob sign the funding transaction and broadcast it.
> > > 10.  Alice completes the claim transaction by adding the preimage and
> broadcasts it.
> > > 11.  Bob sees the preimage on the WJT blockchain and claims the BTC
> using the preimage.
> > >
> > > If Bob stalls at step 8, then there is no way to claim the premium, as
> the funding transaction (which is the source of the claim transaction that
> pays the premium) is not valid yet.
> > > After step 9, Bob has been forced to participate and cannot back out
> and claim the premium only.
> > > This is basically this proposal:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html
> > > In addition, if you really want the premium to be denominated in BTC,
> I have a more complicated ritual:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
> > > The described ritual only sets up the American Call Option, but by the
> time it has been set up, the premium has been paid already and the rest of
> the execution is claiming the American Call Option.
> > > Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
> > > Regards,
> > > ZmnSCPxj
>
>
>

[-- Attachment #2: Type: text/html, Size: 11392 bytes --]

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Runchao Han]

[-- Attachment #1: Type: text/plain, Size: 13351 bytes --]

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’s 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.

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’s 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’m not sure how do you define “Alice stalls”. 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.

Second, I’m 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.

Third, let’s optimistically assume Bob can close this payment channel without Alice’s consent.
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.

In conclusion, Alice’s optionality is not free when she exercises this option, but is free when she aborts this option.



## What will happen if Alice is responsible for broadcasting both funding txs

If Alice is responsible for broadcasting both txs, Alice can always abort the swap for free, regardless of how the protocol is designed.
Basically, Bob officially participates in the swap by signing the WJT tx.
After Bob participating, if Alice hopes to abort the swap, she can just withhold the WJT tx.

In the original Atomic Swap, Bob participates in the swap by signing and broadcasting the WJT tx, and Alice cannot withhold Bob’s participation.
However, if Alice is responsible for broadcasting Bob’s WJT tx, Alice can withhold Bob’s participation by withholding the WJT tx.

Therefore, I think for Atomic Swap protocol design, Bob should be responsible for broadcasting the WJT tx, otherwise the protocol is impossible to be fair to Bob.



Again, sorry for the ambiguity introduced in our last email, and we look forward to hearing from you.

Thanks,
Runchao


> On 10 Aug 2019, at 11:01 pm, Runchao Han <runchao.han@monash.edu> wrote:
> 
> If I remember it right, Alice first signs the WJT transaction, sends it to Bob, then Bob signs it and makes this transaction valid.
> 
> If so, there are two problems.
> First, Bob gets the valid tx first, and he can choose not to send it to Alice.
> Second, even if Bob honestly sends Alice this tx, Alice cannot fully control when to broadcast this to, as Bob also has this transaction.
> 
> If Bob first signs then Alice signs, Alice still has optionality, as she can choose whether to publish this tx and preimage.
> 
> Runchao
> 
> On Sat, Aug 10, 2019 at 10:50 PM ZmnSCPxj <ZmnSCPxj@protonmail.com <mailto:ZmnSCPxj@protonmail.com>> wrote:
> Good morning Runchao,
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, August 10, 2019 1:44 PM, Runchao Han <runchao.han@monash.edu <mailto:runchao.han@monash.edu>> wrote:
> 
> > Hi ZmnSCPxj,
> >
> > Thanks for your reply.
> >
> > I agree with your opinions about OP_LOOKUP_OUTPUT.
> > Indeed, the pruning mechanism renders this opcode unrealistic for some nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of verifying this tx.
> >
> > However, I’m concerning of some security issues of your mentioned protocol (Alice pays the premium contingently on Bob participating).
> > If I understand it right, Alice and Bob should create a payment channel, and mutually construct the funding transaction that “Alice pays Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT”, where the time lock is T+24.
> > Here, Bob is responsible for broadcasting this tx after confirming Alice’s funding transaction on BTC blockchain.
> 
> No, Bob is not.
> 
> The signature exchange for the WJT-side funding tx is done by:
> 
> 1. Alice waits for Bob to provide all its signatures for inputs that will fund the 1,000,000 WJT payout.
> 2. Alice signs its inputs that will fund the 10,000 WJT premium.
> 3. Alice broadacasts the completely signed funding tx.
> 
> Alice is the one responsible for broadcasting the funding tx.
> 
> If Bob stalls, it is not a Bob side option (i.e. Bob cannot stall then continue the protocol when the exchange rate moves to its favor) as Alice can refuse to sign and broadcast the funding tx once it has decided Bob is trolling it, thus Bob cannot force Alice to perform.
> 
> If Alice stalls, Bob can double-spend one of its inputs at a low feerate.
> This either aborts the protocol, or if Alice then broadcasts the funding tx at the pre-agreed feerate and it is confirmed, the premium is now already paid to Bob.
> 
> Regards,
> ZmnSCPxj
> 
> > In this case, Bob can arbitrage by broadcasting this tx after T+24. In this way, Bob receives the 10,000WJT, but Alice cannot redeem 1,000,000WJT anymore.
> > If the premium (10,000WJT) is also hash-timelocked, Alice can keep unraveling the preimage, which makes the atomic swap still premium-free.
> >
> > In the original atomic swap, Bob is incentivised to broadcast his funding transaction, otherwise he may miss the opportunity to redeem Alice’s asset.
> > Also, Alice will lose nothing regardless of how Bob behaves, because Alice locks all her money by hashlock.
> > However, Alice cannot lock the premium using hashlock. This gives Bob opportunity to arbitrage Alice’s premium.
> >
> > What is implied here is that, where the premium should go strictly depends on where Bob’s asset goes.
> > If the Bitcoin’s timelock can be “relative” (e.g. the timestamp can be x+24 where x is the timestamp of the block with this transaction), I think this protocol works.
> > Unfortunately, the “x” here is also an external state according to your definition.
> >
> > In conclusion, I believe your comments on OP_LOOKUP_OUTPUT reasonable, but cannot make sure if the premium mechanism can be implemented by using HTLCs.
> >
> > Thanks,
> > Runchao
> >
> > > On 10 Aug 2019, at 12:29 am, ZmnSCPxj ZmnSCPxj@protonmail.com <mailto:ZmnSCPxj@protonmail.com> wrote:
> > > Good morning Haoyu LIN et al.,
> > >
> > > > We have investigated this problem in very detail. We analysed how profitable the arbitrage can be given the default timelock setting (24/48 hrs). Our result shows that the profit can be approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for stock market. This can be attractive as it's totally risk-free. Please refer to our paper https://eprint.iacr.org/2019/896 <https://eprint.iacr.org/2019/896>, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap <https://github.com/HAOYUatHZ/fair-atomic-swap> if interested.
> > > > Several studies have proposed for solving this problem e.g., http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ <http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/> and https://coblox.tech/docs/financial_crypto19.pdf <https://coblox.tech/docs/financial_crypto19.pdf>. Their basic idea is that, the transaction for the premium needs to be locked with the same secret hash but with a flipped payout, i.e. when redeemed with the secret, the money goes back to Alice and after timelock, the premium goes to Bob as a compensation for Alice not revealing the secret. However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
> > > > To solve this, the transaction verifier needs to know the status of an dependent transaction. Unfortunately, Bitcoin does not support the stateful transaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide whether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.
> > >
> > > I believe an unsaid principle of SCRIPT opcode design is this:
> > >
> > > -   No SCRIPT opcode can look at anything that is not in the transaction spending from the SCRIPT.
> > >
> > > This issue underlies the previous `OP_PUBREF` proposal also.
> > > The reason for this is:
> > >
> > > -   We support a pruning mode, where in only the UTXO set is retained.
> > >     If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very early historical blocks.
> > >
> > > -   The SCRIPT interpreter is run only once, at the time the transaction enters the mempool.
> > >     Thus it cannot get information about the block it is in.
> > >     Instead, the SCRIPT interpreter can have as input only the transaction that is attempting to spend the SCRIPT.
> > >
> > >
> > > In any case:
> > >
> > > > However, this introduces a new problem: Bob can get the premium without paying anything, by never participating in.
> > >
> > > Premium payment can be made contingent on Bob participating.
> > > Of course, it does mean the premium is paid using the destination coin.
> > > It also requires the destination coin to support SegWit.
> > > Let me explain by this:
> > >
> > > 1.  Alice and Bob agree on swap parameters:
> > >
> > > -   Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
> > > -   Alice will pay 10,000 WJT as premium to Bob.
> > > -   Alice will lock BTC for 48 hours.
> > > -   Bob will lock WJT for 24 hours.
> > > -   The protocol will start at particular time T.
> > >
> > > 2.  Alice generates a preimage+hash.
> > > 3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and timelocked at T+48 going to Alice.
> > > 4.  Alice presents above UTXO to Bob.
> > > 5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT premium to Bob.
> > > 6.  Alice and Bob generate, but do not sign, a funding transaction spending some of Bob coin as well as the premium coin from Alice.
> > >     This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
> > >     The hashlock branch requires not just Alice, but also Bob.
> > >     The timelock branch at T+24 just requires Bob.
> > >
> > > 7.  Alice and Bob generate the claim transaction.
> > >     This spends the funding transaction HTLC output and pays out 1,000,000 WJT to Alice and 10,000 WJT to Bob.
> > >
> > > 8.  Alice and Bob sign the claim transaction.
> > >     This does not allow Bob to make the claim transaction valid by itself as it still requires the preimage, and at this point, only Alice knows the preimage.
> > >
> > > 9.  Alice and Bob sign the funding transaction and broadcast it.
> > > 10.  Alice completes the claim transaction by adding the preimage and broadcasts it.
> > > 11.  Bob sees the preimage on the WJT blockchain and claims the BTC using the preimage.
> > >
> > > If Bob stalls at step 8, then there is no way to claim the premium, as the funding transaction (which is the source of the claim transaction that pays the premium) is not valid yet.
> > > After step 9, Bob has been forced to participate and cannot back out and claim the premium only.
> > > This is basically this proposal: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html>
> > > In addition, if you really want the premium to be denominated in BTC, I have a more complicated ritual: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html>
> > > The described ritual only sets up the American Call Option, but by the time it has been set up, the premium has been paid already and the rest of the execution is claiming the American Call Option.
> > > Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
> > > Regards,
> > > ZmnSCPxj
> 
> 


[-- Attachment #2: Type: text/html, Size: 18387 bytes --]

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj]

Good morning Runchao,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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’s 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’s 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’m not sure how do you define “Alice stalls”. 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’m 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’s optimistically assume Bob can close this payment channel without Alice’s 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

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Lloyd Fournier]

[-- Attachment #1: Type: text/plain, Size: 9235 bytes --]

Hello Runchao and ZmnSCPxj,

I think we can simplify the explanation here by not using joint signatures
and payment channel like constructions. ZmnSCPxj's more complex
construction could be more dynamic and practical in some settings but at
least for me it gets in the way of capturing how this relatively simple
idea works.
Here's my attempt at distilling the idea:

Step 0: Alice and Bob negotiate the parameters (timeouts, refund/redeem
pubkeys, the collateral amounts and inputs/outputs for the WTJ-HTLC)

=== Step 1 ===
 Alice signs and broadcasts the BTC-HTLC and sends signature(s) on her
input(s) to the WJT-HLTC to Bob.
Note:
1. She does not need to wait for the BTC-HTLC to confirm before she sends
her signature(s).
2. There is no benefit to Alice in delaying at this point

=== Step 2 ===
Upon receiving Alice's input signature(s) and seeing the BTC-HTLC with
sufficient confirmations, Bob completes the transaction by supplying his
own signature(s) and broadcasts it.

Note:
1. Bob's ability to delay at this point shouldn't be considered an option.
Alice may withdraw her offer by double spending her one of her inputs to
the WTJ-HTLC. Alice's ability to cancel the offer and take back BTC after
the timeout proves there is no option (options cannot be cancelled)
2. In this plain construction Alice should cancel promptly (if she doesn't
see the WTJ-HTLC within the next 1 or 2 blocks for example)
3. You could even extend this protocol  to specify that Bob send signatures
on his inputs the WTJ-HTLC immediately to Alice. If he refuses Alice can
cancel within a second or two.

=== Step 3 ===
Upon seeing the WTJ-HTLC get sufficient confirmations, Alice takes the
funds (including her collateral back) by revealing the secret.

Note:
1. If she doesn't redeem the HTLC she loses her collateral. Assuming the
loss of the collateral overwhelms any gain she could experience from the
delaying her decision and she operates in her own financial interest she
redeems it immediately.

Step 4 is as usual.

At each step there is no unfair advantage to either party (at least if we
idealise the blockchains somewhat and assume that neither party can
influence which transactions get into which block etc etc).

ZmnSCPxj,

Thanks for continuing to spread this idea!
I'm still not sure about your "two hashes" approach to lightning but I hope
to get to the bottom of it soon by describing how I think it should work
more formally somewhere. Will post to lightning-dev when I do :)

LL

On Mon, Aug 12, 2019 at 4:06 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Runchao,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 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’s 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’s 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’m not sure how do you define “Alice stalls”. 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’m 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’s optimistically assume Bob can close this payment channel
> without Alice’s 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 10454 bytes --]

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Runchao Han]

[-- Attachment #1: Type: text/plain, Size: 7760 bytes --]

Hi ZmnSCPxj,

Thanks for your explanation. It’s 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 “whale transaction” works here. Will this introduce some double-spending variants?

Third, assume Bob doesn’t 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’s 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.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, August 12, 2019 11:19 AM, Runchao Han <runchao.han@monash.edu <mailto: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’s 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’s 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’m not sure how do you define “Alice stalls”. 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’m 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’s optimistically assume Bob can close this payment channel without Alice’s 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


[-- Attachment #2: Type: text/html, Size: 48410 bytes --]

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj]

Good morning Runchao,

> Thanks for your explanation. It’s 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.

I am uncertain what you refer to by the "WJT payment channel".
What I am proposing here is there is a single funding transaction that will output to a modified HTLC where hashlock is Alice+Bob while Timelock is Bob, spending inputs from both Alice (10,000 WJT) and Bob (1,000,000 WJT).

So let me rephrase the nearest question as I understand it:

* What happens when Alice broadcasts the funding tx at the same time as Bob double-spends his 1,000,000 WJT input?

As both transactions spend the same input (the 1,000,000 WJT from Bob) then what happens depends on the miners.
The miners decide which transaction is valid and gets confirmed onchain.

That is the reason why we need large timeouts in the HTLC constructions: we need to give enough time, not only to react to transactions being published, but also to have transactions become deeply confirmed.
Otherwise we could have made the timelocks so small as to be practically worthless as an option.

>
> 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 “whale transaction” works here. Will this introduce some double-spending variants?

Yes, that is why Alice and Bob need to wait for deep confirmations of the transactions involved.
Once deeply confirmed, they now know which way the protocol went and can safely perform the next step (or abort the protocol).

>
> Third, assume Bob doesn’t 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.

It does not matter, because Bob doing so *prevents* the option.

Think of it this way:

Suppose we were to meet face-to-face, in order for you to sell me an options contract.
Now, suppose I agree to buy the options contract.
But, while filling up the paperwork, you change your mind.

Until the paperwork is properly filled up, the option does not exist.
Thus, until the paperwork is properly filled,, the option is not exerciseable (and I should not pay anything to you since you did not push through with completing the option).

This is similar in effect.


>
> 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’s your opinion on the payment channel suitable for this scenario?

Any payment channel has the problem of non-cooperation by the other side.
I already mentioned this before.
Again, this is always an issue regardless of the existence or non-existence of an `OP_LOOKUP_OUTPUT`: you have to execute onchain activity anyway in order to enforce anything offchain in case of non-cooperation, and adding in the possibility of various attacks makes it more likely that non-cooperation occurs.
It is the main reason why I think it is difficult to make Lightning support multiple currencies on the same network.

Usability can always be improved by proper software design; you do not worry about what voltage levels need to be transmitted over the wires in order to transmit your email to me, yet you probably consider your email client quite usable.

Regards,
ZmnSCPxj