[NuPool] Announcing: Trustless liquidity pool operation “NuPool” on Bittrex.com has started

[woolly_sammoth]

At the moment that’s it I’m afraid. If you are running on just a single exchange and running the TLLP client in the traditional way it should shutdown cleanly and cancel the orders. The issue arises if you run the client in the background with `nohup`` and the like, or using the run_client script for multiple exchanges. Then the shutdown is forced and the orders aren;t cancelled.
I’ll add this need to the todo list for the next release.

[masterOfDisaster]

So at the moment something like this is the best you can do?

#!/bin/bash echo "starting nupool in the background" function background_loop while :; do pkill -f client.py ~/apps/nupool/unix/client >/dev/null 2>&1 sleep 600 done background_loop &

I would very much welcome you putting other ways of shutting down a tllp client to your todo list
…this would provide an even better liquidity, because tllp bots wouldn’t go nuts and kepp the funds off the order book…

[woolly_sammoth]

my usual tactic is to get the main loop of an application to check the existence of a file in the file system (usually just called ‘run’). The application creates that file on startup and then stops if it is missing for any reason. You can then just remove that file to stop the application even if it’s running in the background.
I’ll definitely bump this up the todo list as it should be fairly easy to accomplish.

[PinkyAndTheBrain]

fyi, i can restart all iwant, it remains at 0% https://raw.nupool.net/?pairs=true

[masterOfDisaster]

I have played with two ways of running a tllp bot

• running it within a screen session and connect to it from time to time to check the status - being able to shut it doewn properly if need be
• running it in the background with periodic restarts - no real interaction and no way to check the status without looking at the exchange

My conclusion is:
even if the tllp bot sometimes goes nuts and needs to be restarted this is the lesser evil. I faced legions of stranded 1 NBT orders that remained after killing the tllp bot (instead of shutting it doen properly). As they weren’t removed after the tllp bot started again they piled up until I noticed that.
Deleting them was something I don’t want to do again soon I rather have a tllp bot that doesn’t provide liquidity for some hours or a few days.
A config parameter to recycle the tllp bot after a given time would be great!

But before I sidetrack the topic, I give you the feedback that the last run of my nupool tllp bot was from
2015/06/28-11:19:44 to
2015/07/05-23:56:12
and only ended because of a power outage at my RaspberryPi.

[Nagalim]

I added this to tading.py:

try:
totime = time.time() - self.startime
if totime > (self.restime*3600):
python = sys.executable
os.execl(python, python, * sys.argv)
except:
print “issues restarting bot”

I’ve been using this for a while, I made it a config parameter, and it works alright for a workaround. https://github.com/Nagalim/nu-pool

i can restart all iwant, it remains at 0%

Does it place the orders and just not validate them? I have been suspicious of nupool’s 0.0085 tolerance since I had trouble getting my bot to work on poloniex. I’m wondering if the nupool price feed is off for some reason, so it validates orders that are higher than the price but fails at validating lower than the price.

[woolly_sammoth]

@masterOfDisater - that’s some run! a config parameter to recycle the client is a good idea and one that I’ll look into.

@PinkyAndTheBrain - there are still ask orders on Bittrex that are lower than the tllp calculated bid price. That is causing the client to not pace orders as they are being run with ordermatch = False.
I don;t have enough funds to clear the ~22BTC worth of orders that are causing the block. Similar things did happen in the early days of NuPool and we found that they do tend to clear as the BTC price moves. If anyone wants to help out, you can run your client with ordermatch = True in your config. This will force the bid order to be placed and filled immediately with the low priced NuBits. It means you get NuBits for a lower price than that calculated by NuPool which may be what you want but may not be. I have set this as the default behaviour in the next release.

[woolly_sammoth]

There have not been any changes to the price feed code on NuPool and the settings are exactly as they have been for the last 2 operations.

[Nagalim]

how much sell side is being validated on bittrex? Are we sure that block isn’t being caused by a rogue tllp bot? If it’s someone actually selling that much nbt, fine, but I can’t help but think that’s a lot of nbt.

[willy]

how much sell side is being validated on bittrex?

https://raw.nupool.net/?pairs=true

[Nagalim]

So it’s not a rogue client then, just an ordermatch thing. 8,000 sell side, all around .00377, then another 4,000 around .00372.

[mhps]

running it in the background with periodic restarts - no real interaction and no way to check the status without looking at the exchange

Check status - you just need to save the output to a log file (instead of > /dev/null ) and look at the tail to see recent status (and history) when you want.

[masterOfDisaster]

Without the

>/dev/null 2>&1

part it’s not possible to run the tllp bot in the background.

Checking for logs in unix/logs is always possible to check the status, but less convenient than running each tllp bot in its own screen session.

At the risk of derailing this thread (please don’t read further unless you are interested in running tllp bots on a RaspberryPi ):
my current tllp bot operation model deals with 3 screen sessions and automatic output of the last lines of the current log files on demand.
One script starts the screen sessions that are named and where the path is set to start the tllp bot with simply executing “./client” (I haven’t found out how to execute commands within a screen session to automate starting the tllp bots):

cd ~/apps/liquidbits/unix/
screen -dmS liquidbits
cd ~/apps/nupool/unix/
screen -dmS nupool
cd ~/apps/nupondCNY/unix/
screen -dmS nupond
screen -dmS poolinfo

And this script - executed from within the “poolinfo” screen - gives a convenient overview of the status of the tllp bots:

#!/bin/bash
liquidbitsdir=~/apps/liquidbits/unix/logs/
liquidbitslog=`ls -t $liquidbitsdir | head -n 1`
nupooldir=~/apps/nupool/unix/logs/
nupoollog=`ls -t $nupoolclientdir | head -n 1`
nupondCNYdir=~/apps/nupondCNY/unix/logs/
nupondCNYlog=`ls -t $nupondCNYdir | head -n 1`

echo "#########################################################################################"
date
echo "### liquidbits ###"
echo $liquidbitsdir$liquidbitslog
tail -n 2 $liquidbitsdir$liquidbitslog && echo
echo "### nupool ###"
echo $nupooldir$nupoollog
tail -n 2 $nupooldir$nupoollog && echo
echo "### nupondCNY ###"
echo $nupondCNYdir$nupondCNYlog
tail -n 2 $nupondCNYdir$nupondCNYlog

Printing the current log file into the output of poolinfo makes it easy to dig deeper in the log files without first searching for the most recent one.
These two scripts with only a few lines make it very easy to run and check the tllp bots.
…just in case somebody is interested in it…

[PinkyAndTheBrain]

any thoughts on tmux vs screen?