The server allows your price to deviate from its own price by not more than 0.5%. If your trading bot tries to place an order and there is a matching order, then it first tries to adapt the price such that it could place the order. However, if this price deviation is more than 0.5% then it also won’t place the order because it wouldn’t get compensated.
With ordermatch=True it will behave as above but if the deviation is larger than 0.5% in the end then the trading bot will just place the order at the server price and therefore match the existing order.
Of course you can argue that you are buying or selling NBT for a discount in those cases, but on the other hand it is gambling because you don’t know how the BTC price will change. That’s why the default behavior is to not match those orders.
After some extra testing this evening, the latest version of the client and server have been seen to act correctly on Bittrex.
A server restart was required which was undertaken at around 20:45 UTC. All outstanding balances have been paid in this transaction: http://blockexplorer.nu/transactions/46b57e1df116595a96361b4e121194a8f8201c9aff29662c818a129971efcbf5
(Any account which had a balance of less than 0.01 was sent 0.01 NBT)
It is highly reccomended that everyone updates to the new client to take advantage of these recent fixes and ensure prompt and correct payout. The latest code can be found here: https://github.com/creon-nu/nu-pool/releases/latest
There has been a lot of effort put in by the pool operators over the last 24 hours with the mammoth bug fixing session last night by @creon being of particular note. I’d like to thank everyone who has participated so far in the Trustless pool for their continued support.
This is the actual system. Every 24 hours all balances above 1 NBT will be send out. We also had a regular payout about 27 hours ago.
The whole Bittrex API problem however required to update the server (twice), which always resets all user balances to 0, so we performed the payouts manually based on the log files.
Don’t you think if the interest policy is “7.5%/mo” or “1500 NBT proportional to coin-hour contributions”, which ever is greater, then there would be more incentive to participate, because if there are a few participants, they will set to split the whole reward? This needs to get pre-approved by the shareholders tho.
If you have a daily notice showing what reward rate would be if participation keeps at current level until term-end, then people can evaluate risk-reward often.
Generally I think shareholders should consider encouraging liquidity provision when everyone wants to pull the fund. It has two aspects:
encourage liquidity provision when liquidity is low. This is partly taken care of by the fixed total reward above.
encourage liquidity provision on the less liquid side (i.e. incentivise buy/sell balancing).
Its not necessarily “1500 NBT proportional to coin-hour contributions”. The variable interest rate system ensures both points you bring up.
You can, and should, specify the minimal interest rate you are willing to get in the pool.conf. Every NBT which is above the target (10,000 NBT currently) will be compensated at lower interest rates as specified by the users. However, you will never get a larger payout by increasing your own minimal interest rate. Its based on the dutch multiple-item auction model and I formally described it here:
So if one side is overloaded, then people will get less interest on this side and there is an incentive to shift funds to the other side of the market where the interest rate is larger.
The problem with the max rate is that it can be too low to encourage fund providers. For example when the price of BTC is plummeting, people pull their fund. Argueablly this is the time the wall is needed. If for example if there is only one person proving 100 NBT, then if everyone knows this person will collect all 1500 NBT reward in the end for 3000 coin-days, then many people might want to jump in because the reward is 1500%/mo.
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.
