This is strange. Which operating system are you on? If it is Windows, then there might be a file called users.txt which has priority.
Besides that I cannot see anything wrong with your line in the users.dat. You can also write another file with the exchange data and pass it as second parameter to the client to use it instead of the users.dat, e.g.
./client.py 104.245.36.10:3333 myfile.txt
Alternatively, not sure how this works on Windows though, you can also pass your line as standard input to the program and tell it to read from there by providing an “-” :
Thanks willy and creon. The above did the trick. My command is cat users-p.dat | python ./client.py 104.245.36.10:3333 -
I think the reason of my problem was that I created users.dat by ln -sf users-p.dat users.dat in the git bash window (I think it feels like a cygwin window) on my 32bit win7 laptop. The link file users.dat cannot be opened properly by client.py (maybe a cygwin python can work)
The way I see your system: set up the minimum rate you are willing to accept for the risk of providing liquidity on a specific exchange, otherwise specify no minimum rate and you will get the target rate if ever you get a reward.
By the way, I have not received yet any payout for a while (1 week ).
Is the minimum payout set to 1NBT right now?
Regarding the payouts, the interest rates are extremely small currently and I restarted the server too often. Sorry for that, since the beta ended I didn’t really take care about server up-time etc. and restarted as I desired to test new features.
However, we will start a small new beta running on our production server. I’ll post something about that soon.
Thanks.
Did you put the git directory on the Pi and it just worked with a users.dat? What percentage of CPU and memory use does it take, as reported by top ?
Great. Can @creon tell what level of security risk the package might bring to the host (compared with not running the package)? I can think of undiscovered security bugs in stock python libraries and nubot if nubot is used. These are low probability possibilities. Any other libs and apps?
Everything in this package, except the json-rpc communication which is optional, is using the standard library. While also standard libraries have bugs, they can usually be considered as rather safe.
The server of course opens a port. This is always a security issue and a bug in the http server if my software theoretically could provide an attacker with any information on the system. The server further requires an unlocked NBT wallet so submit liquidity.
Just pointing out that for anyone quickly skimming the comments that @creon is referring to a configuration that you need to have only if you are running a pool. If you are a participant of a pool you don’t need to worry about this because the Nu-Pool software does not touch your personal Nu wallet in any way.
Setting up the TLLP client is still more work than handing out the coins.
To make using the trustless pool easier, compile it into a stand-alone program.
Its now a double clickable file for all operating systems. For Linux and Mac its a bash script and for Windows a bat file. So its really just about making a double click on the pool.conf, inserting your data and then to double click the client.
Of course, regardless how easy I make the client, henrys pool will always be easier to use because people don’t need to create an API key/secret pair. I think regarding complexity the TLLP places itself pretty much in between of henrys pool idea and a casual LPC operation running a NuBot. I see the TLLP mostly as tier 1 solution - partly because I still haven’t found a way for clients to prove tier 2 reliably. Henrys pool on the other hand has very efficient tools and metrics to adjust tier 3 <-> tier 2 -> tier 1 liquidity.
I already thought about hybrid models in the past, which would basically mean that henry would run a server and a client + would provide his current service and use it in the client according to his metrics (of course with a corresponding compensation for the additional effort).
