Trust-less liquidity pool

Sam and Willy would know that better than I.

I’ve just pushed an update to the nu-pool software that should fix the 1 NBT order bug. The issue was that the orders weren’t being cancelled before the new orders were being placed (they were when the limit was being decreased but not when increased). This may cause a slight delay in liquidity being present on the exchange under such conditions, but will mean that the pyBot places one large order using available funds rather than many 1 NBT orders.
Thanks to @masterOfDisaster for providing logs of a bot that was displaying this behavious and apologies that it took so long for me to identify and fix this issue. I have been working hard with external partners on a concpet that could lead to a much greater demand for NuBits (more on that when the time is right). I have some time now to bump the TLLP software up my priority list.
My pseudo-roadmap for the software looks a bit like this:

  • Improve the price feed code (EUR feeds have been causing an issue on @Cybnate s pool. It could do with some extra feeds being added as backups)
  • Pull all the changes that have been made on the three pools into one repository to allow users to more easily keep track of such changes and only require one peice of software (I will need to co-ordinate with @Nagalim on this to understand what has been done with the NuPond client and how best to integrate it).
  • Investigate porting the pool software to payout in NSR rather than NBT in preparation for the NSR grants available in Nu 2.0
  • Investigate whether the client can report Tier 2 liquidity available on exchange but not on order to the server.
  • Look at the tweaks that are needed in NuBot to integrate more fully with the TLLP software.

Currently the server does have logs detailing the pubkey and the contirbution of thhat account. In a speerate log there are details of the ip addresses used to connect to the server. If a server was compromised, and the attacker was able to gain super user rights, they could tie together which ips are contributing which amounts to the pool. They could then attack the ips and atttempt to gain the api private key which could give them access to the user funds on the exchange. Both Bittrex and Poloniex require that an API key pair is given permission to withdraw funds so, in most cases, the attacker would only be able to place detrimental orders with the funds.
As mentioned, I will look at disabling the logging that logs IP addresses in future pool runs so this small risk will be mitigated further.

6 Likes

Awesome!
I’ve downloaded the current version from https://github.com/inuitwallet/nu-pool, changed the deviation maximum on line 324 in python/trading.py to 0.0005 and have started a test run on the NBT/CNY pair on bter.
I’ll keep an eye on it.

edit: I ran into an error roughly half an hour after the bot was started.
First the bot toggles the bid side between available funds and 1.00 NBT and ended up at 1.00 NBT (total amount and no stacked 1.00 NBT orders!) on bid side.

Sell side seems to be unaffected.

I’ve uploaded you the bot’s log file.
Will restart the bot and see what happens :wink:

If you wire the deviation (and spread would be nice) out to pool.conf as ‘advanced trading parameters’ it would encapsulate what I have done with the cny client.

You’ve done wonderful work Sam, thank you.

Thanks @woolly_sammoth. Highly paranoid clients can also use tor or proxies to mitigate the risk.

I’m in a private troubleshooting conversation with @woolly_sammoth and from that I know that trading.py has been updated to support a “deviation” parameter in pool.conf.
If you download the latest version from https://github.com/inuitwallet/nu-pool you’ll find that.
Unfortunately the parameter isn’t yet included in pool.conf, yo you need to add

deviation = 0.0005 

manually to pool.conf.

Great! Perfect, that means I can just have them download the master directory and supply a pool.conf file myself with the nupond parameters.

Sorry for not replying here earlier. I wanted to make sure that the bot ran with the new options before publishing. It seems from @masterOfDisaster that it does rstart up OK with the new code.
I’ll look at adding the spread as a config parameter too.

i see frequent errors in all bot and exchanges like below:

is this a bot bug? I was trying Python 3.5 but bot cannot start at all!

can you link to the github repo you downloaded from? It looks like you have an issue with line 284 in client.py

from MoD’s

Can you check for me that your line 284 in client.py is this:

self.users[user][unit][‘request’].sampling)

Which is the last parameter in a logger.warning command? At this section of the code, the bot increases the number of requests by 1 and tries to tell the logger. For some reason the requests are coming back as unicode.

If I were trouble shooting this, I would probably put a line like this just before the logger.warning command:

self.logger.warning(self.users[user][unit][‘request’].sampling)

Are you still trying Python 3.5? Does it work in Python 2.7.9?

yes this is the line. i have Python 2.7.10, it seems version 3.5 is not compatible with bots :frowning:
Then what command i should try in what line?
thanks

At line 281, insert a new line that says:

self.logger.warning(self.users[user][unit][‘request’].sampling)

This will tell me what is stored in that value.

not working, all my bots are closed!
obviously i am not the right person to try that :slight_smile:

Alright, sorry, undo what you did (in the future you should probably make a backup before editing code). So, is this a new occurrence? Have you always been getting this error? Have you tried downloading from https://github.com/inuitwallet/nu-pool?

The bots are written for Python 2.7.x. Python 3.x has enough differences that it is effectively a different language. Both versions are well maintained and there is no current plan to port to python 3.

1 Like

i see nubit below 0.99$ today. i think we should make the ALP servers to accept only values between 0.99-1.01$
Out of these bountaries, ALP server should not pay the custodians. This could be managed via the spread value, i think.

This is already how they work. If the btc price moves more than 1% since the last trade the price will appear to drift that much. The word you’re looking for is tolerance and most pools have it around 1%.

2 Likes

maybe not enough fund to support Tier1 :smile: