An Atomic Swap through a Basilisk <-> Basilisk Mode

I changed the basilisk lower level code to use the new DEX* API as it is much much faster and supports [“KMD”, “BTC”, “USD”, “EUR”, “JPY”, “GBP”, “AUD”, “CAD”, “CHF”, “NZD”, “CNY”, “RUB”, “MXN”, “BRL”, “INR”, “HKD”, “TRY”, “ZAR”, “PLN”, “NOK”, “SEK”, “DKK”, “CZK”, “HUF”, “ILS”, “KRW”, “MYR”, “PHP”, “RON”, “SGD”, “THB”, “BGN”, “IDR”, “HRK”, “REVS”, “SUPERNET”, “DEX”, “PANGEA”, “JUMBLR”, “BET”, “CRYPTO”, “HODL”, “SHARK”, “BOTS”, “MGW”, “MVP”]

Since that includes both BTC and KMD, it means a node can quickly get up and running. Of course, if possible, it is always better to run the fullnode locally, but somethings that isnt possible or practical (or convenient).

As I wrote before, there are 3 different modes a coin can be in as far as iguana is concerned: native coind, iguana full mode, and basilisk mode. The latter is now using the DEX* API and will only work with the above coins.

To do a DEX swap, that is 3×3 combinations and the hardest is a basilisk <-> basilisk as all the info needed to construct the rawtx must come from a remote node. It does all the tx signing locally though and it also queries multiple nodes for the most sensitive information (value of utxo) and with all signing done locally, by the time it is transmitted to the network it is a fully signed tx

The swap: MVP <-> USD

Setup LP node:
cd tests
./paxfiats 1
cd ..
curl –url “” –data “{\”agent\”:\”bitcoinrpc\”,\”method\”:\”walletpassphrase\”,\”password\”:\”putpasswordhere\”,\”timeout\”:86444}”
curl –url “” –data “{\”agent\”:\”tradebot\”,\”method\”:\”amlp\”}”
curl –url “” –data “{\”agent\”:\”tradebot\”,\”method\”:\”liquidity\”,\”targetcoin\”:\”MVP\”,\”vals\”:{\”rel\”:\”USD\”,\”bid\”:0.09,\”ask\”:0.11,\”maxvol\”:100}}”

The LP node needs to load USD and MVP chain, login to a specific wallet, notify iguana that is it an LP node with “amlp” API and then submit liquidity commands. In this case a bid 0.09/ask 0.11 for MVP/USD

Setup client node:
cd tests
./paxfiats 1;
cd ..

The client side is simpler, just need to load the 2 coins and login to a wallet.

Additionally, both sides needs to make sure it has enough utxo to complete the atomic swap. there are fees to pay, an extra deposit for the “bob” side, so it is recommended to have a common transaction size utxo and to make a set of them:

fiat/usd sendtoaddress <youraddress> 1
fiat/usd sendtoaddress <youraddress> 1
fiat/usd sendtoaddress <youraddress> 1
fiat/usd sendtoaddress <youraddress> 1
fiat/usd sendtoaddress <youraddress> 1

Now we are ready to start the DEX swap with the client side doing:
curl –url “” –data “{\”agent\”:\”InstantDEX\”,\”method\”:\”request\”,\”vals\”:{\”source\”:\”MVP\”,\”amount\”:0.1,\”dest\”:\”USD\”,\”minprice\”:0.09}}”

This command is sent to the DEX network and the LPnode sees that it fits its requirements and it responds with an offer. The client node waits for 5 seconds and accepts the best offer that has at least its minimum and the atomic swap protocol is started:

sendrawtransaction myfee.(4bf13c090d388d246b6425bc15faaa8be93d392d563310ca40fb1e03100dec25)
sendrawtransaction myfee.(2e83dd0efd58fd1b0c485f1e3d57747c8f1ca569413e737a2536e9343abb5965)

sendrawtransaction bobdeposit.(85972780232abf5d8e146f2fc868c19b35d2c207da8289a86540c13fe29aaa54)
sendrawtransaction alicepayment.(52c2cfdabb159e0dd88351008b4b49300a876c563a03eed3094d4372a24610fa)
sendrawtransaction bobpayment.(28bfd8d8be5ba3dda86e2db81438f04da026ce9ab8545c1eaf570134130427f1)
sendrawtransaction alicespend.(c4975c90929691b28181eb2439c40f6207355b0b1e790e4fd0cd6ed92069821a)
sendrawtransaction bobspend.(18441848573d7d145754078a0d904d91c1f45ec24188655d2a5ffb88567c7bbc)
sendrawtransaction alicereclaim.(e535d78c4cbf6970a71933db08f3c1240594792f61457baacff4d889ad7bdf37)
sendrawtransaction bobrefund.(8c6b1524caa1f58f5a644ead14cb96290ea274215621cba6da7935e273d08e0e)

Still a few issues, in this case only the MVP transactions made it to the blockchain, need to see why the USD ones didnt. But it is almost ready for GUIfication. Once the basic atomic swap is automatically matched and completed, then it will still need a lot of error checking and especially recovery from the error states. I estimate 95%+ of DEX transactions that are started will complete properly.

At this point I dont think we will have a DEX GUI completed when mainnet becomes official, but as you can see the low level command line level is functional even with basilisk <-> basilisk

Fixed the bug on failed remote sendrawtransaction. Here is an automatically matched and completed DEX:

sendrawtransaction bob myfee.(b63921288ae1e95a86784d64f3b20d0579479fa64bcaf986e962fa9f45ec0ceb)

sendrawtransaction alice myfee.(b0fc0614ab06cb1e919a62ec0157d990820fef33f7e82ee5139e2829ec097f06)

sendrawtransaction bobdeposit.(e871c601d81c3d7a0fbe5be75299941378a106249bc58498a6d0dd1e510b301d)

sendrawtransaction alicepayment.(4b7bf772e4cca57de257121f1aa3165898e3d0006b31f9fd57db60149cd0c1f0)

sendrawtransaction bobpayment.(97bd46d2bbd802722aac11da2426463be2f753a4298f361e1ac28a88d44b44f1)

sendrawtransaction alicespend.(ea61c789f75d7bbe93faf0e5690d2a5ccafda4696ab754f2b7af7a6367146b18)

sendrawtransaction bobspend.(395ede337f84a99f5ba33d152263d6a5f5314d1cd823fecb956f324ac25083a6)

Refund of deposit

sendrawtransaction bobrefund.(00478df7ff5f9571014976a5968d91f293e27486e7ebba5b815adc354d9337f0)

[See the original bitcointalk post for the complete code blocks]

Failure of reclaim (this is good as alice spent her half):
sendrawtransaction alicereclaim error.({“result”:null,”error”:{“code”:-26,”message”:”18: bad-txns-inputs-spent”},”id”:”jl777″}

automatched DEX trade completed properly and all required transactions got confirmed in their respective blockchains. At no time was either party in a situation where they are exposed to large financial loss. There are some edge cases that a statistical process uses to make it so that anybody that tries to cheat will end up losing money and the other party will benefit from these losses.

All the other deployed DEX implementations I know about use an intermediate token and only partially decentralizes the process. Trust is required in the issuer of the token and while this is a step up from a central exchange, as the token issuer is not involved in the exchange process directly, it is a single point of failure. MGW distributes this single point to multiple, but still having an intermediate token is one token too many.

When people want to trade A <-> B, there is no room for C.

iguana’s native DEX allows this direct A <-> B trading. One structural issue with a native DEX is what to do with partial fills. In a central exchange, this is not any big problem, but with a native DEX, each swap between two accounts takes the same amount of transactions, regardless of the amount swapped. And due to the increased transactions needed the txfees can easily dominate. That is no good for anybody but the miners, but it also bloats the blockchain with small transactions.

What I came up with is the LP (liquidity provider) node auction. It is a fill or kill auction that the end user node starts and the LP nodes need to fill the entire order to make a valid offer. By this method, partial fills are sidestepped. Basically all the swap will happen or none of it.

The end user realtime auction acts a bit like a market order, but you can specify the minimum price you will accept so there is no danger of getting a large amount of slippage. And the end user node will find out in seconds if there is any LP node that will fill the order. Even if it takes a while (bitcoin confirmation time if BTC is involved) to finalize the transaction, having another party initiate the other side is a very good indication that the trade will complete.

To put long term bid/ask prices, you do need to run an LP node. However, via the basilisk mode you can be an LP node without having any coin running locally. If you will be an active market maker it is strongly advised that you run all coins locally, but if you just want to place occasional bid/ask orders you can invoke the LP node mode for this without having BTC locally. You will have to keep your node online for the duration that your bid/ask is active, or in other words if your node goes offline, so does your bid/ask. The reason is that there is no central server and your node is responding to the realtime auction requests.

OK, so now you ask about privacy. A good question, but there is a layer in between all traders. While logically, a trade is between end user node <-> LP node, under the hood, it is actually like this:

end user node <-> DEX network <-> LP node

The DEX network is comprised of the notary nodes that run an interleaved PUB/SUB network along with a REQ/REP service. This allows for a single request to be submitted to the DEX network and have it propagate not only to all other notary nodes, but to all subscribers to the DEX network (active end user and LP nodes). The communications between end user and LP node is via pubkey only. Also the networking code we use does not tag the packets with the originating IP address, so in order for IP <-> pubkey to be correlated, the attacker will need to compromise a notary node or compromise a router that is in the path of the notary node and your node.

While this is a possibility, it is unlikely that snoopy neighbor will be able to achieve this. However, do not assume it has any sort of perfect privacy. Best to assume it is somewhat public and to use JUMBLR to achieve privacy after you have DEX’ed and obtained the crypto you want.

Before you ask, JUMBLR is not yet, but it is planned for this year along with PANGEA and getting the other assetchain services online. I have a feeling, along way to a full pangea solution, I will create some decentralized gaming infrastructure, so there could well be other reference apps that feed into the BET asset. I also plan to run a “house” tradebot whose trading profits will flow through the BOTS assetchain and BOTS also gets a percentage of the DEX fees. MGW also gets a cut of the DEX fees. For HODL and SHARK which are just holding other cryptos, I think it makes sense to have a market maker that provides liquidity at close to the NAV. the CRYPTO asset is getting the notarization fees and will also get pax fees. REVS then gets a percentage of several of these assetchains, but SUPERNET is what will get a much larger percentage of most of these.

It has been a long time in development, but with KMD, all of the higher level services can now be implemented securely and so this year will be about getting those paying out dividends and from there we can continue to work toward increasing the revenues across the entire spectrum.

For those of you that have followed me for all the three years I am in crypto, you might have noticed that the last months that I am less productive than usual. I have had a personal issue that has caused this, but now it is mostly solved, so I hope to get back to full productivity soon. Luckily the timing of this was when I wasnt the critical path for the project, so there was little ill effect from it to the schedule. However, I dont expect to have to go back to the 16+ hours per day/7 days per week level as the SuperNET project is now much larger than just the core code. I will do my best to not be on the critical path and continue to complete the SuperNET vision.

Bitcointalk topic entries: 1, 2

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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

two × 4 =