Performed the first taprootized atomic swap between BTC and ETH
Parameters used for the swap k: b550385a62c0eba5a837ee11962e380818a50611caa1113e33a411528ebb193d; K: 03d39da41952d4ae038a49b693b313ec956ad80d9fc940dc5afedf86351e9fa930
Transactions:
Alice locks BTC: 850e9258bf8b3bb280d32a647198d8024aece543dc283f7bfa526f4c0ceb1ab8
Bob locks ETH: 723919c0e8ec57d38792ec29b2cb82ee885b9fbbc886b34ff40fb5d3f7cc9b43
Alice withdraws ETH from the contract: 47546191a7c99ec4a7ddc243d6ea75d345ab3aff0762e09dd2f537731bd484f3
Bob spends BTC: 859dbfaa901d7106aecc8cb29966ede0c9d7a17c2cae31f4d420c1d770e9706d
The demo code: https://github.com/distributed-lab/taprootized-atomic-swaps
Topic: Taprootized Atomic Swaps (Read 197 times)
Quote from: n0nce
It sounds to me like the main novelty / improvement here is the off-chain channel and not necessarily the usage of Taproot.
It can be done without Taproot, based on regular signature, but Taproot hides the fact of the swap itself (I mean the existence of alternative lock time).
Quote from: n0nce
What do you mean by 'other accounting system', and why would a 'non-taprootized atomic swap' disclose more information to external auditors?
"other accounting system" - for example, it can be Ethereum. In classic atomic swaps, it's possible to match revealed secrets after the swap and find exact transactions that participated in the swap. In this case, the secret value is revealed only in the counterparty blockchain; on Bitcoin nothing is revealedQuote from: d5000
If I interpret it right, then one part of the process is moved off-chain, which normally would also be an on-chain set of transactions in Tier Nolan's original protocol.
Exactly, parties must have an off-chain channel for exchanging needed dataQuote from: n0nce
You'll still be able to match the transactions through the temporal proximity and exchange rate at the time of transaction, right?
Yeah, so we created the proposal that makes it more difficult (like solving a sudoku puzzle) - https://docs.google.com/document/d/16gkq1BOwL28dPYs4MzYatWpdfc5MrsRg6XBPhhBAgIc/edit#heading=h.860gkxlt55gi
Quote from: n0nce
What do you mean by 'other accounting system', and why would a 'non-taprootized atomic swap' disclose more information to external auditors?
"other accounting system" - for example, it can be Ethereum. In classic atomic swaps, it's possible to match revealed secrets after the swap and find exact transactions that participated in the swap. In this case, the secret value is revealed only in the counterparty blockchain; on Bitcoin nothing is revealed
Quote from: d5000
If I interpret it right, then one part of the process is moved off-chain, which normally would also be an on-chain set of transactions in Tier Nolan's original protocol.
Exactly, parties must have an off-chain channel for exchanging needed data
Quote from: d5000
Already found my misunderstanding: k is not needed for signing but has to be published, so the script on the altcoin transaction needs to be able to use the zk hash function.
when k is published on the altcoin blockchain, it can be used to generate the correct signature for the Bitcoin. yeah, script or smart contract
Quote from: d5000
I guess the protocol would even work if a non-zk hash function is used, only that Bob then cannot verify that Alice knows k. He, however, wouldn't risk losing his coins as Alice can't move them without k. In this case, it would be compatible with many Bitcoin-like blockchains. Or am I getting something wrong?
Yes, everything is correct. zk function, and the proof is needed to be sure that the counterparty locks funds on the correct "k", which after the publishing, will be correctly used for signature generating
It sounds almost identical to Bitcoin <> Lightning atomic swaps; from a first read, it sounds like this should work.
How do you solve this issue though?
You'll still be able to match the transactions through the temporal proximity and exchange rate at the time of transaction, right?
What I like about Lightning swaps is that a payment is per default split into smaller amounts routed through different paths, as well as staying off-chain until a channel is closed, removing temporal proximity.
How do you solve this issue though?
any party can make a matching between transactions in the blockchains in which the exchange took place and find out both the participants in the exchange and the proportion in which assets were exchanged.
You'll still be able to match the transactions through the temporal proximity and exchange rate at the time of transaction, right?
What I like about Lightning swaps is that a payment is per default split into smaller amounts routed through different paths, as well as staying off-chain until a channel is closed, removing temporal proximity.
A concept of taprootized atomic swaps is hiding the swap's very fact. To an external auditor, transactions to initiate and execute atomic swaps will be indistinguishable from regular Bitcoin payments. In the other accounting system involved in the transfer, more information is disclosed (the fact of exchange can be traced).
What do you mean by 'other accounting system' and why would a 'non-taprootized atomic swap' disclose more information to external auditors? 
Very interesting. I've gone through the steps and I think I understand them, even without being an expert. However, I would really like to see an expert's opinion 
If I interpret it right then one part of the process is moved off-chain, which normally would be also an on-chain set of transactions in Tier Nolan's original protocol.
One single component I've a doubt about (not really important):
Why does the altcoin network need to support the zkHash function? Can't Bob simply use K (public key of k) for the condition that Alice needs to sign the transaction with k?
Already found my misunderstanding: k is not needed for signing but has to be published, so the script on the altcoin transaction needs to be able to use the zk hash function.
I guess the protocol would even work if a non-zk hash function is used, only that Bob then cannot verify that Alice knows k. He however wouldn't risk losing his coins as Alice can't move them without k. In this case it would be compatible with many Bitcoin-like blockchains. Or am I getting something wrong?
If I interpret it right then one part of the process is moved off-chain, which normally would be also an on-chain set of transactions in Tier Nolan's original protocol.
Quote
Bob sends the transaction to the Ethereum network (or other that supports zkHash() function or smart contracts)
Already found my misunderstanding: k is not needed for signing but has to be published, so the script on the altcoin transaction needs to be able to use the zk hash function.
I guess the protocol would even work if a non-zk hash function is used, only that Bob then cannot verify that Alice knows k. He however wouldn't risk losing his coins as Alice can't move them without k. In this case it would be compatible with many Bitcoin-like blockchains. Or am I getting something wrong?
I had an idea of Taprootized Atomic Swaps for reaching the untraceability of transactions related to a particular swap.
Atomic swap is an incredible approach to cross-chain exchanges without mediators. However, one of the disadvantages of its implementation in the classical form is the “digital trail” - any party can make a matching between transactions in the blockchains in which the exchange took place and find out both the participants in the exchange and the proportion in which assets were exchanged.
A concept of taprootized atomic swaps is hiding the swap's very fact. To an external auditor, transactions to initiate and execute atomic swaps will be indistinguishable from regular Bitcoin payments. In the other accounting system involved in the transfer, more information is disclosed (the fact of exchange can be traced). Still, it is impossible to link this to the corresponding Bitcoin transactions (without additional context from the involved parties).
The protocol description:
1. Alice (skA, PKA) and Bob (skB, PKB) have their keypairs and know each other's public keys.
2. Alice generates a random k and calculates the public value: K = k * G
3. Alice calculates an escrow public key as PKEsc = K + PKB (PK aggregation mechanism)
3.1 The signature for the escrow public key can be generated only with the knowledge of k and skB
4. Alice calculates h as a hash value of k (zk-friendly hash function is recommended to use)
5. Alice forms the funding transactions with the following conditions of how it can be spent (all these conditions can be put into P2TR):
5.1 Signature of skEsc: only Bob, with knowledge of k and skB can spend the output
5.2 Signature of skA + Locktime1: Alice, with knowledge of skA can spend the output, but only after some point in time t1
6. Alice sends the transaction to the Bitcoin network
7. Alice generates the zero-knowledge proof that includes:
7.1 The proof of knowledge of k that satisfies k*G == K
7.2 The proof of knowledge of k that satisfies zkHash(k) == h
8. Alice provides the set of data to Bob: h, K, PKEsc, proof
9. Bob performs the following verifications:
9.1 Verify that PKEsc == K + PKB, it means that the valid PK of Bob was added to escrow PK
9.2 Verifies that Alice knows k that satisfies k*G == K and zkHash(k) == h, it means that Bob can access the output PKEsc if he receives k
10. If verifications are passed, Bob forms the transaction that locks his funds on the following conditions:
10.1 Publishing of k and the signature of skA: only Alice can spend it if she reveals k
10.2 Signature of skB + Locktime2: Bob, with knowledge of skB, can spend the output, but only after some point in time t2
11. Bob sends the transaction to the Ethereum network (or other that supports zkHash() function or smart contracts)
12. Alice sees the locking conditions defined by Bob and publishes the k together with the signature generated by her skA. As a result - Alice spent funds locked by Bob.
12.1 If Alice doesn’t publish the relevant k, Bob can return funds after Locktime2 is reached
13. If Alice publishes a transaction with k, Bob can recognize it and extract the k value
14. Bob calculates the needed skEsc as skEsc = k + skB (or generates two signature values and aggregates them)
15. Bob sends the transaction with the signature generated by the skEsc and spends funds locked by Alice.
So, on the Bitcoin network, it will look like two regular payments; no info about the swap is revealed (if everything went fine).
Happy to receive some feedback and improvement proposals (you can leave it here https://docs.google.com/document/d/1mVMElv5smDalqD67D9zniwfFfmSg2badeAIZwgW-0kU/ as well)
Atomic swap is an incredible approach to cross-chain exchanges without mediators. However, one of the disadvantages of its implementation in the classical form is the “digital trail” - any party can make a matching between transactions in the blockchains in which the exchange took place and find out both the participants in the exchange and the proportion in which assets were exchanged.
A concept of taprootized atomic swaps is hiding the swap's very fact. To an external auditor, transactions to initiate and execute atomic swaps will be indistinguishable from regular Bitcoin payments. In the other accounting system involved in the transfer, more information is disclosed (the fact of exchange can be traced). Still, it is impossible to link this to the corresponding Bitcoin transactions (without additional context from the involved parties).
The protocol description:
1. Alice (skA, PKA) and Bob (skB, PKB) have their keypairs and know each other's public keys.
2. Alice generates a random k and calculates the public value: K = k * G
3. Alice calculates an escrow public key as PKEsc = K + PKB (PK aggregation mechanism)
3.1 The signature for the escrow public key can be generated only with the knowledge of k and skB
4. Alice calculates h as a hash value of k (zk-friendly hash function is recommended to use)
5. Alice forms the funding transactions with the following conditions of how it can be spent (all these conditions can be put into P2TR):
5.1 Signature of skEsc: only Bob, with knowledge of k and skB can spend the output
5.2 Signature of skA + Locktime1: Alice, with knowledge of skA can spend the output, but only after some point in time t1
6. Alice sends the transaction to the Bitcoin network
7. Alice generates the zero-knowledge proof that includes:
7.1 The proof of knowledge of k that satisfies k*G == K
7.2 The proof of knowledge of k that satisfies zkHash(k) == h
8. Alice provides the set of data to Bob: h, K, PKEsc, proof
9. Bob performs the following verifications:
9.1 Verify that PKEsc == K + PKB, it means that the valid PK of Bob was added to escrow PK
9.2 Verifies that Alice knows k that satisfies k*G == K and zkHash(k) == h, it means that Bob can access the output PKEsc if he receives k
10. If verifications are passed, Bob forms the transaction that locks his funds on the following conditions:
10.1 Publishing of k and the signature of skA: only Alice can spend it if she reveals k
10.2 Signature of skB + Locktime2: Bob, with knowledge of skB, can spend the output, but only after some point in time t2
11. Bob sends the transaction to the Ethereum network (or other that supports zkHash() function or smart contracts)
12. Alice sees the locking conditions defined by Bob and publishes the k together with the signature generated by her skA. As a result - Alice spent funds locked by Bob.
12.1 If Alice doesn’t publish the relevant k, Bob can return funds after Locktime2 is reached
13. If Alice publishes a transaction with k, Bob can recognize it and extract the k value
14. Bob calculates the needed skEsc as skEsc = k + skB (or generates two signature values and aggregates them)
15. Bob sends the transaction with the signature generated by the skEsc and spends funds locked by Alice.
So, on the Bitcoin network, it will look like two regular payments; no info about the swap is revealed (if everything went fine).
Happy to receive some feedback and improvement proposals (you can leave it here https://docs.google.com/document/d/1mVMElv5smDalqD67D9zniwfFfmSg2badeAIZwgW-0kU/ as well)
Jump to: