docs: rfc-0240 XTR-BTC atomic swap #3485
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
philipr-za
reviewed
Oct 25, 2021
SWvheerden
force-pushed
the
sw_btc_xtr_swap
branch
2 times, most recently
from
f9ece9a to
021e6d3
Compare
SWvheerden
changed the title
SWvheerden
force-pushed
the
sw_btc_xtr_swap
branch
2 times, most recently
from
4b0f384 to
fe3cb40
Compare
|
Pretty sure this is not a breaking feature but rather documentation |
SWvheerden
changed the title
delta1
reviewed
Oct 26, 2021
RFC/src/RFC-0240_AtomicSwap.md
Outdated
|
|
||
| ## Description | ||
|
|
||
| Atomic swaps are atomic transactions that allow users to trustlessly exchange different crypto assets and or coins without the use of a central exchange. This makes it much more private and secure to do and swap because no third party is required for this to be secure. Atomic swaps work on the principle of using [Hashed Time Lock Contract](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)(HTLC). In short, it requires some hash pre-image to unlock the contract or the time-lock can be used to reclaim the funds. |
There was a problem hiding this comment.
Suggested change
| Atomic swaps are atomic transactions that allow users to trustlessly exchange different crypto assets and or coins without the use of a central exchange. This makes it much more private and secure to do and swap because no third party is required for this to be secure. Atomic swaps work on the principle of using [Hashed Time Lock Contract](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)(HTLC). In short, it requires some hash pre-image to unlock the contract or the time-lock can be used to reclaim the funds. | |
| Atomic swaps are atomic transactions that allow users to trustlessly exchange different crypto assets and or coins without the use of a central exchange. This makes it much more private because no third party is required. Atomic swaps work by using [Hashed Time Lock Contracts](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)(HTLC). In short, it requires some hash pre-image to unlock the contract, or the time-lock can be used to reclaim the funds. |
RFC/src/RFC-0240_AtomicSwap.md
Outdated
|
|
||
| Atomic swaps are atomic transactions that allow users to trustlessly exchange different crypto assets and or coins without the use of a central exchange. This makes it much more private and secure to do and swap because no third party is required for this to be secure. Atomic swaps work on the principle of using [Hashed Time Lock Contract](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)(HTLC). In short, it requires some hash pre-image to unlock the contract or the time-lock can be used to reclaim the funds. | ||
|
|
||
| In an Atomic swap, both users lock up the funds to be exchanged on their respective chains in an HTLC-type contract. However, the pre-image, or spending secret, of the two contracts is the same, but only one party knows the correct pre-image. When the first HTLC contract is spent, then this publicly reveals the pre-image for the other party to use in spending the second HTLC. If the first HTLC is never spent, the second transaction's time-lock will allow the user to respend the funds back to themselves after a time. |
There was a problem hiding this comment.
Is it "publicly" revealed? It is revealed to the counterparty I presume. Maybe some clarification about "after a time" as well: how much time? is it the length of the time lock? can it only be spent after that?
Suggested change
| In an Atomic swap, both users lock up the funds to be exchanged on their respective chains in an HTLC-type contract. However, the pre-image, or spending secret, of the two contracts is the same, but only one party knows the correct pre-image. When the first HTLC contract is spent, then this publicly reveals the pre-image for the other party to use in spending the second HTLC. If the first HTLC is never spent, the second transaction's time-lock will allow the user to respend the funds back to themselves after a time. | |
| In an Atomic swap, both users lock up the funds to be exchanged on their respective chains in an HTLC-type contract. The pre-image, or spending secret, of the two contracts is the same, but is only known to the initiator. When the first HTLC is spent, then this reveals the pre-image for the other party to use in spending the second HTLC. If the first HTLC is never spent, the second transaction's time-lock will allow the user to spend the funds back to themselves after a time. |
There was a problem hiding this comment.
Yes, its publicly revealed on the blockchain.
But yeah the time is the time lock, and there is no limit to what it should be or what a minimum is. It is completely user-defined.
RFC/src/RFC-0240_AtomicSwap.md
Outdated
|
|
||
| BTC uses a scripting language to enable smart contracts on transactions which enables [atomic swaps](https://tlu.tarilabs.com/protocols/atomic-swaps/AtomicSwaps.html) on the BTC chain. Traditionally [Mimblewimble] coins do not implement scripts, this makes Atomic swaps harder to implement but not impossible. Grin has implemented atomic swaps as a version of a 2-of-2 multi-signature transaction [mimblewimble atomic swaps](https://tlu.tarilabs.com/protocols/grin-protocol-overview/MainReport.html#atomic-swaps). Fortunately, Tari does have scripting with [TariScript] which works a lot like BTC scripts, this makes adding in scripts a lot easier. Because of the same type of scripting, the scripts to both HTLCs will look very similar and we only need to ensure that we use the same Hashing function in both. | ||
|
|
||
| To do an Atomic swap from BTC to XTR we need 4 wallets, 2 BTC wallets, and 2 XTR wallets. |
There was a problem hiding this comment.
I'd suggest clarifying where these numbers come from. Is it 1 of each type of wallet for each party?
There was a problem hiding this comment.
yip, will clarify
| ``` | ||
| _relative locktime_ is a time sequence that Alice chooses to lock up the funds in order to give Bob time to claim this. | ||
|
|
||
| #### XTR - HTLC script |
There was a problem hiding this comment.
these 2 headings should have the same formatting, either both with the dash or both without
There was a problem hiding this comment.
Agree with this, lets make them consistent.
|
|
||
| ## Goals | ||
|
|
||
| The aim of this Request for Comment (RFC) is to describe how an Atomic swap will be created. |
There was a problem hiding this comment.
Suggested change
| The aim of this Request for Comment (RFC) is to describe how an Atomic swap will be created. | |
| The aim of this Request for Comment (RFC) is to describe how BTC/XTR Atomic swaps will be created. |
There was a problem hiding this comment.
Specifically avoided calling this a BTC/XTR Atomic swap document so that we can expand this to include all other crypto atomics swaps here.
There was a problem hiding this comment.
That’s fine but at the moment that’s all it is 🤷
SWvheerden
changed the title
There was a problem hiding this comment.
Hi @SWvheerden, looking good, just a suggestion to make the example text a bit clearer, also rectified a math rendering gremlin.
RFC/src/RFC-0240_AtomicSwap.md
Outdated
Comment on lines
77
to
91
| As an example, Alice wants to trade some of her XTR for Bob's BTC. Alice and Bob need to agree on an amount of XTR and BTC to swap. If this is agreed on the following steps will happen: | ||
|
|
||
| * Alice chooses a random string as the pre-image (\\( \preimage \\)), she hashes this with SHA256. She then sends the hash to Bob. Along with het BTC address. | ||
|
|
||
| * Bob sends his a public version of the [script key], \\( K_{Sb} \\) for use in the XTR transaction. | ||
|
|
||
| * Alice creates a XTR transaction with an HTLC contract requiring \\( \preimage \\) as the input, to pay out to Bob's address or it pays back to her after a certain time. | ||
|
|
||
| * Bob waits for this transaction to be mined. When it is mined, he checks the spending script and verifies that the script checks (\\ \hash{\preimage} \\), he has the [script key], \\( K_{Sb} \\) to claim it and that it has a sufficiently long time-lock to give him time to claim the transaction. | ||
|
|
||
| * Upon verification, Bob creates a BTC transaction with the same \\( \preimage \\). But this HTLC spends to Alice's BTC address she gave him. | ||
|
|
||
| * Alice checks the Bitcoin blockchain and upon seeing that the transaction is mined, she claims the transaction. But by claiming it, she makes public what (\\( \preimage \\)) is. | ||
|
|
||
| * Bob sees that his BTC is spent, and looks at the witness to get \\( \preimage \\). Bob can then use \\( \preimage \\) to claim the XTR transaction. |
There was a problem hiding this comment.
Suggested change
| As an example, Alice wants to trade some of her XTR for Bob's BTC. Alice and Bob need to agree on an amount of XTR and BTC to swap. If this is agreed on the following steps will happen: | |
| * Alice chooses a random string as the pre-image (\\( \preimage \\)), she hashes this with SHA256. She then sends the hash to Bob. Along with het BTC address. | |
| * Bob sends his a public version of the [script key], \\( K_{Sb} \\) for use in the XTR transaction. | |
| * Alice creates a XTR transaction with an HTLC contract requiring \\( \preimage \\) as the input, to pay out to Bob's address or it pays back to her after a certain time. | |
| * Bob waits for this transaction to be mined. When it is mined, he checks the spending script and verifies that the script checks (\\ \hash{\preimage} \\), he has the [script key], \\( K_{Sb} \\) to claim it and that it has a sufficiently long time-lock to give him time to claim the transaction. | |
| * Upon verification, Bob creates a BTC transaction with the same \\( \preimage \\). But this HTLC spends to Alice's BTC address she gave him. | |
| * Alice checks the Bitcoin blockchain and upon seeing that the transaction is mined, she claims the transaction. But by claiming it, she makes public what (\\( \preimage \\)) is. | |
| * Bob sees that his BTC is spent, and looks at the witness to get \\( \preimage \\). Bob can then use \\( \preimage \\) to claim the XTR transaction. | |
| As an example, Alice wants to trade some of her XTR for Bob's BTC. Alice and Bob need to agree on an amount of XTR and | |
| BTC to swap. If this is agreed on the following steps will happen: | |
| * Alice chooses a random string, \\( \preimage \\), as the pre-image and hashes it with SHA256. She then sends the hash | |
| of the pre-image, \\( \hash{\preimage} \\), to Bob along with her BTC address. | |
| * Bob sends her a public version of his [script key], \\( K_{Sb} \\), for use in the XTR transaction, which we can refer | |
| to as Bob's script address. | |
| * Alice creates a one-sided XTR transaction with an HTLC contract requiring \\( \preimage \\) as the input, which will | |
| either pay out to Bob's script address or to her script address, \\( K_{Sa} \\), after a certain "time" has elapsed | |
| (block height has been reached). | |
| * Bob waits for this transaction to be mined. When it is mined, he verifies that the UTXO spending script expects a | |
| comparison of \\( \hash{\preimage} \\) as the first instruction, and that his public [script key], \\( K_{Sb} \\), will | |
| be the final value remaining after executing the script. He has the private [script key], \\( k_{Sb} \\), to enable him | |
| to produce a signature to claim the funds if he can get hold of the expected pre-image input value, \\( \preimage \\). | |
| He also verifies that the UTXO has a sufficiently long time-lock to give him time to claim the transaction. | |
| * Upon verification, Bob creates a Segwit HTLC BTC transaction with the same \\( \hash{\preimage} \\), which will spend | |
| to Alice's BTC address she gave him. It is important that the time lock for this HTLC has to expire prior to the time | |
| lock of the XTR HTLC that Alice created. | |
| * Alice checks the Bitcoin blockchain and upon seeing that the transaction is mined, she claims the transaction, but, | |
| in order for her to do so, she has to make public what \\( \preimage \\) is as she has to use it as the witness of the | |
| claiming transaction. | |
| * Bob sees that his BTC is spent, and looks at the witness to get \\( \preimage \\). Bob can then use \\( \preimage \\) | |
| to claim the XTR transaction. |
SWvheerden
force-pushed
the
sw_btc_xtr_swap
branch
from
146be0c to
15a690e
Compare
philipr-za
reviewed
Oct 29, 2021
| ``` | ||
| _relative locktime_ is a time sequence that Alice chooses to lock up the funds in order to give Bob time to claim this. | ||
|
|
||
| #### XTR - HTLC script |
There was a problem hiding this comment.
Agree with this, lets make them consistent.
Co-authored-by: Philip Robinson <simian@tari.com>
Co-authored-by: Philip Robinson <simian@tari.com>
philipr-za
approved these changes
Oct 29, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds in RFC-0240 to allow us to do BTC-XTR atomic swaps.