To be honest it s difficult to hide my excitement for this trustless liquidity pooling.
I feel it s the counterpart of bitcoin mining pooling. The difference is the scale: The number of participants is potentially much higher. All you need is a raspberry pi and some cryptos assets.
2 Likes
Not really sure what happened to the server over night. It restarted automatically but didn’t post why it crashed … I’ll look into that. Also note that the user balances are fully recoverable from the log files, a server crash therefore only displays a wrong balance for up to 24 hours but the payment should be correct. I’ll see if I can improve that.
Much more important the crash showed that the client acted very poorly in this situation. I pushed an update which makes the client’s behavior better:
- (Almost) all connection attempts have a timeout and return an error if it is reached
- The client shuts down the trading bot once the server is unreachable for more than 5 minutes
The client then continuously tries to reconnect and restarts the trading bot once the server is reachable again. Of course, as always, the user has to take care about tier 2 <-> tier 3 movements and I am also not planning to change that.
It may happen that some NBT (not necessarily related to your balance) show up on your addresses later today but in general this all is still without payment. As mentioned by @willy payed beta runs are planned but since I am paying them out of my pocket I also want to ensure that the data and experience I am gathering during that run is worth it, so a couple of things have to be set up in advance.
1 Like
There should be only one pool or LPC for any pair on a given exchange, right?
i mean there will be wall collision otherwise.
The system is capable to support all exchanges and currencies at once. Interest rates for each exchange and currency have to be determined through the custodial grant proposal (an interest rate of 0% will be equivalent to no compensation for that unit and exchange).
For my planned operation I am very open for discussions about that. I would be glad if you allow me to support more than one exchange, but I could perfectly understand if shareholders first want to try a single exchange. Of course we should prefer exchanges where registration and API key generation are simple.
EDIT: So for example, the beta run I am planning to start tomorrow would contain the following information in the proposal:
- poloniex: BTC, daily interest 0.165%, target funds (ask/bid) 50.00 NBT
- ccedk: BTC, daily interest 0.165%, target funds (ask/bid) 50.00 NBT
- bitcoincoid: BTC, daily interest 0.165%, target funds (ask/bid) 50.00 NBT
- bter: BTC, daily interest 0.165%, target funds (ask/bid) 50.00 NBT
Again, the pool operator and shareholders can agree to set the interest rate and target funds arbitrarily to create a good configuration.
2 Likes
Why will this be the case? Both servers would use the same price. The only problem with multiple pool servers on a single exchange and pair is that people could submit the same order request to both servers in order to get twice the reward. It would be in the responsibility of the pool operators so synchronize the credited orders in this case such that each order will only be counted once.
Would they? Because the peg spreads are tight slight differences in prices (due to different feed, weight scheme, response time…) and distribution of prices of the wall could cause collisions, when one pool/LPC’s wall can be eaten by another’s.
All servers get the price from the same three tickers: bitfinex, coinbase, bitstamp every 30 seconds. Clients get the price for their orders from the server (they only use the tickers to verify that the server’s price makes sense).
Multiple servers therefore would need to synchronize their ticker calls (this can be done via ntp, just as NuBots do it with multiple-custodians=true), or even create a shared price representation (e.g. both grep a feed and then agree on the average).
You are right that it involves many additional aspects and I would not want to try it in the very first run. But I think that the problem itself is managable with the corresponding development effort.
Right now the client blindly would buy / sell into a wall. I agree this is not really in the intention of the customer and if orders are present at the corresponding position which would nullify the provided liquidity, then the bot shouldn’t place the order. This is also an option in the NuBot.
I gave the cliet a try from git bash window on win7 with command python ./client.py 104.245.36.10:2019 . It worked. I was able to place orders through the bot. I do often get error msgs
xxx ERROR: unable to receive balance for unit nbt on exchange poloniex: Nonce must be greater than 1426395000000. You provided 1426395000000.
xxx INFO: adjusting nonce of exchange poloniex to 105
xxx ERROR: unable to receive balance for unit nbt on exchange po
loniex: Nonce must be greater than 1426395052000. You provided 1426395052000.
xxx INFO: adjusting nonce of exchange poloniex to 155
…
When I pressed ctrl-C my order wasn’t canceled (is this a feature?). It would be nice if there is a quick command to cancel or orders.
Over all, this is really neat!
1 Like
Yes it deletes all orders on shut down (at least it tries 10 times until it gives up). In your case the nonce was too small and it would find some good offset after a while.
Hi everyone,
The tests with the payout system went sufficiently well, and therefore the payed beta started today at 4pm UTC, Sunday 15th of March. I decided to set some parameters which would differ in a real operation:
- The minimum payout is 0.03 NBT + txfee
(in a real operation this should be larger) - The server tries every hour to send payouts if the minimum payout was reached
(in a real operation this will be a 12h or 24h window)
Run the client with the this server address (NOTE THAT THE PORT CHANGED FROM PREVIOUS RUNS):
./client.py 104.245.36.10:2020
Please use the most recent client!
The server pays 7.75% per month (0.25% per day) for each exchange and order side up to 200 NBT liquidity. Payouts will be sent from BP3AVaDNHfqavNDAxGS3Puq2BqWySfMpiw which I will provide with some more funds soon. You can see that it already processed some test payouts I made earlier.
I am planning to fund the beta for 7 days and shut the server down after that. Note that other circumstances may lead to an immediate stop of the experiment at any time - your client then should automatically cancel all orders without you to take action, but please make sure that this is the case (its beta).
You would greatly help me if you would post or PM me the following information:
- The last balance shown by your client before a payout
- The amount received on your address
- Roughly the liquidity that you are providing
IMPORTANT: Please DO NOT use any large amounts of NBT in this experiment. I am not responsible for any money lost because of participating in the beta run. Furthermore the target values are small, and the server won’t pay any interest to users who provide liquidity above those 200 NBT.
Also please make a new exchange account if you want to participate. Please do not use your regular trading account.
Thanks for your support!
UPDATE: I’m sorry I had to restart the operation and changed some parameters. In order to have more of the most recent version I changed the port to 2020! So the new server address is 104.245.36.10:2020
3 Likes
In the config file, the first two parameters would be a nbt address and ‘nbt’, right ?
nbt address then ‘btc’ (without ') … you are always providing NBT liquidity so this specifies the other currency
EDIT: does it work?
I updated the original post a bit (was about time). Let me know if you have some additions to the FAQ section or other questions.
Ideally I would like to have the original idea post now as second post of this thread. Is this possible? Mods?
Giving it a try now on ccedk with 22.62620758 nbt only on the sell side.
Is it enough to get a reward?
Yes, it should trigger a payout per day. Unfortunately the server shows a very bad connection status at the moment which is why your efficiency is so extremely poor. The server is located in California NA, so maybe there are just too many Americans watching netflix right now, I don’t know.
I hope that the server performance will improve over the next hours.
I see. What is efficiency?
Your client sends 20 requests per minute and the server tries to validate them. If those requests don’t show up in time (as it is the case right now) it is not able to validate the liquidity and therefore gives no credit (this is similar to PoW mining when the shares won’t reach the server).
The server is not on more load than on recent days so I really assume (hope) it is a temporary problem on the hoster’s side.
Tks for the info.
OK the problem really appeared to be a scaling issue (sorry for blaming the American netflix watcher 
) . I replaced a component of the HTTP server module that allows more API calls and suddenly all server responses go through as intended (its even more responsive as before).
All users have an efficiency of around 100% now!
Unfortunately I had to restart the server in order so all balances are reset to 0. I’ll grep the credits lost from the log files tomorrow when I got some sleep and will send them manually.
Of course I hope this will be the last interruption, but on the other hand I am doing this to figure those things out, so thank you for your patience.
1 Like
restarted the bot. 100% accepted now…
wondering now about the difference between nubot and creonbot…
of course it s much simpler to set up creonbot but in terms of buy/sell strategies, how does it differ?
creon you should consider seriously becoming a part of nubot dev team 
1 Like