Initial commit

Author: OmegaTymbJIep

.gitignore

@@ -0,0 +1,7 @@
+.idea
+
+/target
+
+*.dev.*
+dev.*
+*.dev

Cargo.lock

@@ -0,0 +1,8 @@
+[package]
+name    = "taprootized-atomic-swaps"
+version = "0.1.0"
+edition = "2021"
+license = "MIT"
+
+[dependencies]
+eyre = { version = "0.6.11" }

Cargo.toml

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023 Distributed Lab
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

LICENSE

@@ -0,0 +1,67 @@
+# Taprootized Atomic Swaps
+
+Taprootized Atomic Swaps (TAS) is an extension for Atomic Swaps that presumes the untraceability of
+transactions related to a particular swap. Build top on Schnorr signatures, Taproot technology, and
+zero-knowledge proofs TAS hide swap transactions under regular payments.
+
+## Intro 
+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.
+
+<div align="center">
+<img src="https://github.com/distributed-lab/taprootized-atomic-swaps/blob/main/assets/atomic-swap.png"/>
+</div>
+
+On the other hand, atomic swaps is a technology that initially assumed the involvement of only two 
+parties and a “mathematical contract” between them directly. That is, an ideal exchange presupposes 
+2 conditions:
+1) Only counterparties participate in the exchange (works by default)
+2) Only counterparties know about the fact of the exchange (it would be nice to ensure)
+
+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).
+
+<div align="center">
+<img src="https://github.com/distributed-lab/taprootized-atomic-swaps/blob/main/assets/sequence-diagram.png"/>
+</div>
+
+### The protocol includes the following steps:
+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`
+   1. The signature can be generated only with the knowledge of `k` and `skB`
+4. Alice calculates the `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:
+   1. Signature of `skEsc`: Bob, with knowledge of `k` and skB can spend the output
+   2. Signature of `skA` + Locktime: 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:
+   1. The proof of knowledge of `k` that satisfes `k * G == K`
+   2. The proof of knowledge of `k` that satisfes `zkHash(k) == h`
+8. Alice provides the set of data to Bob:
+   1. `h`
+   2. `K`
+   3. `PKEsc`
+   4. `proof`
+9. Bob performs the following verifications:
+   1. Verify that `PKEsc == K + PKB`, it means that the valid `PK` of Bob was added to escrow PK
+   2. Verifes 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:
+    1. Publishing of `k` and the signature of `skA`: only Alice can spend it if she reveals `k`
+    2. Signature of `skB` + Locktime: 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)
+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.
+    1. If Alice doesn’t publish the relevant `k`, Bob can return funds after locktime is reached
+13. If Alice publishes a transaction with `k`, Bob can recognize it and extract the kvalue
+14. Bob calculate the needed `skEsc` as `skEsc = k + skB`
+15. Bob sends the transaction with the signature generated by the `skEsc` and spends funds locked by 
+Alice.

README.md

@@ -0,0 +1,7 @@
+use eyre::Result;
+
+fn main() -> Result<()> {
+    println!("Hello, world!");
+
+    Ok(())
+}