InstantDEX - decentralized shapeshift proof of concept

[jl777]

Previous threads:
https://bitcointalk.org/index.php?topic=1340621.msg13828271#msg13828271
https://bitcointalk.org/index.php?topic=1364951

describe the atomic cross chain protocol, which I now have pretty much working on top of iguanacore. Still need to verify the blockchain's will accept the tx, but from order propagation, order match, protocol negotiation are all working, even most of the one party disconnects case. However I still have to add more validations of the rawtx data to make sure it matches the expected values, but for testing the basics, enough is working now.

Before even the fee tx are made, both sides go through a "cut and choose" protocol. Basically it is like shuffling a deck of cards and having the other side choose one. In order to prevent cheating, all the cards that were not chosen are revealed to the other side. In this case, the "card" is actually a keypair used for creating the transactions, both as reveal secret and 2of2 multisig. The fee is set to 1/777'th of the transaction value and 1000 keypairs are used, so if the someone tries to cheat and get away with a free ride, then will end up paying 1000 fees of 1/777 = 1000/777 = 28.7% penalty. Another attempt at cheating would be to put up a deposit and not go through with the trade, but in this case the other party gets to claim the deposit, which is 10% more than the trade value.

alice starts the process by issuing an API call using curl:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"InstantDEX\",\"method\":\"request\",\"vals\":{\"source\":\"BTCD\",\"amount\":1,\"dest\":\"BTC\",\"minprice\":0.0025}}"

It is a request to convert 1 BTCD into BTC, with a minimum price of 0.0025

I have one of the relay servers setup to respond to incoming requests and if it finds one it can satisfy, it sends back a quote based on the current prices available on central exchanges. It adds a 1% profit margin and makes sure it is above the minimum price.

[(BTCD 1.00000000) -> (BTC 0.00000000) r.1555902389 q.0] destamount 0.00311118 aveprice 0.00314261 minamount 0.00250000

this starts the back and forth process that leads to:

ALICE:
0100000025797e57010acd55e30647957397faccb371031a54583b1f0ef6a74da494308cdefcf7899f020000006a473044022078dc07bb1a5052b6c3be55f3b0dbf215bccf53c2fe96214f7f631bf812dbb954022033381fcb1ed57024a6b55d9dde5c949a1c779e5588ba5582eca2b40760dbbdc4012103377aea6f477582332f128acb197b9f463b5262571d23afaa113dfab48753e3cdffffffff02a0860100000000001976a914ca1e04745e8ca0c60d8c5881531d51bec470743f88ac7053883b000000001976a914c210f6711e98fe9971757ede2b2dcb0507f3f25e88ac00000000 <- sendrawtransaction alicefee.(4bc6dc649ce823463b833ad19489e56aac7768bc50c5a65fad628fb3bf62d0f1)

BOB:
01000000011501573db522fad7c2597a91c725c6d0988fe4a7c9f038847ac37ec1af8646e3010000006a473044022059a71e3cc249b6cce290b506991b79e1189e2184c7804ac5163d8bb9696d337b022030e9894f2bca492e0331cf3e2682fe16d8437f8c7d0a20d225223f77afdb6b12012103958f90717f04239331a532353cebaf973025ea6586cbe70d70673ed025c2eb51ffffffff0210270000000000001976a914daedddd8dbe7a2439841ced40ba9c3d375f9814688ac20f40e00000000001976a914a8f1248b3c22b3a53855e3a47759ca05fadf741888ac00000000 <- sendrawtransaction bobfee.(fce96811a213f7453a231f677969877ca26be63c44bd9d4c6c8ce01e0a353869)

04000000011501573db522fad7c2597a91c725c6d0988fe4a7c9f038847ac37ec1af8646e3010000006a473044022100ccade6ded0e435581e942538262521b4ad1d4d5cdb34e477fb6d4d40f2c8aa14021f5ff51e3b8fd7df79894359fc287bf95dff791d71881f0835f9fa1f1e911f56012103958f90717f04239331a532353cebaf973025ea6586cbe70d70673ed025c2eb51ffffffff02d538050000000000676304808b7e57b1752102a9669e63ef1ab04913615c2f3887ea3584f81e5f08feee9535b19ab3739d8afdac67a914fc2fb2cc391fd04fdf23975fe10942480d4dbf6d882103a7b696908f77d69ec89887f8c4a0423b9e80b5974dc43301bd7d8abad07e1211ac685be20900000000001976a914a8f1248b3c22b3a53855e3a47759ca05fadf741888ac808b7e57 <- sendrawtransaction bobdeposit.(0c7eec2f0b5f66e0a70364cf98fe3c3154b52dc4292fe2594dcbdee6fe36fa8d)

ALICE:
verifies the deposit is proper and sends:
0100000025797e57010acd55e30647957397faccb371031a54583b1f0ef6a74da494308cdefcf7899f020000006a4730440220360dafed37ab3d40d40f8badca8639fc20e9592825107006f0b7e8246c9837da022030cf6fcebd312aac0224a9196b50b2f9683004b34c4f01fc469e80a4681739c3012103377aea6f477582332f128acb197b9f463b5262571d23afaa113dfab48753e3cdffffffff0200e1f505000000004752210262389d35fab6a1ea8b776dae511126e8b4f9e6a2999604f300cb038c628923982103d65501ab7adc65e88b29cc7bca32af3bac9b2e4d0b44e2a574a6d02185b2264c52ae10f99335000000001976a914c210f6711e98fe9971757ede2b2dcb0507f3f25e88ac00000000 <- sendrawtransaction alicepayment.(802f91a8db3a4357fb24c31410301315fc982b7e0cefe376e318af11de4ae000)

BOB:
verifies the payment and sends his payment:

04000000011501573db522fad7c2597a91c725c6d0988fe4a7c9f038847ac37ec1af8646e3010000006a47304402203c1eee1d939f672e2f805b5dcf48b6b5ee877140c6ccf07f2e00a98143fdf40302206e3bf240767eddef63a17e38076a7f684ed70f0a0fe6e945626d7447e1d4c420012103958f90717f04239331a532353cebaf973025ea6586cbe70d70673ed025c2eb51ffffffff024ebf04000000000067630420827e57b17521034924708e5d3b76f695530f3e8dd28297565177882247c4829b56c7db33abcddaac67a914d0e187a0b07b3a36517f3f2517ab88359f58456c882102a9669e63ef1ab04913615c2f3887ea3584f81e5f08feee9535b19ab3739d8afdac68e25b0a00000000001976a914a8f1248b3c22b3a53855e3a47759ca05fadf741888ac20827e57 <- sendrawtransaction bobpayment.(ebff5b4517f62f0cf4fbeda4d264f12460a3f5bd3584652f4d3d89ff1da25508)

ALICE:
gets bob's payment and spends it (thus revealing the secret bob needs)
04000000010855a21dff893d4d2f658435bdf5a36024f164d2a4edfbf40c2ff617455bffeb000000006b48304502210089f9026fe6618a9893bdfe7555783d57e98371139a155725ed7a818dee14915f022013bcfd69c5893a508f3a2abb63919a1cbd0603abc4a8f08587bfe4871d586634012102a9669e63ef1ab04913615c2f3887ea3584f81e5f08feee9535b19ab3739d8afdffffffff013e980400000000001976a914b7128d2ee837cf03e30a2c0e3e0181f7b9669bb688ac00000000 <- sendrawtransaction alicespend.(9a243fd64f7693ece5120a91514b94ff1656ff0a6d406544383416d48db65219)

BOB:
uses the secret to spend his half and gets refund of deposit
0400000014847e5701f5974873838847700d449e33ab037bc6a2100b8be47b4134fb756bd3ca26e7f200000000d648304502210090e186ab2645383feedc1e6ec66c0f786a0a4cb1e339d253129f27ca873f269602200cef8fefa7f5dfbf9ee1400e3bb056796b22f2ba29791d19592079b199722da101483045022100c95d1ae2c03666eb0f6541aad7d58ff08318f49f20592332c60b3eff6f7e857502204393773a7bd7bac011b60e1854c15462bdb4ca979f1a3e3767bcd0368dd509ff0121021510cb0f068ef50d47def117dd9119b2d218669daf1bbe0c4590ed9b797940a821038bc06ee1f3209ce1603985985b7fe82b0488f6e871f9a8476d0e06506a046281ffffffff01f0b9f505000000001976a9143ef4734c1141725c095342095f6e0e7748b6c16588ac00000000 <- sendrawtransaction bobspend.(1e1797ccd806dc1547566a9c03aaa2541c844a5caba680bdc7343d9b55fbe674)

04000000018dfa36fee6decb4d59e22f29c42db554313cfe98cf6403a7e0665f0b2fec7e0c000000006a47304402207bd38ffb34aa7da647c4842a01cd9bf04be1f38057fe8f98246395e839b1d0160220189f1521bf93abf7497152668e9da8d09db15803fcad365a211dfcf486a6e6ee012103a7b696908f77d69ec89887f8c4a0423b9e80b5974dc43301bd7d8abad07e1211ffffffff01c5110500000000001976a9143ef4734c1141725c095342095f6e0e7748b6c16588ac00000000 <- sendrawtransaction bobrefund.(92e349bd2435c52d1b78efa3f4153126536cdb1a0e19b5d6707f0f76b804dcac)


I wanted to have a single place to describe how a decentralized shapeshift functionality is created on top of the atomic cross chain protocol. more after I enable and test the actual broadcasting of the signed transactions. The above is the simplest case, but I have seen most of the non-completion states during testing, so even if some issues I dont see it as too much work to get it all fixed. Getting complete test results is the next step after verifying these tx will actually confirm.

hope to post more details soon

 

[jl777]

things are more complicated as one side of the atomic swap is via basilisk lite node and it doesnt have any blockchains locally.

https://blockchain.info/tx/22651e62f248fe2e72053d650f177e4b246ee016605102a40419e603b2bbeac8
http://explorebtcd.info/tx/3d82297b93afef410384b7089b9b2e532ae6812e8c74c8d5476f11e99b678a8b

The feetx got confirmed. but stuck on the deposit. I will optimize the process by locally caching all the unspent info, so it wont keep having to query the network for them. also that will make it much more accurate about creating new rawtx without reusing outputs that are already used

 

[jl777]

A question was asked about basilisk: "
just listening to your Core Radio interview. When running in Basilisk mode, you're relying on full Iguana nodes to answer queries. How does that affect security -- are you completely vulnerable to those nodes giving you wrong answers?
Also, what stops an attacker from charging zero fees for a query and always being selected?"

multiple nodes are queried and unless there is an attack, they will all return the same rawtx as a determistic vin selection algo is used. The basilisk node can verify that the returned transaction is valid, except for the details about the spends. However, these all must be unspents previously received by that basilisk node, so it can simply verify that it is one of these. In a restart from scratch mode, the basilisk node would have to query random peers about the details of each unspent that is being spent, making sure it is not from the same node that returned the rawtx.

in fact, I recently improved things so that each basilisk node starts each session by getting a list of all its unspents and it can then construct the rawtx out of that. this shifts the fee collection to need a different model, but I am thinking of allocating block rewards to iguana nodes that fulfill basilisk requests. having all the unspents local reduces the time needed to construct a new tx as once there are in the local cache, no external request is needed at all

in the event wrong answers are given, then it wont be able to be signed or will be rejected on submission to the blockchain

the only wrong answer that would pass these tests would be unspents to the address in a basilisk node's wallet that is of greater value, thus making the basilisk node spent a lot more in network txfee, so this attack is only profitable for the miner of the block the tx will be included in. However, by verifying each input against the local cache, avoids this bad data also.

if you can think of any other attack, please let me know. all the data being used by the iguana nodes are publicly available blockchain data, so there doesnt seem to be any issues on that side. preventing an overspend on txfee was the only attack I found so far and going to the validated local unspent cache avoids this
[doublepost=1468254325][/doublepost]followup Q:
the attacker can still present themself as multiple nodes all of which charge zero fees, no? (I understand that transactions based on wrong answers might be rejected, but the wrong answers could be used to mislead the user in the meantime)

###
If the attacker controlled all nodes a basilisk connects to, then of course it could mislead it to an extent. However, if there is only one honest node, then the basilisk node will be able to detect that it is under attack. Also, by keeping track of its own unspents locally in long term storage, the attacker would need to control all the nodes all the time for a particular basilisk node....
Under such assumptions, any p2p network can be fooled. There will be reference SuperNET nodes that people can add to their peer list which will at least allow attacks to be detected.
Your zero fee attack makes me that much more inclined to go to aggregated fee sharing via basilisk voting, ie basilisk nodes reward the fastest iguana nodes that respond and also track nodes that are giving conflicting data