Wait, we are not getting 1,500 NBT from the shareholders! This is the theoretical upper limit which would have only be reached if from the first moment on 20,000 NBT would have been provided at 0.25%. Since this not the case the remaining NBT will be “given back” to the shareholders, where giving back according to the grant either means that we use it for future operations or that we will burn the remaining NBT. The actual cost for the shareholders is therefore determined after the operation.
However, I like the general idea of giving a larger incentive to balance early on. One possible model would be to scale the pool’s maximum interest rate according to the current liquidity - this could be done in addition to the variable interest rate system specified by the user.
The custodian must open an account in exchange with a high liquidity, like Bitstamp for example.
The custodian should duplicate his TLLP served funds on his own Bitstamp account.
Custodian Buys NBT/Sells BTC:
Custodian’s buying 1000 NBT order on TLLP is fulfilled
Custodian’s client immediately buys 1000 USD worth of BTC on Bitstamp (market order),
or buys on best price (If custodian has accounts on several different exchanges)
Custodian Sells NBT/Buys BTC:
Custodian’s buying 10 BTC order on TLLP is fulfilled
Custodian’s client immediately sells 10 BTC for X USD on Bitstamp (market order)
or sells on best price (If custodian has accounts on several different exchanges)
Yes this is a very interesting concept. @GreatScott proposed something similar somewhere. It would require some implementation effort but in general this would be possible.
However, I really don’t want this project to converge to a real trading bot in the sense that in realizes a profit optimizing strategy by performing market actions. I think the TLLP should focus on the liquidity itself.
But an independent standalone program, which essentially checks your orders on the exchange and mirrors the actions as your describe it would be a very nice project.
There appears to be one pool user who is using an older version of the client.
They are providing ~3900 NBT on the buy side but the server is reporting the following error unable to validate request: too many requests received: 467
The new way the client works will reduce the number of requests that are sent and ensure that this user gets the proper compensation for their liquidity provision. The liquidity is only being reported by the pool sporadically too. With the current buy side liquidity of Nu looking so low, it would be nice to have a more stable report of the value being returned by the pool.
I would encourage everyone to ensure that they are running the lastest version of the client so that everyone gets the compensation to which they are entitled.
The lastest version of the client can be found here: https://github.com/creon-nu/nu-pool/releases/latest
Hello Nu!
The whole Nu and the ways to provide liquidity (being an important aspect when trying to provide a stable crypto currency…) are intriguing me.
I’d like to try @creon’s nupool, but have stumbled upon a question for which I couldn’t find an answer.
I have decided not to use the helpdesk, because the question might be of general interest and could be included in the FAQ.
Is it possible to run nupool client with the same pool.conf on different machines?
Does this generate conflicts or is this a feasible way to create a kind of redundant client?
This is perfectly possible. You can run as many clients on the same key as you want. Of course you will only get rewarded once.
However, make sure to disable the trading bot on all but one of the running clients. This can be achieved by setting
trading=none
in the pool.conf. This is not crucial, but if you don’t do this then the trading bots of your clients will steal the funds of each other and will complain a lot that something is wrong which might lead to many order replacements.
EDIT: I just noticed that this parameter wasn’t documented at all. Sorry for that. I’ll update the corresponding post.
We just hit our target of 10,000 NBT on the sell side for the first time! This means people with a minimal interest rate of 0.25% will partially not get compensated for their funds and people with lower interest rates will have priority. If you see your bot removing funds from the order book without replacing them, then either consider decreasing your minimal interest rate or remove them from the exchange to reduce your risk.
The buy side also recovered a bit and is stable around 4,500 NBT. The support is really amazing. Please report any issues you might have with your client, be it usability or efficiency problems. We want every client to work.
EDIT: Our server wasn’t so excited about that as we were and decided to kill itself. But I found the problem and fixed it. Sorry for that. All payouts have been sent. Let me know if someone is missing any balance.
OK the 13th user that joined apparently had some interest rate set the system wasn’t able to deal with correctly. This could and should have been tested in the beta, but it never showed up in my experiments.
The issue is fixed, the server is up and running and of course I will send the payouts of the last hours soon. Sorry for the inconvenience and thank you that you all kept the client running
Also for the future: Be assured that nothing will happen to your funds. Your bot will remove them if the server is down for more than 2 minutes, so don’t worry about that.
EDIT: You may have noticed a couple more server restarts. I thought it may be wise to use this irregular downtime to push some other server updates I was planning to do. However, you should also always have been compensated with at least the amount you had as balance. I also made a new client version:
If you experiencing a problem that your client does place not more than 0.5 NBT then updating to this version should help. It also contains a message feature that allows me as server operator to post you a message in the client in order to inform you about a mandatory update, if there is any.
The first number in the liquidity list is buy side, the second number is sell side.
You can also go into your client, Help -> Debug Window -> Console and then type getliquidityinfo B and look for the address BNUpooLxGbHXSs7Qcwi5EBXzZ82BbWwsMN.
OK we are officially full now and clients start to decrease their funds on both sides. Anyone who wants something from the cake needs to provide liquidity for less than 0.25% per day on both sides.
20,000 NBT on a new exchange within 2 weeks and without any particular PR effort and using a completely new and unknown software users have to run. The concept works, attracts users, and shifts the competition from LPCs to independent liquidity providers.
This is an open call to anyone who feels capable to run such a server, we need many different independent LPCs, not two or three big pools. Here is a working option which allows you to be an LPC without being rich. Anyone who is interested, please PM me, I am not asking for any compensation.
Good question. My client runs on a raspi 1 without any problem. To run a server with 16 users I could imagine that its a bit weak iconsidering that you also need a Nu daemon in parallel.
A raspi 2 has more performance than our current server and will easily handle this amount of users.
By the way right now I am still getting a rate of 0.25% although it shows up with THROTTLED_10_SECOND at the same time.
Besides, I would have a question.
What happens if every participant specifies no rate (meaning every participant wants to get 0.25% or nothing) and the the overall liquidity that wants to be provided is beyond the liquidity target?
How does the pool select participant A over participant B? First arrived first served?
If you look again, its THROTTLED_1_SECOND this time, correct? They changed the message. I implemented a more generic fix to deal with this and also reduced the frequency of how often the client makes API calls:
Interestingly the server doesn’t have any of these issues, which is why you still get 0.25%. I have no explanation for that, since the server make much more API calls.
No just overall contribution. If the target is 150 NBT and you are providing 100 NBT and I join with 200 NBT, then you will get 1/3 of the 150 NBT compensated and I will get 2/3 of the 150 NBT compensated.
