Trust-less liquidity pool

[mhps]

Does connecting to the TLLP server use secure (https) connection and if not, is a secure connection needed?

If a hacker breaks into a TLLP server, what information can be collected? Liquidity providers’ IP, liquidity provision history, anything else?

[willy]

Does connecting to the TLLP server use secure (https) connection and if not, is a secure connection needed?

Not yet. Could always be a plus… but given the fact, that only your public key is transmitted, I don’t think we are in a rush here.

If a hacker breaks into a TLLP server, what information can be collected? Liquidity providers’ IP, liquidity provision history, anything else?

I can only speak for NuPool here: Due to the design of our server, the IP address is recorded for a short period of time but is not connected to a specific user account. Standard tllp shouldn’t log any IP information afaik.
A log file usually looks like this: pub key, credit (thus: balance), exchange, timestamp. Maybe sampling/missing problems (client->server connection) can be found deeply in the debug logs.

[mhps]

Thanks @willy. So high value IPs can be obtained if someone gains access to the server. It’s not too bad.

[willy]

high value IPs

Can you elaborate on that?

I don’t want to go into to much detail about our structure, but I will talk to @woolly_sammoth if we still need to keep IP addresses after all.

[woolly_sammoth]

We do have a server log that has ip addresses but it isn’t generated by the pool software and so can only be tied to an Api public address and payout nbt address by matching timestamps in the server log.
It is worth a thought that we don’t really get any value from this log so it will likely be disabled in future pool runs.
The architecture of the server has had thought put towards security. Each process is run by a standard user and ssh access is only possible with an appropriate private key. All unused ports are blocked and fail2ban monitors for brute force attacks and automatically blocks offending ip addresses.
It’s not fort knox but the attack surface of the server is quite small. An attacker would have to put quite a lot of effort into getting the information off the server and even then, could only associate three prices of pseudo-anonymous information: ip, nbt address and api public key.

[mhps]

Can you elaborate on that?

If the client sends pub key to the server then the IP can be tied to the pub key. It is possible to find out the balance from payout.

I guess if the hacker takes over the server (or a rogue pool owner for that matter) he could do something easier than breaking the client’s computer behind the IP. For example in the NBT/BTC market when the peg walls are dominating liquidity, the hacker could just removes all buy side BTC and direct all sell side NBT to be placed at 0.000001 BTC where he has a buy order, then direct all buy side BTC to buy NBT at 1BTC where he also has an order. Virtually all clients’ value will be transfered to the hacker’s account. The client software could do sanity check to avoid such drastic scenario but the hacker could still sabotage, e.g. by inserting code to front run the client and steal most coins from the client pretty quickly.

In this sense TLLP isn’t totally trustless unless the client can check the prices independently. (for the NBT/USD market the price could be hardwired)

edit to add: It seems that both the server and the client get the prices independently from third parties. So the server can’t influence the order placing on the client side.

[Nagalim]

The server is never given the API secret. The client is the one that puts up buy and sell orders.

The only invasive API call by the server is asking for their orders, I think. To really get someone to place arbitrary orders, you’d have to hack the github and get people to pull a tainted copy and run it without reading it.

This is what we mean by ‘trustless’. The pool operator could be completely corrupt, and the user would not feel the pain, only Nu. The client does check the prices independently, from yahoo or coindesk or bitfinex or what have you, dependent on the currency.

[mhps]

The server is never given the API secret. The client is the one that puts up buy and sell orders.

I meant the API public key. It is used to identify client on the server side, right?

The client does check the prices independently

Oh I thought the client gets the price from the server.

[Nagalim]

Identify, yes. Control, no.

[mhps]

Identify, yes. Control, no.

Then the server knows which pub key is tied to which IP (and identify high value IPs) ?

[Nagalim]

Sam and Willy would know that better than I.

We do have a server log that has ip addresses but it isn’t generated by the pool software and so can only be tied to an Api public address and payout nbt address by matching timestamps in the server log. It is worth a thought that we don’t really get any value from this log so it will likely be disabled in future pool runs.

[woolly_sammoth]

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.

Then the server knows which pub key is tied to which IP (and identify high value IPs) ?

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.

[masterOfDisaster]

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

[Nagalim]

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.

[mhps]

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

[masterOfDisaster]

If you wire the deviation (and spread would be nice) out to pool.conf as ‘advanced trading parameters’

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.

[Nagalim]

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

[woolly_sammoth]

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.

[zoro]

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!

[Nagalim]

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