Updated README

Author: KyrylR

README.md

@@ -1,13 +1,13 @@
 # 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.
+Taprootized Atomic Swaps (TAS) is an extension for Atomic Swaps that presumes the untraceability of 
+transactions related to a particular swap. Based on Schnorr signatures, Taproot technology, and
+zero-knowledge proofs, the taprootized atomic swaps 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 
+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">
@@ -20,10 +20,11 @@ parties and a “mathematical contract” between them directly. That is, an ide
 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).
+This paper will provide a concept of taprootized atomic swaps that allow 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).
 
 <div align="center">
 <img src="assets/sequence-diagram.png"/>
@@ -32,36 +33,32 @@ to the corresponding Bitcoin transactions (without additional context from the i
 ### 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:
+3. Alice forms the alternative spending path `Script = sig(skA) + Locktime` in the form of Bitcoin Script 
+4. Alice calculates an escrow public key as `PKEsc = K + PKB + hash((K + PKB) || Script) * G` (here,
+   escrow is just a public key, formed using Taproot technology
+   1. The signature `sig(skEsc)`, verified by thr `PKEsc`, can be generated only with the knowledge of `k`, `skB` and `Script`
+5. Alice calculates the `h` as a hash value of `k` (zk-friendly hash function is recommended to use)
+6. 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` (it's the `Script` itself)
+7. Alice sends the transaction to the Bitcoin network
+8. Alice generates the zero-knowledge `proof` that includes:
+   1. The proof of knowledge of `k` that satisfies `k * G == K`
+   2. The proof of knowledge of `k` that satisfies `zkHash(k) == h`
+9. Alice provides the set of data to Bob:
    1. `h`
    2. `K`
-   3. `PKEsc`
+   3. `Script`
    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.
+10. Bob calculates `PKEsc` as `K + PKB + hash((K + PKB) || Script) * G` and finds the transaction locked BTC (verifies it exists). Then Bob performs the following verification:
+    1. 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`
+    2. Verifies that the `Script` is correct and includes only the required alternative path.
+11. 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` (hash preimage)
+    2. Signature of `skB` + Locktime: Bob, with knowledge of `skB`, can spend the output, but only after some point in time `t2`
+12. Bob sends the transaction to the Ethereum network (or any other that supports `zkHash()`)
+13. 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.
+14. If Alice publishes a transaction with `k`, Bob can recognize it and extract the `k` value
+15. Bob calculate the needed `skEsc` as `skEsc = k + skB + hash((K + PKB) || Script)`
+16. Bob sends the transaction with the signature generated by the `skEsc` and spends funds locked by Alice.