Thank you sir. I will download to try
zcash does not work in 32bits
neither does komodo
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:
1. alice will eventually claim the deposit when it times out in some hours
2. 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
3. after timeouts, bob can reclaim his deposit and payment
4. alice is happy at this point and can collect even more via spending bobdeposit
5. 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
