Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
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 wrote: > Good morning Runchao, > > > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, August 10, 2019 1:44 PM, Runchao Han > 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 zmnsc...@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
Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
Good morning Runchao, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, August 10, 2019 1:44 PM, Runchao Han 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 zmnsc...@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 ` > > > OP_LOOKUP_OUTPUT 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
Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
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 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 ` OP_LOOKUP_OUTPUT >> 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
