From 3f571ce717179134a9d7185ca8413553f2e271e0 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Thu, 9 Mar 2017 14:23:41 -0800 Subject: [PATCH 1/8] Add draft of XCAT ZIP --- drafts/arcalinea-xcat/draft.rst | 74 +++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 drafts/arcalinea-xcat/draft.rst diff --git a/drafts/arcalinea-xcat/draft.rst b/drafts/arcalinea-xcat/draft.rst new file mode 100644 index 00000000..dfd3f068 --- /dev/null +++ b/drafts/arcalinea-xcat/draft.rst @@ -0,0 +1,74 @@ +**Title:** Cross-chain Atomic Transaction Standards + +**Author:** Jay Graber + +**Status:** Active + +**Category:** Informational + +**Created:** 2017-03-08 + +Abstract +=========== + +This is an Informational ZIP describing a proposed specification for a standardized protocol for performing cross-chain atomic transactions (XCAT) between Zcash and Bitcoin, or other Bitcoin-derived cryptocurrencies. + +Motivation +=========== + +A well-defined standard for performing cross-chain transactions would improve the liquidity of cryptocurrencies and be useful for third-party services, such as decentralized exchanges. + +Specification +=============== + +The proposed protocol for XCAT is a set of hash time-locked contracts across both chains, created by two parties who wish to do a cross-chain exchange. + +To perform an exchange, both parties need to have the public keys of the other, on both chains. The party that wishes to initiate the exchange (the "seller") constructs two hash time-locked contracts by generating pay-to-script-hash (P2SH) addresses using the XCAT protocol and the public key of their counterparty (the "buyer"). + +For the purposes of this example, the seller initiating the exchange will be named "Alice", and the buyer agreeing to complete the exchange will be named "Bob". + +Alice wishes to initiate an XCAT exchange from Bitcoin to Zcash. She chooses a random number R, hashes it, and creates a P2SH address on the Zcash blockchain using her and Bob's public keys, that she will wait for Bob to fund with the amount he wants to trade. (Agreement on the amount to trade and exchange rate is outside the scope of this protocol, and could be determined out-of-band, or within the user interface of an application using XCAT under the hood) + +The script in the P2SH address takes the following form: + +:: + + OP_IF + [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 + OP_ELSE + CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 + OP_ENDIF + OP_EQUALVERIFY + OP_CHECKSIG + +There are two scenarios for spending funds from this P2SH address. The first is a successful atomic swap which gives Alice the money she asked for, and gives Bob access to the secret R which he can use to redeem his funds on the other blockchain. The second is a fail case which refunds Bob's money if Alice does not follow through. + +1. Success case: Alice spends the funds sent to the address, revealing the random number R she hashed to create the script in the process. +2. Fail case: Alice does not spend the funds sent to the address within the timeout period, so Bob sends his funds back to himself, canceling the transaction. + +At the same time that Alice creates this P2SH address on the Zcash blockchain, she must also create a P2SH address on the Bitcoin blockchain, which she funds herself with the amount of BTC she wants to trade out of. + +The script for this second transaction takes the following form: + +:: + + OP_IF + [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 + OP_ELSE + CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 + OP_ENDIF + OP_EQUALVERIFY + OP_CHECKSIG + +The two scenarios for spending funds from this second P2SH address are as follows: + +1. Success case: Bob uses R to spend the funds from this P2SH address, as Alice has already revealed R to Bob in the process of spending from the P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain atomic transaction is now complete, and both parties have the funds they requested. +2. Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction. + +The time-lock period on the first transaction must be significantly shorter than the time-lock on the second, in order to give Bob enough time to redeem his funds on the other blockchain using the secret R provided by Alice. If there were an insufficient delay between the first and second timeouut period, Alice could potentially spend Bob's funds at the last minute, and then quickly refund herself before Bob had a chance to redeem his portion using the R she reveals. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange. + + +Rationale +=========== + +Users are free to come up with their own protocols for cross-chain atomic swaps, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality. From bb8dc9acbac49c36c4aadffa15ca210bc3cc836c Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 27 Mar 2017 15:22:21 -0700 Subject: [PATCH 2/8] Add to section on timeout periods --- drafts/arcalinea-xcat/draft.rst | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drafts/arcalinea-xcat/draft.rst b/drafts/arcalinea-xcat/draft.rst index dfd3f068..48f4ed04 100644 --- a/drafts/arcalinea-xcat/draft.rst +++ b/drafts/arcalinea-xcat/draft.rst @@ -36,7 +36,7 @@ The script in the P2SH address takes the following form: OP_IF [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_ELSE - CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 + CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG @@ -55,7 +55,7 @@ The script for this second transaction takes the following form: OP_IF [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_ELSE - CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 + CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG @@ -65,10 +65,21 @@ The two scenarios for spending funds from this second P2SH address are as follow 1. Success case: Bob uses R to spend the funds from this P2SH address, as Alice has already revealed R to Bob in the process of spending from the P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain atomic transaction is now complete, and both parties have the funds they requested. 2. Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction. -The time-lock period on the first transaction must be significantly shorter than the time-lock on the second, in order to give Bob enough time to redeem his funds on the other blockchain using the secret R provided by Alice. If there were an insufficient delay between the first and second timeouut period, Alice could potentially spend Bob's funds at the last minute, and then quickly refund herself before Bob had a chance to redeem his portion using the R she reveals. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange. +Timeout Periods +------------------ + +Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT: + +**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction which allows the other party to use the revealed R, in order to give them enough time to redeem their funds using R. + +For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals. + +Note that using long time-locks in the P2SH scripts does not necessarily mean that the transactions themselves will take a long time. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange. + +**Block times** - The protection provided by the timeout period must take into account relative block times between the two blockchains. Rationale =========== -Users are free to come up with their own protocols for cross-chain atomic swaps, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality. +Users are free to come up with their own protocols for cross-chain atomic transactions, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality. From cb5a29f35570328b6ff52ac868de5e298240a3e8 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 8 Jan 2018 19:32:53 -0800 Subject: [PATCH 3/8] Change wording --- drafts/arcalinea-xcat/draft.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/arcalinea-xcat/draft.rst b/drafts/arcalinea-xcat/draft.rst index 48f4ed04..0b818497 100644 --- a/drafts/arcalinea-xcat/draft.rst +++ b/drafts/arcalinea-xcat/draft.rst @@ -70,7 +70,7 @@ Timeout Periods Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT: -**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction which allows the other party to use the revealed R, in order to give them enough time to redeem their funds using R. +**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction in which the other party uses the revealed R, in order to give them enough time to make use of R to redeem their funds. For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals. From 5d9e790e17ec56ba5319df59658c8fb198a2fefd Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 15 Sep 2020 14:20:38 +0100 Subject: [PATCH 4/8] Move Jay's XCAT draft to be ZIP 300. Signed-off-by: Daira Hopwood --- drafts/arcalinea-xcat/draft.rst => zip-0300.rst | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename drafts/arcalinea-xcat/draft.rst => zip-0300.rst (100%) diff --git a/drafts/arcalinea-xcat/draft.rst b/zip-0300.rst similarity index 100% rename from drafts/arcalinea-xcat/draft.rst rename to zip-0300.rst From 14630b1c449d9aed909fe2f9e730bad92713d579 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 15 Sep 2020 14:26:19 +0100 Subject: [PATCH 5/8] ZIP 300: reformat preamble and headings. Signed-off-by: Daira Hopwood --- zip-0300.rst | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/zip-0300.rst b/zip-0300.rst index 0b818497..2b37bd2b 100644 --- a/zip-0300.rst +++ b/zip-0300.rst @@ -1,25 +1,28 @@ -**Title:** Cross-chain Atomic Transaction Standards +:: -**Author:** Jay Graber + ZIP: 300 + Title: Cross-chain Atomic Transactions + Owners: Daira Hopwood + Original-Authors: Jay Graber + Status: Proposed + Category: Informational + Created: 2017-03-08 + License: MIT + Pull-Request: -**Status:** Active - -**Category:** Informational - -**Created:** 2017-03-08 Abstract -=========== +======== This is an Informational ZIP describing a proposed specification for a standardized protocol for performing cross-chain atomic transactions (XCAT) between Zcash and Bitcoin, or other Bitcoin-derived cryptocurrencies. Motivation -=========== +========== A well-defined standard for performing cross-chain transactions would improve the liquidity of cryptocurrencies and be useful for third-party services, such as decentralized exchanges. Specification -=============== +============= The proposed protocol for XCAT is a set of hash time-locked contracts across both chains, created by two parties who wish to do a cross-chain exchange. @@ -66,7 +69,7 @@ The two scenarios for spending funds from this second P2SH address are as follow 2. Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction. Timeout Periods ------------------- +--------------- Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT: @@ -80,6 +83,6 @@ Note that using long time-locks in the P2SH scripts does not necessarily mean th Rationale -=========== +========= Users are free to come up with their own protocols for cross-chain atomic transactions, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality. From 49b7eae44f81b7c426388d131a4d14b1fd3909dd Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 15 Sep 2020 14:33:11 +0100 Subject: [PATCH 6/8] ZIP 300: formatting changes. Signed-off-by: Daira Hopwood --- zip-0300.rst | 106 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 87 insertions(+), 19 deletions(-) diff --git a/zip-0300.rst b/zip-0300.rst index 2b37bd2b..4c1c5583 100644 --- a/zip-0300.rst +++ b/zip-0300.rst @@ -14,23 +14,44 @@ Abstract ======== -This is an Informational ZIP describing a proposed specification for a standardized protocol for performing cross-chain atomic transactions (XCAT) between Zcash and Bitcoin, or other Bitcoin-derived cryptocurrencies. +This is an Informational ZIP describing a proposed specification for a +standardized protocol for performing cross-chain atomic transactions +(XCAT) between Zcash and Bitcoin, or other Bitcoin-derived +cryptocurrencies. + Motivation ========== -A well-defined standard for performing cross-chain transactions would improve the liquidity of cryptocurrencies and be useful for third-party services, such as decentralized exchanges. +A well-defined standard for performing cross-chain transactions would +improve the liquidity of cryptocurrencies and be useful for third-party +services, such as decentralized exchanges. + Specification ============= -The proposed protocol for XCAT is a set of hash time-locked contracts across both chains, created by two parties who wish to do a cross-chain exchange. +The proposed protocol for XCAT is a set of hash time-locked contracts +across both chains, created by two parties who wish to do a cross-chain +exchange. -To perform an exchange, both parties need to have the public keys of the other, on both chains. The party that wishes to initiate the exchange (the "seller") constructs two hash time-locked contracts by generating pay-to-script-hash (P2SH) addresses using the XCAT protocol and the public key of their counterparty (the "buyer"). +To perform an exchange, both parties need to have the public keys of the +other, on both chains. The party that wishes to initiate the exchange +(the "seller") constructs two hash time-locked contracts by generating +pay-to-script-hash (P2SH) addresses using the XCAT protocol and the +public key of their counterparty (the "buyer"). -For the purposes of this example, the seller initiating the exchange will be named "Alice", and the buyer agreeing to complete the exchange will be named "Bob". +For the purposes of this example, the seller initiating the exchange will +be named "Alice", and the buyer agreeing to complete the exchange will be +named "Bob". -Alice wishes to initiate an XCAT exchange from Bitcoin to Zcash. She chooses a random number R, hashes it, and creates a P2SH address on the Zcash blockchain using her and Bob's public keys, that she will wait for Bob to fund with the amount he wants to trade. (Agreement on the amount to trade and exchange rate is outside the scope of this protocol, and could be determined out-of-band, or within the user interface of an application using XCAT under the hood) +Alice wishes to initiate an XCAT exchange from Bitcoin to Zcash. She +chooses a random number R, hashes it, and creates a P2SH address on the +Zcash blockchain using her and Bob's public keys, that she will wait for +Bob to fund with the amount he wants to trade. (Agreement on the amount +to trade and exchange rate is outside the scope of this protocol, and +could be determined out-of-band, or within the user interface of an +application using XCAT under the hood) The script in the P2SH address takes the following form: @@ -44,12 +65,22 @@ The script in the P2SH address takes the following form: OP_EQUALVERIFY OP_CHECKSIG -There are two scenarios for spending funds from this P2SH address. The first is a successful atomic swap which gives Alice the money she asked for, and gives Bob access to the secret R which he can use to redeem his funds on the other blockchain. The second is a fail case which refunds Bob's money if Alice does not follow through. +There are two scenarios for spending funds from this P2SH address. The +first is a successful atomic swap which gives Alice the money she asked +for, and gives Bob access to the secret R which he can use to redeem his +funds on the other blockchain. The second is a fail case which refunds +Bob's money if Alice does not follow through. -1. Success case: Alice spends the funds sent to the address, revealing the random number R she hashed to create the script in the process. -2. Fail case: Alice does not spend the funds sent to the address within the timeout period, so Bob sends his funds back to himself, canceling the transaction. +1. Success case: Alice spends the funds sent to the address, revealing + the random number R she hashed to create the script in the process. +2. Fail case: Alice does not spend the funds sent to the address within + the timeout period, so Bob sends his funds back to himself, canceling + the transaction. -At the same time that Alice creates this P2SH address on the Zcash blockchain, she must also create a P2SH address on the Bitcoin blockchain, which she funds herself with the amount of BTC she wants to trade out of. +At the same time that Alice creates this P2SH address on the Zcash +blockchain, she must also create a P2SH address on the Bitcoin +blockchain, which she funds herself with the amount of BTC she wants to +trade out of. The script for this second transaction takes the following form: @@ -63,26 +94,63 @@ The script for this second transaction takes the following form: OP_EQUALVERIFY OP_CHECKSIG -The two scenarios for spending funds from this second P2SH address are as follows: +The two scenarios for spending funds from this second P2SH address are as +follows: -1. Success case: Bob uses R to spend the funds from this P2SH address, as Alice has already revealed R to Bob in the process of spending from the P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain atomic transaction is now complete, and both parties have the funds they requested. -2. Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction. +1. Success case: Bob uses R to spend the funds from this P2SH address, as + Alice has already revealed R to Bob in the process of spending from the + P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain + atomic transaction is now complete, and both parties have the funds they + requested. + +2. Fail case: Bob has not followed through on his part of the trade + within the timeout period, so Alice sends her funds back to herself, + canceling the transaction. Timeout Periods --------------- -Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT: +Having timeout periods on both transactions allows the XCAT protocol to +work by enabling refunds in case a counterparty misbehaves. The example +above uses a timeout period of 24 hours for the first transaction and 48 +hours for the second, but these are simply suggestions. Actual timeout +periods should be considered to be variables that depend on the following +factors for any given implementation of XCAT: -**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction in which the other party uses the revealed R, in order to give them enough time to make use of R to redeem their funds. +Duration +'''''''' -For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals. +The time-lock period on the transaction in which the initiating party +reveals R must be significantly shorter than the time-lock period on the +second transaction in which the other party uses the revealed R, in order +to give them enough time to make use of R to redeem their funds. -Note that using long time-locks in the P2SH scripts does not necessarily mean that the transactions themselves will take a long time. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange. +For example, once Alice reveals R by spending what Bob sent to her P2SH +address, Bob must have enough time to use R to redeem his funds on the +other blockchain before Alice can be allowed to refund herself. If there +were an insufficient time delay between the first and second timeout +periods, Alice could potentially spend Bob's funds at the last minute, +then quickly refund herself on the other blockchain before Bob gets a +chance to redeem his portion using the R she reveals. -**Block times** - The protection provided by the timeout period must take into account relative block times between the two blockchains. +Note that using long time-locks in the P2SH scripts does not necessarily +mean that the transactions themselves will take a long time. If both +parties are immediately responsive and execute their trades in a timely +manner, providing the correct information, the full cross-chain atomic +trade can happen quickly. The full duration of the timeout period for +each transaction only elapses in the fail case, when either Alice or Bob +defaults on their agreement to exchange. + +Block times +''''''''''' + +The protection provided by the timeout period must take into account +relative block times between the two blockchains. Rationale ========= -Users are free to come up with their own protocols for cross-chain atomic transactions, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality. +Users are free to come up with their own protocols for cross-chain atomic +transactions, but having a well-defined protocol would aid adoption and +support third-party services wishing to provide such functionality. From e9f7b48e41df55ed7dd0a730e81558ad6e7c3fe1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 15 Sep 2020 14:39:32 +0100 Subject: [PATCH 7/8] ZIP 300: add Status section. Signed-off-by: Daira Hopwood --- zip-0300.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/zip-0300.rst b/zip-0300.rst index 4c1c5583..c42d054d 100644 --- a/zip-0300.rst +++ b/zip-0300.rst @@ -20,6 +20,14 @@ standardized protocol for performing cross-chain atomic transactions cryptocurrencies. +Status +====== + +This proposal only supports transparent cross-chain swaps and relies on +the scripting system inherited from Bitcoin. At the time of writing +(September 2020), it has not achieved widespread adoption. + + Motivation ========== From 689e5a9501fe23800cb1f5f63e4eb49b9a71bea2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 15 Sep 2020 14:39:44 +0100 Subject: [PATCH 8/8] ZIP 300: generate HTML and index. Signed-off-by: Daira Hopwood --- README.rst | 1 + index.html | 1 + zip-0300.html | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+) create mode 100644 zip-0300.html diff --git a/README.rst b/README.rst index ffe49c3d..c27ac34e 100644 --- a/README.rst +++ b/README.rst @@ -98,6 +98,7 @@ Index of ZIPs 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Implemented (zcashd) 252 Deployment of the NU5 Network Upgrade Reserved + 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Reserved 303 Sprout Payment Disclosure Reserved diff --git a/index.html b/index.html index 824b2302..e0e3a246 100644 --- a/index.html +++ b/index.html @@ -71,6 +71,7 @@ 250 Deployment of the Heartwood Network Upgrade Final 251 Deployment of the Canopy Network Upgrade Implemented (zcashd) 252 Deployment of the NU5 Network Upgrade Reserved + 300 Cross-chain Atomic Transactions Proposed 301 Zcash Stratum Protocol Final 302 Standardized Memo Field Format Reserved 303 Sprout Payment Disclosure Reserved diff --git a/zip-0300.html b/zip-0300.html new file mode 100644 index 00000000..601af2b5 --- /dev/null +++ b/zip-0300.html @@ -0,0 +1,76 @@ + + + + ZIP 300: Cross-chain Atomic Transactions + + + +
+ 
ZIP: 300
+Title: Cross-chain Atomic Transactions
+Owners: Daira Hopwood <daira@electriccoin.co>
+Original-Authors: Jay Graber
+Status: Proposed
+Category: Informational
+Created: 2017-03-08
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/123>
+

Abstract

+

This is an Informational ZIP describing a proposed specification for a standardized protocol for performing cross-chain atomic transactions (XCAT) between Zcash and Bitcoin, or other Bitcoin-derived cryptocurrencies.

+
+

Status

+

This proposal only supports transparent cross-chain swaps and relies on the scripting system inherited from Bitcoin. At the time of writing (September 2020), it has not achieved widespread adoption.

+
+

Motivation

+

A well-defined standard for performing cross-chain transactions would improve the liquidity of cryptocurrencies and be useful for third-party services, such as decentralized exchanges.

+
+

Specification

+

The proposed protocol for XCAT is a set of hash time-locked contracts across both chains, created by two parties who wish to do a cross-chain exchange.

+

To perform an exchange, both parties need to have the public keys of the other, on both chains. The party that wishes to initiate the exchange (the "seller") constructs two hash time-locked contracts by generating pay-to-script-hash (P2SH) addresses using the XCAT protocol and the public key of their counterparty (the "buyer").

+

For the purposes of this example, the seller initiating the exchange will be named "Alice", and the buyer agreeing to complete the exchange will be named "Bob".

+

Alice wishes to initiate an XCAT exchange from Bitcoin to Zcash. She chooses a random number R, hashes it, and creates a P2SH address on the Zcash blockchain using her and Bob's public keys, that she will wait for Bob to fund with the amount he wants to trade. (Agreement on the amount to trade and exchange rate is outside the scope of this protocol, and could be determined out-of-band, or within the user interface of an application using XCAT under the hood)

+

The script in the P2SH address takes the following form:

+ 
OP_IF
+    [HASHOP] <hash digest of R> OP_EQUALVERIFY OP_DUP OP_HASH160 <Alice's pubkey hash>
+OP_ELSE
+    <time-out duration (24 hours)> CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <Bob's pubkey hash>
+OP_ENDIF
+OP_EQUALVERIFY
+OP_CHECKSIG
+

There are two scenarios for spending funds from this P2SH address. The first is a successful atomic swap which gives Alice the money she asked for, and gives Bob access to the secret R which he can use to redeem his funds on the other blockchain. The second is a fail case which refunds Bob's money if Alice does not follow through.

+
    +
  1. Success case: Alice spends the funds sent to the address, revealing the random number R she hashed to create the script in the process.
    2. +
  2. Fail case: Alice does not spend the funds sent to the address within the timeout period, so Bob sends his funds back to himself, canceling the transaction.
    3. +
+

At the same time that Alice creates this P2SH address on the Zcash blockchain, she must also create a P2SH address on the Bitcoin blockchain, which she funds herself with the amount of BTC she wants to trade out of.

+

The script for this second transaction takes the following form:

+ 
OP_IF
+    [HASHOP] <hash digest of R> OP_EQUALVERIFY OP_DUP OP_HASH160 <Bob's pubkey hash>
+OP_ELSE
+    <time-out duration (48 hours)> CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <Alice's pubkey hash>
+OP_ENDIF
+OP_EQUALVERIFY
+OP_CHECKSIG
+

The two scenarios for spending funds from this second P2SH address are as follows:

+
    +
  1. Success case: Bob uses R to spend the funds from this P2SH address, as Alice has already revealed R to Bob in the process of spending from the P2SH address he sent ZEC to on the Zcash blockchain. The cross-chain atomic transaction is now complete, and both parties have the funds they requested.
    2. +
  2. Fail case: Bob has not followed through on his part of the trade within the timeout period, so Alice sends her funds back to herself, canceling the transaction.
    3. +
+

Timeout Periods

+

Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT:

+

Duration

+

The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction in which the other party uses the revealed R, in order to give them enough time to make use of R to redeem their funds.

+

For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals.

+

Note that using long time-locks in the P2SH scripts does not necessarily mean that the transactions themselves will take a long time. If both parties are immediately responsive and execute their trades in a timely manner, providing the correct information, the full cross-chain atomic trade can happen quickly. The full duration of the timeout period for each transaction only elapses in the fail case, when either Alice or Bob defaults on their agreement to exchange.

+
+

Block times

+

The protection provided by the timeout period must take into account relative block times between the two blockchains.

+
+
+
+

Rationale

+

Users are free to come up with their own protocols for cross-chain atomic transactions, but having a well-defined protocol would aid adoption and support third-party services wishing to provide such functionality.

+
+
+ + \ No newline at end of file