James' Posts

easydex

#1

Here are some technical notes on native DEX to give an idea of what needs to be tested:

At first we need to do more clearbox testing as opposed to blackbox testing. by understanding what is supposed to happen internally, it will be easier to make sure it actually is and when that is solid.
there are two totally different (complicated) parts to the native DEX. Ordermatching and the atomic swap itself
In a decentralized exchange, just knowing what the orderbook is becomes complex. Here we have LP nodes (acting as servers to a degree) and client nodes. The latter need the absolute latest orderbook, but not that often, just when they want to do a trade, but of course they want it quickly
A requirement for the LP node is that anybody is able to run one, ie. permissionless. To achieve this, I made a custom p2p network. yes, yet another one, but I wanted the absolute fastest networking so decided to make my own. That means there could (are) bugs in the fundamental networking code as I read/write directly to the network ports. I combined the p2p and rpc aspects and the peers actually use the same requests as the browser makes for http://5.9.253.195:7779/api/stats/orderbook?base=REVS&rel=KMD and the equivalent. This allowed me to use the same code for the p2p networking and the rpc handling. native DEX p2p network has custom messages to propagate new peers quickly and available utxos reasonably quickly
At any given time, most of the LP nodes will have a recent set of available utxo and a very current set of peers. So, the client connects to any of the seed nodes, gets a list of peers and iterates getpeers on them to get a complete map of all the LP nodes. It is quite possible the networking can flood itself, but I did put guards against that in
the native DEX is based on utxo (pairs). the LP node needs the utxo to trade and a 13% bigger utxo to use as a deposit. The client node needs a utxo to trade and a 1/777th size one for the dexfee. A node scans its smartaddress (derived from passphrase) for pairs of utxo using a simple bestfit algorithm and creates utxopairs that can be seen locally using the inventory command
Now I am concerned that at some scale, the current design will bog down, however I have structured things to be pretty efficient. Each LP node creates a pub/sub nanomsg socket along with a push/pull pipeline socket. The former is used for sending out data (and commands) the latter for receiving requests. Both channels are fed through the RPC command processor, so typically a matched pair of “method” fields are used similar to “ping” -> “pong” response
Since the nanomsg pub/sub was designed to broadcast to a very large number of nodes, it should be able to handle thousands of client nodes. However, to maximize data propagation, all the clients are connected to all the LP nodes. with 10 LP nodes now, this is not an issue, but it could become one if we end up with hundreds (or thousands) of LP nodes
any node can request from an LP node about peers and utxos and prices, whenever any node does, the LP node publishes the answer and since all clients (and LP nodes) are subsribers to all LP nodes, the original requestor along with everybody else will get the data. This makes it so that a lot of times all the required data is available client side automatically
To receive requests, all nodes connect to a one stage pipeline with a single provider, a specific LP node. this serializes the request stream from all other nodes into a specific LP node. Most requests are about peers, utxo and prices, but there are a few special ones that start an atomic swap
Since we are swapping specific utxo, it can only be swapped with a single party. This means we need to create an exclusive lock on that utxo for sale. Of course it needs to be time limited to prevent the orderbook from being locked. The “price” command and “request” command are nearly identical, the latter just provides a 60 second lock for the requesting party to “connect”. Since the information is broadcast publicly, it is possible for some other node to jump in and establish the connection. However, in some sense the native DEX is a free for all, first come first served, so this is in the spirit of the DEX operation
the “connect” command makes sure a utxo was properly reserved and if it was it creates a nanomsg NN_PAIR socket, which has the nice attribute of being limited to two connections, one immediately being taken by the LP node. This assures exclusivity of the connecting client node during the atomic protocol and further that only one party at a time is trading any specific utxo. At least on the LP node side. It is possible for an evil client to try to trade the same utxo to multiple LP nodes, but the blockchain will prevent such double spends
In my tests, I am seeing the above process of fetching the utxos, getting prices, requesting and connecting happens essentially instantly
Once the atomic swap protocol starts, I set it up like railroad tracks, basically it can only go along a single path, or derail. This dramatically simplifies all the possible errors that can happen during the atomic swap.
https://bitcointalk.org/index.php?topic=1364951
discusses the protocol details for the atomic swap itself. It is quite difficult to understand, so I will try to simplify
bitcointalk.org
Atomic swaps using cut and choose
Atomic swaps using cut and choose
In order to prevent spamming, the client node must pay a dexfee (1/777th tradesize) to assure the LP node that he is serious. Putting an actual financial cost has the advantage in that it removes spammers at the first step and also it creates a revenue stream for our patient investors. There is an implicit assumption that LP nodes are more reliable than client nodes. Even before the dexfee is sent, the two nodes use the cut and choose protocol to perform a key exchange and create a trade specific set of addresses that will be used. Once this is done, then the dexfee is sent. Once the fee is verified to have been sent, the atomic swap starts for real. By convention the two parties trading are Alice (client) and Bob. Bob has the burden of providing a deposit in the protocol. To compensate, Bob has no dexfee at all, just the coins txfee.
Bob first broadcasts a deposit. Alice waits for this to be confirmed. By waiting for the coin confirmation, the nature of the protocol avoids malleability issues, other than the generally annoying part about malleability where the txid you expected is not what ends up in the blockchain. Alice then sends a 2of2 multisig to Bob, Bob can verify it is to the right address that he will be able to spend, but he cant spend it yet
Bob then sends his payment to Alice, who is able to spend it immediately and by doing so has to divulge the information Bob needs to spend the 2of2 multisig.
As soon as the three initial transactions are sent to the blockchain(s): bobdeposit, alicepayment, bobpayment, the trade is locked, both parties know they will get at least what they agreed upon, in cases where one side doesnt do what they are supposed to, the other party can get even more
for each of the three payments, there are two outcomes: bob spends it or alice spends it. The mainstream sequence is:

  1. bobdeposit 2. alicepayment 3. bobpayment 4. alicespend 5. bobspend 6. bobrefund
    however at any point, the sequence can stop due to disconnection or intentionally. You will see that regardless of what point it stops at, the result is acceptable:
  2. alice will eventually claim the deposit when it times out in some hours
  3. bob can refund his own deposit and in doing so allows alice to reclaim her payment. if enough time elapses, alice can spend the bobdeposit and give bob the information to spend alicepayment
  4. after timeouts, bob can reclaim his deposit and payment
  5. alice is happy at this point and can collect even more via spending bobdeposit
  6. there is no reason for bob to leave the transactions for alice to reclaim
    The above is a very high level description and the reality has a lot of subtle details to make it all work. Happy hunting for bugs

#2

10:07 <jl777> updated native DEX protocol, if you havent updated very recently, you need to update to be compatible
10:07 <jl777> I added pubkey addressing!
10:07 <jl777> so now you can send messages to any node (theoretically) via pubkey
10:08 <jl777> example scripts forward and pub
10:08 <jl777> the latter is to use an LPnode to broadcast a JSON object, no real restrictions and parsers will be added to make it more than a string level transport
10:09 <jl777> also inventory now returns both a bob:[] and alice:[] array
10:09 <jl777> to forward, you specify the destination pubkey and a method2, which will become the method on the destination node
10:10 <jl777> by using a special method2 of “publish”, it tells the destination node (if and only if it is a LPnode) to broadcast to all its subscribers
10:10 <jl777> very new code, so can have bugs
10:12 <jl777> the first RPC return JSON has your node’s pubkey, so you can tell the other nodes what pubkey to use
10:13 <jl777> the forward/publish method has a little bit of IP privacy, but the LP nodes will know the mapping from pubkey to ipaddr, so do not rely on this to provide any strong privacy! anybody can run an LP node, so it just prevents all clients from having your (pubkey/ipaddr) broadcast to them
10:13 <jl777> however in order to make efficient atomic swaps, I do send your node’s ip address to the network, so again do not rely on DEX to provide any privacy
10:14 <jl777> the way to get and keep privacy is to use JUMBLR and then use a different IP address to DEX the jumblr’ed funds. Nothing else will do
10:15 <jl777> I have not tested the pubkey based atomic swaps yet, as I wanted to get the basic pubkey comms solid first. that is next on the list, but all other than actual autotrade should be working. I know of only one bug


#3

19:12 <jl777> finally got things reasonably stable
19:12 <jl777> client side posting of prices appears to work, at least user utxo gets into orderbooks
19:13 <jl777> i havent tested client <-> client, that should work, so go ahead and test it between two different people, would help me to know if that works or no
19:13 <jl777> what is left is to optimize the ordermatch process, and then to fix all the bugs
19:13 <jl777> but so far there are not many bugs found and only 1 reported
Thursday, June 15th, 2017
09:17 <jl777> @andb68 the LP nodes are up and running
09:17 <jl777> First thing you need to do is get komodo and iguana installed
09:18 <jl777> I believe there is a guide somewhere about how to do this, but not sure where
09:18 <jl777> once you have native komodod synced, then run assetchains
09:18 <jl777> optionally, you can start syncing BTC and/or LTC, but for now we can test with a purely KMD native setup
09:19 <jl777> once all the assetchains are in sync and you have built iguana, then from the iguana exchanges directory, you can build the marketmaker client
09:19 <jl777> use the iguana/exchanges/client script, you need to edit the randval file and put in a decent passphrase
09:20 <jl777> run the client script
09:20 <jl777> issue a getpeers command using the getpeers script
09:20 <jl777> the first time your run it, it will return a special JSON object with the “userpass” and “pubkey” for your passphrase
09:21 <jl777> put the userpass value in the userpass file (or equivalent)
09:21 <jl777> I usually make copies of the scripts in a different directory so git wont complain when I do a new pull about modified files
09:21 <jl777> you need to pass in the userpass with each localhost api request, so I made simple scripts that take care of that
09:22 <jl777> with a copy of al the scripts and customized randval and userpass files you can issue all the commands
09:22 <jl777> there is a help command that you can issue to see all the documented api calls, there are also some that are not documented
09:25 <jl777> hopefully somebody can make an easy to follow document out of the KMD install, iguana install and native DEX setup @rick
09:40 <jl777> I recently setup some new nodes and the following is from memory:
09:40 <jl777> sudo apt-get install build-essential pkg-config libcurl3-gnutls-dev libc6-dev libevent-dev m4 g+±multilib autoconf libtool ncurses-dev unzip git python zlib1g-dev wget bsdmainutils automake libboost-all-dev libssl-dev libprotobuf-dev protobuf-compiler libqt4-dev libqrencode-dev libdb+±dev ntp ntpdate
09:40 <jl777> wget https://github.com/nanomsg/nanomsg/archive/1.0.0.zip; unzip 1.0.0.zip; cd nanomsg*; cmake .; make; make install
09:40 <jl777> git clone https://github.com/jl777/komodo; cd komodo; zcutil/build.sh -j8
09:40 <jl777> <make minimal komodo.conf file> ->~/.komodo 09:40cd ~/komodo/src; ./komodod -addnode=78.47.196.146 & 09:40<./komodo-cli getinfo to make sure it is getting blocks>09:40cd ~/SuperNET/iguana; ./m_LP; cd exchanges; ./m_mm 09:4009:40<lunch break while KMD completes sync, wait for it to reach the realtime blocks>09:40cd ~/komodo/src; ./assetchains 09:4009:40Now you should be ready for native DEX testing. Also the first JSON return has the smartaddresses for all the coins. Send some small amounts to the smartaddresses so you have something to test with. Ask for some coins if you dont have them 09:41@noashh can you make a support.supernet.org entry out of the above with a heading "how do I setup a node for command line native DEX" 11:47 grewalsatinder set the topic: https://github.com/SuperNETorg/komodo/wiki/Setting-up-Liquidity-Provider-(LP)-Node http://pad.supernet.org/LP-Node | asset 17571711292785902558 https://sprnt.slackarchive.io/tradebots/ 11:47I added LP node setup guide link to channel topic 12:27Latest version is ready for orderbook testing 12:27everything should be automatically syncing to all peers (LP nodes) and you can verify with the getpeers script 12:27all utxos and all prices are also synced, which can be checked with getutxos and getprices functions 12:28however, all a node really has to do is issue an orderbook api call and it returns the realtime orderbook without any network load as it is a local call 12:28setprice to set your price for your utxos (if any) 12:29and everything else is automatically updated, without network flooding. At least that is what we need to test. to make sure orderbooks are properly generated, that setprice is properly propagated 12:29notice that base/rel is inverse of rel/base as far as prices go 12:29however a setprice is based on a specific base -> rel and you are saying you want to sell base for rel at the specified price
12:30 <jl777> a buy for rel/base at the inverse price is equivalent to sell base/rel at price
14:19 <jl777> All aspects of native DEX other than the actual autotrade has worked in at least one case
14:19 <jl777> that means orderbooks are propagating
14:19 <jl777> each node’s prices are propagating
14:19 <jl777> and it all seems pretty instant at the orderbook level
14:25 <noashh> @grewalsatinder is the github LP node setup link as up to date as what james wrote? Could you merge the 2 versions?
22:44 <grewalsatinder> The matket maker steps are not mentioned there. Other things laed to all setup and compile till point marketmqker and then lead to ugly gui
22:44 <grewalsatinder> @noashh
22:46 <jl777> currently the bittrex marketmaker part is disabled, just use the run script for the LP node side and the client script for the client side
23:21 <noashh> grewalsatinder: so that means we can use either your guide or what james wrote and it will have the same result? ie. james mentions to wait for assetchains sync and I did not see that on github.
23:24 <noashh> And what about http://wiki.supernet.org/wiki/Market_Maker ? Is that the version that other guy wrote?
00:00 <grewalsatinder> Github is not updated with command line instructions for mm
00:00 <grewalsatinder> Those are in james guide
00:00 <grewalsatinder> I’m in flight. Ablut to take off
00:01 <grewalsatinder> Cmd changing, so a lot of iterations will happen. For now good to follow James text dex api file
00:03 <grewalsatinder> Media wiki can be updated by documentation writers :slight_smile:
01:26 <noashh> What is James text dex api file?
01:26 <noashh> I know james text from #tradebots, the github entry and the mediawiki entry
03:58 <xrobesx> @jl777 my LP node is all setup running everything. The kmd address linked to the iguana passphrase has lots of 100, 10, .001, and .0001 utxo inputs.
03:58 <xrobesx> http://kmd.explorer.supernet.org/address/RBvkZ1E141Q5fDYbtZZTMDSvcQBgns5Xr1
03:58 <xrobesx> But whenever I do the ./utxos script in exchanges, it gives me: [ ]
03:58 <xrobesx> What scripts should I be running now for testing? Or specifically which addresses should I be sending to?
04:00 <xrobesx> I originally started with ./client to get the userpass value and the smartaddresses output, but then I closed it and restated with ./run after inputting the userpass
06:33 <jl777> put your iguana passphrase in the randval file that the run script uses
06:34 <jl777> marketmaker is 99% independent from iguana, it is actually a morphed clone of iguana inside
06:34 <jl777> so the iguana passphrase is totally irrelevant to marketmaker, it uses the passphrase from the command line JSON
07:09 <xrobesx> Yes I have my passphrase in randval and my userpass in the userpass file. And I ran it with ./run. What exactly do I need to be doing now to test?
07:28 <jl777> most important now is to see quotes from one node appearing on another
07:28 <jl777> if you do an inventory command, it will show the utxo you have ready to trade
07:28 <jl777> myprices command shows your prices
07:29 <jl777> help shows all the available commands
07:29 <jl777> setprice sets the price
07:29 <jl777> orderbook displays an orderbook
07:29 <jl777> so the question is if all the api calls work properly. all other than autotrade are approved for testing and have worked in at least one case
07:30 <jl777> if RBvkZ1E141Q5fDYbtZZTMDSvcQBgns5Xr1 is the smartaddress that appears when you do the first api commands then it should appear in inventory
07:30 <jl777> as a client your node will connect to the peers but wont become a peer
07:31 <jl777> as an LP node, your node will become a peer but will only be able to be a maker and not a maker and taker like the client nodes can
07:32 <jl777> i am most concerned about having some inverted prices, as that is a big monetary loss if any such bug is allowed to remain
07:33 <jl777> orderbooks are totally arbitrary, can be anything/anything, the convention is base/rel means the price in base to get the (volume * price) of rel
07:33 <jl777> rel/base has inverted price and the volume is also adjusted, whether properly or not, I am not 100% sure yet
07:34 <jl777> to test connectivity issues of a new LP node is also needed
07:35 <jl777> basically find bugs in the api wherever they are, but most importantly with the orderbook. everything about trading relies on the orderbook, so if the orderbook is wrong, the trading will be wrong. if the orderbook is right, that is the only way to have a chance for proper trading
07:35 <jl777> with native DEX it implements a money multiplier function. Not literally, but effectively.
07:36 <jl777> On all other exchanges, if you have 1 BTC and you want to buy 10 other coins, you have to split that BTC into 10 parts
07:36 <jl777> with native DEX, you can reuse the same utxo as many times as there are other coins to bid on!
07:37 <jl777> each offer is actually a base->rel ask (just flip the orientation to get prices the way you are used to) and it is fully backed by the utxo 07:38but with the understanding that any utxo can disappear at anytime (disconnection, being spent, etc), it is the similar logic to handle making multiple offers with a single utxo. As soon as it gets involved in a trade, it will disappear from the orderbooks (must be verified) and if an atomic swap doesnt complete, it will reappear 07:38the orderbooks are dynamically created with the then current set of utxos and prices from nodes (pubkeys) 07:39so you can set prices you want to trade at independent of whatever utxos you have. Then as soon as appropriate utxo appears in your smartaddress, all nodes in the network will display your (utxo + price) in their orderbooks 07:40network bandwidth usage is close to optimal, without any polling except for latest peers between LP nodes 07:41in my tests I am seeing essentially instant updates from when I setprice on one node to all the other nodes, but I am testing with nodes all in a single data center, so in reality it will be delayed by a ping time 07:43native DEX not only allows you to always control your funds, it also allows you to make offers in parallel for all your utxo. this is a liquidity multiplier. So, if you have half a dozen coins you are following and have a desired entry price below the current market for each one, you can set that price for all coins and automatically all your corresponding utxos are appearing in each of the orderbooks. Instead of having to guess which coin will drop 20% to hit your offer, the first coin that drops 20% will hit one of your offers. So, this feature will multiply your trading profits and offers functionality that no central exchange has (or can easily reproduce) 07:44@audo good marketing materials above 07:45The only disadvantage of native DEX compared to central exchanges is that it takes longer for an atomic swap to complete as coin confirmations need to be waited for, however for a below market bid, you are waiting anyway, so this is not any big issue 07:45also, client nodes can now also be posting offers just like an LP node. and it is done automatically just like LP nodes 07:46In addition, a client node can fill existing orderbook offers using the same utxo that are at the same time posted in N orderbooks 07:47basically you dont have to lock up your funds dedicated to a specific trade. It is your money, there is no need to withdraw it as you always control it, and you can make as many trade offers as you like, even use the same funds to fill existing offers (but I prevent self trading) 07:47some internal details might help the testing 07:49I made a custom peer to peer network that the LP nodes create among themselves. This peer network is designed to propagate the list of peers, list of utxos and each node's prices among each other as efficiently as possible. It isnt a consensus requirement to have all nodes in 100% sync, but I think most of the time they should be 07:50each node has a pubkey and of course an ip address, but only the peer networking is using ip addresses of the LP nodes 07:50the orderbook is pubkey based, so each offer has the offer details and the pubkey 07:50in order to enable client nodes that have no known ip address to the network to talk to each other, I made a forwarding service that the LP nodes provide 07:53each node registers their pubkey/ipaddr to one or more LP nodes. After that, that LP node will respond positively to a lookup command when asked about a pubkey it is forwarding to. So, there isnt much ip privacy, but at least your ip address isnt posted on all the orderbooks and is mostly limited to the LP nodes. however since anybody can be an LP node, do not rely on any actual ip privacy. if you need that you need to take separate measures. Since there is no ip privacy guarantee, during the atomic swap process, the two nodes that are trading do establish a direct ip connection. Well it is using nanomsg so only the offering side is posting their ip address, but essentially it is direct ip link. Which means it is fast and reliable, only if one of the nodes disconnects will there be an issue 07:54for all the public api commands, it is possible to forward (or broadcast) it to a specific pubkey (or everyone), so this allows one pubkey to notify another pubkey that it wants to trade 07:59each node is locally polling its native coin daemons for listunspent and then pairing these up into a set of Bob utxopairs and a set of Alice utxopairs. Yes, the same utxos are used for both the Bob[] and Alice[] arrays. The Bob utxopairs have the payment + deposit utxo, where the deposit is 12.5% bigger than the payment. The Alice utxo has payment + dexfee, where the dexfee is 1/777th the size of the payment. Since it will be rare to fit these exact ratios, each utxo payment has an effective number of satoshis that is no bigger than its value. By proportioning your utxos you can minimize the amount lost in the allocation, but for the Alice side, this is a small effect as long as you have a bunch of small utxos for all your larger ones. it uses a simplistic bestfit algo, but if the best fit is another utxo of the same size, then that will be used for the feetxid even if something a lot smaller could have been used 08:00What this means is that with an intelligent set of utxos, you can get more effective tradeable funds. native DEX core does nothing about creating the utxos themselves, it is required that a layer above manages the utxos. Also all funds that appear in a smartaddress is assumed to be for native DEX. Dont send funds there you dont want to trade! 08:03Due to the efficient nature of the peer network, it has a memory of all the peers, utxos and prices. Short of stopping all LP nodes at the same time, this memory will stay intact. This is good but it could be bad if some things that should be forgotten are not. More specifically a nodes set of prices is remembered, but locally it is required to issue all the setprices on each instance. The reason is that once you setprice and if there it a matching utxo, it appears on orderbooks (actually it was always appearing even when you were offline!) and maybe you decided to change your prices and so to have it automatically trade based on old prices, I didnt like that. 08:03The above means the orderbook cannot be fully relied upon to be current. 08:08Because of this, prior to each trade, there is a mini-protocol between the requesting node and the offering node to negotiate the actual price and at this time another check to make sure all the txids are still unspent is done, along with making sure about the price. Since the prices are separated out from the utxo and they were dynamically bound via the orderbook (which is just a local overlay to the raw data) it is likely that there isnt 100% agreement down to the satoshi for any new trade. The negotiation process consists of a request call sent to the offering (Bob) node, which validates the offer and sends back a requested command to the requesting (Alice) node. When the Alice node gets the requested, she checks to make sure it is acceptable and sends a connect command to Bob, who responds with a connected. The connected return has the direct ip info Alice needs to establish a mutually exclusive pair socket with Bob. This assures only a single party can be trading for any specific utxo, granted it might not be the originating Alice node as the requested data is broadcast publicly, in a practical sense it is a free for all, so it does not violate things to allow someone to hop into a trade, but practically speaking it wont be easy for this hijacking to happen. 08:09Once there is a direct connect between Alice and Bob, they do the atomic prototol, which if it is finished creates a bobdeposit, alicepayment and bobpayment transactions onchain. Then each side can spend their payment and bob redeems the deposit, or if one side doesnt, timeouts happen and eventually both sides end up with the appropriate amounts 08:11I forgot about coins. Currently there are dozens of coins that are supported. Most are disabled, but they can be enabled with an enable command. A disabled coin can only be enabled and when disabled it is as if that coin is not there. getcoins command will list all the coins 08:11To add a new coin, just a small amount of info is needed 08:11{"coin":"LTC", "name":"litecoin", "rpcport":9332, "pubtype":48, "p2shtype":5, "wiftype":176, "txfee":100000 } 08:12the equivalent to the above is all that is needed to add a coin to native DEX. For many coins we already have this data, for others it is usually available in chainparams.cpp file 08:16iguana/exchanges/LP_commands.c is the file with the commands parser, the definitive list of commands is whatever that file implements, even if you cant read C code, it should be mostly understandable as it uses literal strings for all the commands. If you have a question about how to construct an api request, look at the examples in the iguana/exchanges directory and combined with the LP_commands you have all you need to get a complete set of api functions. Some are internal ones used for forwarding responses and trade reservations, so not all are appropriate to issue from command line. I think I put all such api requests in the help output: 08:16available localhost RPC commands:\n \ 08:16setprice(base, rel, price)\n\ 08:16myprice(base, rel)\n\ 08:16enable(coin)\n\ 08:16disable(coin)\n\ 08:16inventory(coin)\n\ 08:16autotrade(base, rel, price, volume, timeout)\n\ 08:16swapstatus()\n\ 08:16swapstatus(requestid, quoteid)\n\ 08:16public API:\n \ 08:16getcoins()\n\ 08:16getpeers()\n\ 08:16getutxos()\n\ 08:16getutxos(coin, lastn)\n\ 08:16orderbook(base, rel)\n\ 08:16getprices(base, rel)\n\ 08:16register(pubkey,pushaddr)\n\ 08:16lookup(pubkey)\n\ 08:16forward(pubkey,method2,)\n\ 08:16forward(pubkey,method2=publish,)\n\ 08:16forwardhex(pubkey,hex)\n\ 08:16let me know if I missed any. 08:17Above should be enough information to create nice documentation. Please do not complain that native DEX has no documentation. @vanbreuk hopefully some tech writer can make the above easily accessible 08:23Noashh just gave me a wiki account. I will take all of this information and document it there 08:23Thank you for all of that james. Greatly appreciated 08:24if any questions, just ask, native DEX is quite complicated on the inside, but I spent a lot of time to create as easy to use outside api as possible 08:24the last api function I am debugging now is the autotrade, which is passed in base, rel, price, volume 08:25it calls orderbook internally and starts a negotiation with the best available offer. I need to make it a bit smarter and to have it deal with not establishing contact with the best offer better than just reporting failure 08:26you can use the inventory to get a list of all your utxos and getutxos to get the global list.currently the REVS/KMD orderbook has a bunch of entries 08:26but you can enable any coin and create utxo, setprice and orderbooks for that coins should magically appear 08:26this i have not tested, but since I am not doing anything REVS specific, it should just work 08:27and REVS/KMD is just one of the REVS orderbooks, REVS/anycoin can be created just by issuing a REVS/anycoin orderbook command 08:28it gets confusing really quickly with base/rel vs rel/base, but if you go back to KMD/BTC pricing it should be the familiar sats pricing one way and some large multiplier (basically coins per BTC) the other way 08:29I havent validated the volumes that appear in the orderbooks and it could well be off by the price multiplier, or upside down or some other bug. The native DEX is my sixth rewrite/port/refactor of the DEX. Written from a baseline iguana cloning/port and all contained in the LP_*.c files in the exchanges dir 08:31The networking uses nanomsg extensively, pair socket for atomic swaps, pub/sub for LP nodes broadcasting to all the client nodes, push/pull for sending commands to a node. Also, the iguana http commands processor is used to an almost REST type of interface is available using URL and at the same time POST via curl can be used, or a push into the nanomsg. All paths lead to the same commands processor. One unexpected thing is that the p2p port and the rpc port are the same as I use the rpc commands as the p2p messages. 08:33http://127.0.0.1:7779/api/stats/help works the same as a curl --url "http://127.0.0.1:7779 " --data "{\"userpass\":\"$userpass\",\"method\":\"help\"}" 08:33and you can access the public api by changing the localhost to an LP node's ip address 08:35[{"ipaddr":"5.9.253.201","port":7779,"profit":0.01010000}, {"ipaddr":"5.9.253.200","port":7779,"profit":0.01041000}, {"ipaddr":"5.9.253.196","port":7779,"profit":0.01018000}, {"ipaddr":"5.9.253.204","port":7779,"profit":0.01051000}, {"ipaddr":"5.9.253.195","port":7779,"profit":0.01098000}, {"ipaddr":"5.9.253.203","port":7779,"profit":0.01049000}, {"ipaddr":"5.9.253.197","port":7779,"profit":0.01029000}, {"ipaddr":"5.9.253.198","port":7779,"profit":0.01023000}, {"ipaddr":"5.9.253.202","port":7779,"profit":0.01069000}, {"ipaddr":"5.9.253.199","port":7779,"profit":0.01076000}] 08:35above are the main LP nodes 08:36http://5.9.253.201:7779/api/stats/help 08:36http://5.9.253.201:7779/api/stats/orderbook?base=REVS&rel=KMD http://5.9.253.201:7779/api/stats/orderbook?base=REVS&amp;rel=KMD 08:37curl --url "http://127.0.0.1:7779 " --data "{\"userpass\":\"$userpass\",\"method\":\"orderbook\",\"base\":\"REVS\",\"rel\":\"KMD\"}" 08:37curl --url "http://5.9.253.201:7779 " --data "{\"userpass\":\"$userpass\",\"method\":\"orderbook\",\"base\":\"REVS\",\"rel\":\"KMD\"}" 08:38to make a url, just do the field=value&field2=value2 with the first thing after api/stats/being the method field 08:43Sounds good. This should be enough info for quite a large page or 2 on the wiki 08:43Getting late here. I'll start on that in the morning 08:50As far as what type of node to run, the LP nodes are able to do direct networking due to their published ip addresses so they have a speed advantage over pubkey based client nodes. The atomic swap protocol requires the Bob (maker) side to post a deposit, so half the funds are tied up in deposits (of course multiplying it N times makes up for this!). The Alice side pays a dexfee of 1/777 so 99%+ of funds are used, but the Alice side incurs that 1/777 dexfee that the Bob side doesnt. Now currently the BTC txfees are quite horrible and could easily dwarf not only the dexfee, but the total payment amount! So all calculations are totally skewed for BTC 08:53I see a question on BTT about managing the utxos. That is external to the native DEX. So you can manage it just by sending utxo into your smartaddress. It acts like an exchange deposit address. Of course you can use the same passphrase in agama or swing wallet and just directly spend the funds at any time. So "managing" is a matter of sending/spending to the smartaddress. I imagine some fancy graphical interface can be made with slider bars to trigger sends, but really, just sending multiple 100 KMD transactions to the smartaddress, along with 1 KMD (for the dexfees) and you are ready for trading in 100 KMD lots 08:55As far as earning fees, it is expected that LP nodes are run by people who own the DEX (or JUMBLR or BOTS) assets and out of self interest they will keep an LP node running. Of course making the spread is always a nice income if you can manage (or dont care about) the overall market fluctuations 08:55https://bitcointalk.org/index.php?topic=1605144.msg19589608#msg19589608 08:57` above shows a chart of revenue flows. As you can see the DEX asset is a key engine for revenues, and SuperNET owns about 25% of DEX, JUMBLR and BOTS and will get a combined revshares from all of them. Of course you can own these assets and not run any LP node, but when we have an easy to use GUI, it shouldnt take too much effort to provide some liquidity to make the spread (not fees). Also, non-KMD coin communities are expected to be running their own LP nodes to provide native DEX liquidity for their coins