easyDEX test run - automated atomic cross chain swap
With bitcoin protocol there is a way to setup an atomic swap between two parties. What that means is that either the swap happens with both parties getting their half, or everybody gets all their funds back.
With recent events it should be clear that the safety of doing direct atomic swaps is clearly needed. From the user standpoint, I made a shapeshift like request/response mechanism. I dont have any fancy HTML page, so it is just via command line curl call:
curl --url "http://127.0.0.1:7778" --data "{"agent":"InstantDEX","method":"request","vals":{"source":"BTCD","amount":0.1,"dest":"BTC","minprice":0.002}}"
The user does the above call, which submits a request to swap 0.1 BTCD for BTC, with a minimum price of 0.002. Now this triggers a broadcast to all liquidity providers and the ones that are willing and able to fill this request responds. The originating node waits for 30 (this is adjustable) seconds and if the best offer is above the minimum price, the atomic swap protocol is started.
The protocol itself is rather complicated as it needs to make sure that all possible cases end up with nobody losing any funds. Since all funds are always in the user's local wallets, as long as you keep your passphrase secure, your funds are secure. At the high level to achieve this there are several ways, but I wanted a way that would work with as many coins as possible, even coins that dont support the fancy new opcodes. All one of the coins needs to support is a standard 2of2 multisig and given that the atomic protocol works. On the other side the coin needs to support time locking and in between there is quite a lot of complicated back and forth, but for now I will just go over the specific transactions.
By convention the side with bitcoin, I call Bob and the one with the altcoin is called Alice. Both sides need to make a small fee prior to starting the swap, this prevents a "nothing at stake" attack and as we have seen without anything at stake, there will be people that will do all sorts of things if they can get a financial edge. The small fee makes such attacks nonviable. Similarily the deposit has a bit more than the transaction amount to discourage Bob from starting swaps and not finishing.
Bob will send a conditional deposit that Alice can spend if Bob doesnt follow through with the swap. Alice then sends a 2of2 multisig payment to Bob, but Bob cant yet spend it. However, Bob knows that he has the multisig funds in pocket so he sends the actual payment to Alice (in a special format). Alice spends this payment and in doing so is forced to divulge the missing info Bob needs to spend the multisig. Bob uses this info and spends the multisig and then also reclaims his original deposit.
The above is the simple case!
The protocol also handles either party bailing out at any part of the process, but until the simple mainstream case is understood, it is not easy to understand how to recover in the non-main cases.
Bob fee: https://blockchain.info/tx/af20b9c97c7808396edaf036110ae951b4a26fefd9cfca0924734bfecec0bbe8
Alice fee: http://explorebtcd.info/tx/c34e914e768f3c59c3a40d3148fa7062546b17c1c2b49eaeca65c2dba6d9f389
Bob deposit: https://blockchain.info/tx/cfc0f3e8a997ec022a89619697edab7071f623ccf8af51299ec7fdeb51dce0c3
Alice payment: http://explorebtcd.info/tx/9f94fe748342149ee8f045bfeb20a8f049c7f55161f449c236f091fe7db570bf
Bob payment: https://blockchain.info/tx/2bfc8e633518169be61b6127221b2add55c13a0dc1f98fcf2ad04032ac33fa9c
Alice tries to spend Bob payment:
01000000019cfa33ac3240d02acf8ff9c10d3ac155dd2a1b2227611be69b161835638efc2b000000006a4730440220240cb90601d6baa5615a58984833129661b454c93e3f45b3192226658d0eff0c02206284ed90bbaa5f7c78ccff6f28932b5b9fa3479eca2850e414e57bdac1cb113d012102a9669e63ef1ab04913615c2f3887ea3584f81e5f08feee9535b19ab3739d8afdffffffff01402c0000000000001976a914b7128d2ee837cf03e30a2c0e3e0181f7b9669bb688ac00000000
Bob tries to spend Alice payment: 010000002822a25701bf70b57dfe91f036c249f46151f5c749f0a820ebbf45f0e89e14428374fe949f00000000d547304402205876c6fcfbf1e19862cd1328f70c24dc79b1605a75d39dc08ae9436ffb5b37df0220679c6ab98eb6b23e510ba7618097bb59165aae760796c2614aab0dbd4a702d0b01483045022100ec4e0f1c96b986f5857b4d4d239d9c0bba5f0b17bfa2f6ea4e68952521a38c35022066069c79af47cf5cf9d8e65551029686abefd068c254922d55ac44f5ddff45c501210239f51bac8bf4b0222f9e8c2f31053e2096c38b8cbdb08b493dda3af7295b7a8d2103b416ef019d5dbba173915b2d2127240c50502b72b958b312fb3fb58419f080bfffffffff01706f9800000000001976a91454a752f0d71b89d7c014ed0be29ca231c9546f9f88ac00000000
Bob does refund: 0100000001c3e0dc51ebfdc79e2951aff8cc23f67170abed979661892a02ec97a9e8f3c0cf000000006b483045022100fa4646dd2d692fece16368b9b43af0b9646f0f22b6876fcb41eee3e44483f54e02203ace1b69683335144a4ef3e3db46a1d732748e19d54ee8862362f5e3ef4e82fb01210398a4cb9f6ea7c52a4e27455028a95e2e4e397a110fb75f072c2c58a8bdcbf4baffffffff0194340000000000001976a91454a752f0d71b89d7c014ed0be29ca231c9546f9f88ac00000000
The first 5 transactions got confirmed on the respective blockchains, but I am still debugging the spending of the three last transactions. All of this is being done within a single iguana instance on each side, in fact one of them is running BTC as a lite client and BTCD as a full node. And there is also a special bulletin board network that the nodes use to communicate with each other indirectly. So quite a lot is working and custom bitcoin transactions are always quite the pain.
Now you might wonder if this easyDEX can be made to work with STEEM and from my initial research into it, the answer is yes! STEEM supports 2of2 multisig and use the secp256k1 keypairs, which is exactly what is needed. I would need to get the transaction signing code working locally with remote relay node or to require a locally running steemd. Or both approachs to offer more flexibility.
Now the above places security above speed and the process to do the above is the 30 seconds for waiting for the responses, but after that there needs to be a wait for BTC confirmation and also altcoin confirmation, so it will take some minutes before you will know that the trade is finalized. However, no more worries about being Gox-finexed
I need to debug the spending of the special transactions and beef up the custom network and it will be ready for public testing. And it might seem too simple to just make a single curl call to start all this back and forth, but for the client side that is all that is needed, but clearly I need to add ways for the GUI to display the progress status of each swap and a history.
This was a very interesting read. I do have a few questions:
Who are the liquidity providers you mention at the beginning of the post?
Could anybody tap into the network to listen to the swap requests, and send the offers?
I will post about the liquidity providers in a future post, but I plan to make it open to anybody who runs a full node. I might even be able to get a lite node to be a liquidity provider, but not sure about that yet. Regardless of what it takes to be an LP, all such LP nodes will see all the requests, so that gives each conversion the chance for best price
Good job like always) Go on
Nice @jl777
Shot you an Upvote :)