Just to clarify: The liquidity operation on Bittrex has officially started!
Please use the client release designed for this operation: https://github.com/creon-nu/nu-pool/releases/latest
Don’t hesitate to ask any question you might have. Let’s make this a success. Thanks!
This is quite likely to a certain extent since nbt stability primary use is the hedge vs bitcoin.
We would have to eliminate nbt/btc pairs from exchanges to eliminate such a risk.
Awesome job!
It seems to be in German. Anyway to change the language in English?
I would be very interested in that actually. I think a lot of providers want to know if the maximum interest rate offered is enough. In other words, they want to know (including me) in which case it is sufficient and in which case it is not.
I have in mind the downtrend of bitcoin’s price as a particular situation.
Done, my bad.
@Creon is the brains behind this calculation. I’ll have to bow to his knowledge before giving an answer on how an answer can be arrived at.
These are the future market options that you can find on big Exchanges like OKCoin or Bitfinex, which allow you some kind of BTC price guarantee for a certain time period. @JordanLee mentioned it somewhere in the general context of LPCs.
Of course the ideal solution would be automatic, i.e. the client automatically secures any order placed by such a future market contract. Again, I still have to look into it to say if this is feasible or even possible as I imagine it.
If someone here is familiar with these trading tools, then I would appreciate to have a small chat about it.
Right. The main thread related to hedging against the loss in value of BTC when you are custodian on NBT/BTC using some kind of derivatives is here, I believe.
Having an automatic hedging feature, that would for example directly deduce the cost of protection from your payout would be awesome.
First payouts have been sent: http://blockexplorer.nu/transactions/f967026943990e665a80265f520ae1c36271232189280016122c4b453f5f886c
About two hours ago I started to recognize a problem with Bittrex. The server only barely gets requests validated and I think some of you will have an efficiency of around 0 now. Sometimes it recovers for a while, but all data during those (long) periods is faulty. When talking to Bittrex they already warned me that Cloudfare might throttle the server, but I cannot say if this is in any way related to our current problem.
What I did now is to modify the Bittrex client in the way that it ensures that only one order per market side will be placed at a time. This means previous orders will simply be removed before placing a new one. This will reduce the number of calls to the exchange and hopefully solve our problem for now:
https://github.com/creon-nu/nu-pool/releases/tag/0.92
THIS UPDATE IS MANDATORY!
We will update the server once @woolly_sammoth and @willy are awake. (I restarted the server, see below). The server will not accept more than two orders (buy/sell) in a request of a user, such that requests from old client in some cases will get rejected. So please update the client as soon as possible to avoid getting rejects.
I can only hope that it will improve the situation. Furthermore I am eagerly trying to get in contact with Bittrex to get more information from their side. Don’t know what else to say than sorry - with 10 users and more than 7000 NBT liquidity on day one the operation already scaled to a multiple of the beta and these problems were hardly observable from my tests.
Important: When the server restarts, all balances will be reset to zero. I will personally take care that all open balances will be sent (manually) when we restart the server. Furthermore be assured that your funds are not at risk, also not on the current server. The trading bot is not affected by all this, its only the server <-> exchange communication which creates this problem.
Thank you for your understanding.
EDIT: Its totally unfeasible right now. I will restart the server. Again, update your client as soon as possible to avoid getting rejects. Thanks!
EDIT2: The server was restarted. Lost balances will be sent soon.
EDIT3: All open balances have been sent. Everyone with a balance below 0.015 NBT got 0.015 NBT. Please let me know if anyone did not receive a payout.
Hi,
not sure why nobody else wrote anything, however, I think I found the remaining bug in the Bittrex wrapper which prevents the bot from replacing orders after a BTC price movement.
https://github.com/creon-nu/nu-pool/releases/tag/0.92
I know this all is very nasty and should have been discovered during beta. It just never reached the scale to see it.
Let’s hope that things are finally resolved now. I really can’t thank you enough for your support, especially over the last 12 hours.
It seems like the 0.92 version works properly. Server validations are very well timed and this with the same amount of users as last night. The trading bot also replaces orders correctly, even after many subsequent BTC price movements.
Note that you weren’t able to place your bid orders earlier because someone placed an ask order below 1 USD value and nobody of you set ordermatch=True. So while this was unfortunate, it in fact was the correct behavior. I am running a bot now with above flag set, so it should clean out those orders as long as they aren’t too large.
This is the good news I guess, while the bad news is that we will have to do another server restart. This issue is not a big one and we can schedule this to any time we want and arrange it that you will get your open balances paid in the moment where we restart the server, so there really should be no disadvantage for your, except that your balance will be paid earlier.
If a sell order is to low, does the bot place buy orders just below that low sell order? It would be sweet if this were an option.
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.
I have received two interest payments.Is it possible to distribue interest only after it has accumulated above a certain amount?
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.
Yes this takes care of it.
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.