pezkuwichain/consensus
1
0
Fork 0
mirror of https://github.com/pezkuwichain/consensus.git synced 2026-04-22 04:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2 from retotrinkler/patch-1

Browse Source 
Fix BTX -> BTC typo
This commit is contained in:
Jeff Burdges
2018-09-21 08:52:09 -04:00
committed by GitHub
parent cb3895cf99 c350b48d19
commit ddbbaf0ca8
1 changed files with 21 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bridge/swap.md
+21 -1
View File
@@ -1 +1,21 @@
We envision a bridge that manages security for atomic swaps by observing the bitcoin blockchain, but does not itself hold bitcoins, and only holds dots as stake. Aside from the bridge nodes and polkadot infrastructure, we have two customers, Paula who trade dots and Brit who trades bitcoin, although atomicity could generalise either to a group.
I'll give a handy wavy sketch that should be informed by going over ZKCP literature:
Step 0. Paula's offer of Dot and Brit's offer of BTC get matched via some trading network, placing them into communication. I donno if MPC helps here.
Step 1. Paula and Brit negotiate their transaction:
- Paula provides Brit with her BTC wallet hash and her bridge supported test for considering the transaction settled on bitcoin.
- If Brits consider the test reasonable, then Brit secretly crafts but does not publish her BTC payment x to Paula, and gives Paula the hash of x.
Step 2. Paula submits a bridge parachain transaction y to Brit that registers the trade with the bridge and time locks the funds she wishes to trade. Registration reveals the test, the Dot and BTC amounts, Paula's BTC wallet hash, and the BTC transaction hash.
Step 3. After the parachain transaction is finalised, Brit submits her BTC transaction x, or maybe gives it to Paula so she can submit it. If Brit does not do so fast enough then Paula's time lock expires.
Step 4. The bridges threshold sign y releasing the funds, after recognising that x matches its hash commitment, sends the correct BTC amount to Paula's BTC hash, and has persisted long enough to past the test.
We could improve perceived latency for Brit, and maybe simplify client code, by having Brit threshold encrypt x to the bridges in step 2, so the bridges carry out step 3 after finalising. We expect polkadot to be fast though, so imho Brit should prefer the latency and simpler security model above. Also I'd expect the above scheme simplifies bridge code far more than alternative schemes simplify client code.