comment 0

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 "" --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:
Alice fee:

Bob deposit:
Alice payment:

Bob payment:

Alice tries to spend Bob payment:

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.

(By jl777)


Leave a Reply

Your email address will not be published. Required fields are marked *