The pool now supports the following exchanges: poloniex, ccedk, bitcoincoid
(note that the nubot is unable to submit sell orders on bitcoin.co.idas described here)
The GET client API of the server shows missing requests, rejected requests and the last error for each unit
The server has a general GET method status that shows the number of validations performed, the liquidity and the current sampling. Click here for an example.
Thanks to @willy’s help we could figure out that the timing is more of a problem than expected. Fortunately the nonce turned out to be a nice parameter to overcome this issue.
The new API methods allow the client to tweak the nonce for each exchange if too many rejects or missing requests were seen. The client outputs the current balance, efficiency and orders every thirty seconds and tries to adjust the shift if necessary.
It would be awesome if we could get some more people to test the client. For Linux users its really simple:
Create a new exchange account on Poloniex, CCEDK or Bitcoin.co.id
Create API keys on their website (ask if you need help, this can be confusing)
Clone the repository: git clone https://github.com/creon-nu/nu-pool
Switch to the folder cd nu-pool/python
create a file called users.dat in the format payout-address units exchange api-key api-secret
e.g. echo "BQRKF4X8gFLyHGVeym8tuff57PcJczYPVg BTC poloniex 85BQTQG1-N3D3PFKX-YUNIHIO1-WQCWTRER 1234abc" > users.dat
run the client: ./client.py 104.245.36.10:2019
Then report if there is a problem and if not, and it outputs some balance and efficiency, then send a small amount of NBT or BTC to the exchange account (or PM me your address and I will send you some).
Running now on CCEDK.
All seems good so far. I had one instance of an invalid nonce but nothing apart from 100% efficiency for ten minutes or so now.
Good work @creon
Thanks so much. I see your missings are increasing. This could be due to a bug I fixed around 20 minutes ago, so you may want to update the repo once again and restart the client.
This would be awesome, but please not with more funds than you are using here, I really don’t want anyone to risk something. However, you don’t need to run multiple clients, just add one line for each exchange in the users.dat
excellent. I was just setting up new dat files for each exchange.
I’ll add as seperate lines instead.
The small amounts on the exchanges are there for testing NuBot anyway so I’ve effectively written them off. Happy to help with this project, it really is very impressive.
Yup, that’s me. The bitcoin.co.id comes were failing every time when I first ran the client and the nonce was being tweaked a lot.
I’ve left the client running overnight though and all sends are getting through on all exchanges. Seems the api issue has been fixed?
Thank you! I will soon start a run with (small but real) payouts, so stay tuned.
Furthermore a little update which might encourage more people to join the fun:
The client does not need to run a NuBot anymore, it places orders itself which allows to better handle the nonce problem and to distribute liquidity over different coins if required. This is currently only available for Poloniex and CCEDK, I will write the Bitcoin.co.id wrapper extension tomorrow.
With @willy’s indispensable help we could also greatly improve the search for a good nonce and clients should approach around 100% performance in less than a minute.
The robustness of the whole system exceeds my expectations and if the concept continues to evolve I am planning to implement it after the term of my current liquidity operation passed. This program is as easy to use as a miner and requires no special hardware and I believe that we could attract a very large number of crypto enthusiasts to try it.
I agree that it is easy to use. The hardest part is generating the API keys from the exchange.
I’m interested in the fact that the system no longer needs NuBot to be run by the client. Does the server run a NuBot instance? If not, does tthe client mirror the NuBot functionality.
I’m looking forward to continuing to use this system.
Just had a look at the code. ignore my previous question about the server running a Nubot instance. Your last post clearly says that the client places the orders itself.
Are there plans to add other price feeds aside from bitfinex? I know @benjyz has been implementing a price feed server for NuBot. It might be worth seeing if the price calculation can be mirrored for TIH or, eventually, if the price can be fetched from that server. Then there would be a ‘Nu Price’ - a sort of network sanctioned view of the value of ‘$1’, calculated from various different sourcesb - that can give some consitency across these services.
Other than that, it all looks really good. My only criticism would be that you said it would be 50 lines of code!
To make pool implementation easier and more robust it might make sense that NuBot would offer an API of some sorts, so that third party applications can access functionality. So NuBot would a port open and accept JSON requests, such as submitOrder(exchangeName), getOpenOrders(exchangeName), etc.
I just hit a crash. seems to have been caused by a 403 http error being retured from CCEDK
urllib2.HTTPError: HTTP Error 403: Forbidden
A restart fixed it so I assume it was just a temporary blip in the APi. I’m sure it’s already in your mind but it would be better to handle http errors more gracefully. Then 24 hour, unmanned opperation is easier.
Edit:
Another issue. It seems that the CCEDK nonce calculation got stuck. I’m not sure how it had been going but when I returned to the client it was attempting to adjust the nonce by +/- 10000, so I assume it had been going a while.
The way we handle this nonce offset in Nubot is to take the upper bound in the returned error
``must be from 1426070646 till `1426070666```. If you subtract the system time from that figure you get an offset figure compared to the local time. That offset should be good for all nonces going forward.
Can you make a website that has 1) a newly generated deposit address, 2) an input box for an nubits address, and 3) a button. If one provides a receiving address to the input box and press the button, any coin sent to the deposite address will be used in the pool to support peg, for a month, and after a month the funds will come back to the reveiving address plus reward.
Totally anonymous, trustless, automatic liquidity pool. Beats parking .
That’s basically what I am doing: https://github.com/creon-nu/nu-pool/blob/master/python/exchanges.py#L111
So if the current nonce is too large then it targets the average value of the bounds and otherwise it tries to place itself in the third quarter of the allowed range. It however still happens that it overestimates the nonce first and then underestimates it in the second round and so on. It probably should have some memory and fall back to the dumb but at some point always working method by setting
new_shift = ( (old_shift + 7) mod 200 ) - 100
Unfortunately trial and error is more or less the only option with those ideas.
Absolutely, I am trying to imitate the NuBot’s selection here. Right now the clients get their price from the server (get /price) and blindly follow it, so currently the server operator could fool the clients and propagate an invalid price. Therefore both, client and server, need to check the price and if the client sees that the server price deviates too much from the real price, then no orders should be placed.
I think you can write the client logic without NuBot functionality and statistics in about 50 lines of code. I also see the whole project here as proof-of-concept, the server client communication is far from being efficient by using json objects (compare to stratum for example). If someone wants to launch a GHash scale liquidity operation with thousands of users then a more sophisticated server communication protocol and serious development efforts are required.
This would be really great!
Of course I will not abuse my custodian address to submit pool liquidity, that would be irresponsible without the agreement of the shareholders. So if I am planning to do this then I will create a new grant proposal and ask for the OK to run this operation - and for the corresponding funds of course (after the operation).
This sounds more like a more public version of the Nu Lagoon, since the pool operator has the private keys and could run away with the coins.
The project made a lot of progress and this mostly because of the great feedback I got so far, so thanks for that! While it was originally planned only to show a proof-of-concept, the codebase developed to a concrete implementation of a working pool software package, both on client and server side, that (hopefully) is capable to be used in a large scale operation.
Every request sender on the client side and each request listener on the server side is now an independent thread (i.e. in parallel working tasks)
Better nonce adjustment with less voodoo
The client checks the price for each unit from three different price tickers (bitfinex, coinbase, bitstamp) and cancels all orders if the server price deviates too much from the ticker price
The currently final list of supported exchanges is: Poloniex, CCEDK, Bitcoin.co.id, BTER Remark: I’d love to add Allcoin to the list, but their API is still in beta and getting keys is comparably hard, so its not really worth the effort right now
All exchanges are supported by the internal trading bot
The users.dat allows an (optional) last parameter which can be set to pybot, nubot, or none in order to select the corresponding trading bot or to disable it completely
The payout system was simplified:
The price doesn’t play a role anymore in the ranking of the orders, as long as it is within the tolerance. I wanted to encourage price competition by including it into the equation but @willy pointed to some front-runner strategies that could lead to an unfair advantage. If we have an expert in game theory here then I’d be glad to talk about that in further detail.
I had to replace the nonlinear interest calculation through a step function because of numerical problems with large floating numbers in Python. So now everyone gets the full interest rate up to the targeted liquidity and 0% for everything which is provided above that value.
Last but certainly not least and too important to be written in above list is that @woolly_sammoth already made a prototype of a python based Graphical User Interface that easily allows to configure and monitor the client. I assume that he will post some screenshots when he thinks that the time is right. It will be independent of the client software itself and can even monitor remotely running clients (log data is passed via socket).
More testers are always welcome I hope to start a payed test run on Sunday with the current settings and small targets of around 50 NBT (on each side and exchange) with 5% monthly interest. It will only run for about a week. If everything will be successful then I am planning to make a second beta run with larger target values and a more public announcement (reddit etc, I could need some help with that).
Thanks for the support and stay tuned for the upcoming GUI client!
.
.