Not sure what the problem is. My bots are running fine. Maybe a connection issue?
Strange…
On one machine (where the bot ran fine for days) I get
2015/06/14-07:37:05 ERROR: server unresponsive for usd on ccedk
2015/06/14-07:37:05 INFO: stopping PyBot for usd on ccedk
2015/06/14-07:37:06 INFO: successfully deleted all orders for usd on ccedk
2015/06/14-07:37:35 ERROR: server unresponsive for usd on ccedk
2015/06/14-07:37:35 INFO: stopping PyBot for usd on ccedk
2015/06/14-07:37:36 INFO: successfully deleted all orders for usd on ccedkAnd on another machine (where I started the bot to test) I get
could not retrieve ccedk ids, server is unreachable <urlopen error [Errno -2] Name or service not known>
On the latter machine I can load the website without any trouble. So DNS seems to be ok.
I tried to use an older version of the bot. Unfortunately I don’t know how to find out the exact version. This bot runs.
The version that stopped working was running since
2015/06/01-16:28:39 INFO: starting PyBot for usd on ccedk
with no major issues (except for temporary socket errors).
Then this message was in the log
2015/06/12-10:14:31 ERROR: server unresponsive for usd on ccedk
2015/06/12-10:14:31 INFO: stopping PyBot for usd on ccedk
2015/06/12-10:14:31 INFO: successfully deleted all orders for usd on ccedkAnd from that on the bot was not running and couldn’t be restarted (not this version of the bot).
I don’t think this can be related to only the bot…
How can this version of the bot tun fine for 11 days and then stop without a change at ccedk or the server (to me it looks like ccedk API)?
Strange indeed as my bots are running. Had to restart the EUR/NBT bot yesterday as it had spontaneously reduced my liquidity for some unknown reason. The USD/NBT bot didn’t have a problem at all. There have been no changes on the server since 1 June. Given that my bots still work it sound unlikely that there has been changes to the CCEDK API.
Not sure what is going on. Maybe a restart of your OS is required or refreshing the software as below?
You can find the latest release of software including the bots here: https://github.com/Cybnate/nu-pool/releases. The release is aligned with Nu-pool and you should only need to change the servername (nbt.liquidbits.net), exchange (e.g. ccedk) and pair (e.g. USD for NBT/USD pair).
1 Like
Proposal to extend LiquidBits.net TLLP services
After a somewhat rough start things have stabilised and the pool pays out everyday without problems. Therefore I like to propose to continue the TLLP service when there shareholders support me with providing the means.
The main changes are the reduced rates for the CCEDK fiat pairs NBT/EUR and NBT/USD from 0.33%/day to 0.25%/day. Given the low or zero volatility risk and the low trade volumes I think this is still a very attractive rate.
I’ve reduced the NBT/USD pair from 10,000 to 7,500 on CCEDK not being that popular and increased the NBT/BTC pair on Bitcoin.co.id from 2,500 to 5,000 as this exchange is becoming more popular. I’ve left the CCEDK NBT/EUR pair the same at 2,500 NBT maximum paid liquidity aiming for an increase in popularity.
Here is the resulting draft custodial grant:
=##=##=##=##=##=## Custodian Hash starts with this line ##=##=##=##=##=##=
Custodial Address: xxx Amount Requested: 245 NBT
Custiodial grant request to continue to operate Liquidbits.net, a liquidity pool for NuBits.
@cybnate continues the independent trustless liquidity pool (TLLP) to provide liquidity on the EUR/NBT, USD/NBT and BTC/NBT markets. A target of 7,500 NBT on the bid and ask side of the order books will be provided by the pool split over 3 currency pairs, resulting in a total maximum liquidity of 15,000 NBT. The operation will end after thirty (30) days when a motion to continue operations haven’t passed before.
Liquidity provided by users will be compensated as follows:
-
with up to 7.5% per month (0.25% per day) on CCEDK’s EUR/NBT pair on both sell and buy side to a maximum of 2,500 NBT ( max pay-out 187.50 NBT/30days)
-
with up to 7.5% per month (0.25% per day) on CCEDK’s USD/NBT pair on both sell and buy side to a maximum of 7,500 NBT (max pay-out 562.50 NBT/30 days)
-
with on average 10% per month (0.33% per day) per month on Bitcoin.co.id BTC/NBT pair to a maximum of 5000 NBT in total but split as follows:
-
0.38% per day up to 2500 NBT on sell side ( max pay-out 285 NBT/30 days)
-
0.28% per day up to 2500 NBT on buy side ( max pay-out 210 NBT/30 days)
using the pool’s calculations based on the Dutch auction model to allow a fair distribution of returns amongst liquidity providers. 1245 NBT of the requested amount in this grant will be held as reserve to make pay-outs to connected users.
The current grant has 1245 NBT left to date with about 9 days to go at a current payout rate of just under 10 NBT on average. Allowing for a minor increase there will be approx. 1100 NBT left.
Total required 1245 - 1100 = 145 NBT.
Terms and conditions
Pay-outs take place every 24 hours. The minimum pay-out is 1 NBT. The spread continues to be 0.04 with 0.075 tolerance on both exchanges. Operations and pay-outs will start within 3 days after the custodial grant has passed successfully. The pool will continue to operate under the name Liquidbits.net. Remaining funds will be settled with future grants or when the pool is discontinued, burned.
Fee
The pool fee is a one-off 100 NBT and serves as a contribution for the effort of supporting the pool, the website, reporting, supporting the users and the monthly costs of operating the server.
Instructions
Instructions on how to participate in the pool can be found here: http://cybnate.github.io/index-liquidbits.html
Work is underway to improve the website.
=##=##=##=##=##=## Custodian Hash ends with this line ##=##=##=##=##=##=
Please your feedback in the next few days to ensure the continuation of the service. Aiming to post a final version shortly after 30 June (23:59 UTC). The current pool ends in approx. 9 days.
1 Like
What’s the tolerance?
I won’t vote for any more custodian grants that don’t give a %.05+fee operating spread on btc pools. That will mean something like a .008 tolerance for you. ( I think ccedk fees are %.01?)
The tolerance setting in the software is 0.075. The spread is 0.2% on either side (total between 0.0325 and 0.475%).
The CCEDK and Bitcoin.co.id fees are different, but without creating multiple instances I can’t cater for that at the moment.
So this proposal purposely goes against the recent motion that was passed constraining offsets on btc pools to be larger than %.5? I will not be voting for it then.
I am aware some people voted for the spread regulation motion because of the core component of disclosure requirements (well, at least @cybnate did), with an understanding that offset/tolerance proposed in individual motions and grant proposals override the original motion. In hindsight it is hard to gauge shareholder agreement like this, so in the near future we still need to refactor the spread regulation motion even though it has passed.
So I won’t go so far as to withhold voting for a different spread. I’m on the fence for a 0.4% spread, though.
Either way:
- It may be good to mention in your post that CCEDK is offering 0.001% trading fee until early August, which covers this run and helps justify your lower tolerance
- I guess you want to write 0.004 offset and 0.0075
tolerance?
The way I understand it, cybnate is saying 0.2% (0.002) offset and 0.4% spread, but I’m not sure.
Apparently I’m still getting entangled in the wording, so here is an example:
USD on CCEDK will be on the ask side for 1.002 and on the bid side for 0.998. So the offset is 0.002 on each side. Total spread is 0.4% between 0.998 and 1.002.
On top of that there is a tolerance setting in the software which is set at 0.0075. This allows some margin on e.g. the BTC and EUR pairs to prevent the bid and ask orders from moving with every tiny change. As far as I understand the software this is on top of the spread. That is how I arrive at 0.325 and 0.475 which are both below 0.5%.
However both CCEDK and Bitcoin.co.have almost zero fees. I can tell you that on average I’m making money on the BTC pair because of the spread and low exchange fees. However I’m also aware that this can turnaround into negatives, which don’t need to be a problem with the fee being paid.
Regarding the earlier motion, I’m of the opinion that this motion did set a guideline for those who didn’t define it explicitly. That was the reason I voted for it. My custodial grant is supposed to be clear regarding offsets. Shareholders are of course free to not vote. And with 0.475 I’m only marginally below 0.5%.
When the software allows easier tailoring at some stage I would provide competing pools with low spreads and high fees and high spreads with almost zero fees (only offsetting exchange fees) on different exchange pairs. For USD pair I think a low spread is appropriate, BTC pair higher spreads and lower fees should be possible.
1 Like
Just appeared to have lost the Liquidbits server. I’ve submitted a ticket with Digital Ocean.
It is not clear what happened, but it looks like another outage with DO as I have no access at all, not even directly through their site.
Just to be on the safe site, you might want to cancel your orders manually.
1 Like
You supply your custodians with a bot. The concept of that motion was to have operators supply relevant bots. The bot you provide places orders with an offset of .2%. That means your offset is .2%, not 0.475 or whatever phenomenological number appears on the exchange.
With a 0.75% tolerance, you could provide a bot with %.45 offset and still be perfectly relevant. What that means is that if someone takes my repo to run on your pool instead of yours, they will be more profitable. You are actively hamstringing your liquidity providers.
I am not asking you to change your tolerance, I think %0.75 is fine. I simply am asking that you make your intended participants’ offsets to be relevant to that number. Please increase your Repo’s offset to 0.4% or call a spade a spade and reduce your tolerance to 0.5% so you can be fair about your 0.2% offset. Running with a 0.75% tolerance and defaulting the providers to a 0.2% offset is unfair to your providers who trust you to give them the best software for the job.
I’m sorry I made this a voting issue. Your work is great and I will vote for it either way.
The server is back. It looks like NUD went rogue taking over 75% of the memory (normally just over 50%)
Had to restart the server, investigate further tomorrow (local time).
Confirmed in the SSH logs that there was a memory problem, creating login issues and making the server non-responsive. Memory usage was at 93% when I managed to get through, normally at around 75%. Will keep an eye on this. There might have been a relation with the fork Nu had in the past or there is a memory leak. Will update NU with the next reboot. The new payout time has now shifted to around 11am UTC in case you wonder.
Apologies for the inconvenience.
1 Like
I’m not feeling comfortable to change code when I do not completely understand the implications as the change you propose is not in the config files and need to be made in the code.
Hope @woolly_sammoth can provide some advise on how Nu-pool deals or intends to deal with this.
1 Like
Shouldn’t 495 NBT be in fact 5000 NBT?
Apart from that, since I am not clear 100% on the difference between spread, tolerance and offsets and since Liquidbits.net has produced a nice job so far, I will vote for its continuation.
I am waiting for the new hash.
1 Like
Yes, it should. Well spotted. I’ve updated the draft.
1 Like
I am trying liquidbits on a ubuntu machine. I get this error message upon starting
2015/07/26-xx:xx:xx ERROR: unable to receive balance for usd on ccedk: exception caught: 'bool' object has no attribute '__getitem__'
Any idea what is wrong? @woolly_sammoth @willy
1 Like
Not sure off hand but will look into it later today.
2 Likes
This might be relevant -
I tried with the same setup on a R-pi with no error.
I tried nupond with cny on the ubuntu machine and there was no error.