Big NBT buy (450 NBT, basically all our sell side liquidity). We’re now number 19 for volume on Bter’s CNY charts. So hooray! I hope whoever’s liquidity that was ( @masterOfDisaster? ) will put the CNY on buy side so we can boast a heavy buy side on bter.
1 Like
Woops!
Nice 
Put the CNY on buy side!
…I need to take a break.
2 Likes
Ideally, the bot should put that order up itself so you don’t have to even know it happened. Did you have to restart the bot to get it to work? I hope we work out bugs like that eventually so you never have to manually touch the bot after the initial setup.
Does anyone know how/when the NBT/CNY pair will show up on coinmarketcap? $450 volume would put us at number 3 just under Bittrex in terms of daily NBT volume and contribute 20% to the total daily volume for NBT. And it was all above $1/NBT.
I don’t think this one buy is properly indicative of the future, but if it is, hoorah.
The bot was at
2015/05/20-21:11:11 INFO: bter - balance: 0.08162923 rate: 0.01% ppm: 0.00000491 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 24.5000 x 0.01% - ask: 46.2473 x 0.01% - APIKEYThat’s why I restarted it and got
2015/05/20-21:11:53 INFO: starting PyBot for cny on bter
2015/05/20-21:11:53 DEBUG: starting liquidity operation with sampling 96
2015/05/20-21:11:54 INFO: successfully deleted all orders for cny on bter
2015/05/20-21:11:54 INFO: waiting 5.78 seconds to synchronize with other trading bots for cny on bter
2015/05/20-21:12:02 INFO: successfully placed bid cny order of 454.6660 nbt at 6.18994530 on bter
2015/05/20-21:12:03 INFO: successfully placed ask cny order of 46.2480 nbt at 6.21475470 on bter
2015/05/20-21:12:53 INFO: bter - balance: 0.08164261 rate: 0.01% ppm: 0.00003479 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 454.6660 x 0.01% - ask: 46.2480 x 0.01% - APIKEYShould I have waited some time and would the bot have adjusted that without being restarted?
I would have hoped the bot would pick up the new balance and place the orders accordingly. The loop the bot uses is about a minute so it may take a while depending on when the balance shows up in the api call.
Just noticed that a significant percentage of the votes is going to 1381ae23c3686167e8fc86ed185fe2539106a5d9 which is only the hash of this custodial grant:
Custodial Address: B8K2wj2i7JTSgSo73P74qvBETy4kpfp6UX
Amount Requested: 300 NBT
Please make sure you add this custodial grant request as such in the client instead as a motion hash.
2 Likes
Thank you shareholders.
1 Like
Thank you for your confidence in the Nu network!
When I had a look at http://nupond.net/status
{"credits": 12753, "users": 4, "validations": 306079, "liquidity": [50.979166666666664, 29.911250000000006], "sampling": 24}
I was wondering and had a look at my bot. It had removed all orders and started to place 1.00 NBT orders - it was already at 34 NBT at bid side and 36 NBT at buy side.
I stopped the bot (canceling orders took some time) and after starting it again it was running fine.
This 1 NBT order thing is really annoying…
I have been so frusterated with this bug for the last week, it’s seriously demoralizing. My buy side support wanes not because I don’t have willing custodians or a listening grant server, but because my custodians can’t keep their orders on the exchange!
I have been looking into this bug every night and I was hoping to come up with a temporary solution before posting about it, but no such luck. My current attempt at a solution is to restart the entire client when it goes into the bugged mode. By the way, the “1 nubit at a time” bug is not the only manifestation of the bugged mode, and a client restart always fixes it until it drops into that mode again.
I can confirm that based on my experience so far.
Hi All,
The 1NBT does seem to be triggered by a certain set of circumstances in which the calculation which determines if the client should place more funds on order goes into some sort of loop.
I have read and re-read the peice of code that seems to be at fault and can’t find any obvious problems in the logic. I’d like to understand morefully what the set of cicumstances are. My latest build on github contains some simple logging outputs to see what all the variables involved are set to when the problem code is triggered.
@Nagalim, could you copy those log lines from my client into yours so that, when this happens again, we can try and track through what is going on with some real data?
I’ve not ever seen the behaviour myself but would be very interested to try and understand what is going on and fix it.
2 Likes
If you want to see the behavior more, turn down the ‘deviation’ maximum. That is why my pool experiences this problem more than the others: I am trying to keep a tighter peg. When I do my testing, I use a deviation of like 0.03% and I see the problem fairly often. It has to do with how much the ticker price is changing.
1 Like
Alll this time I thought the 1NBT orders was a feature to somehow discourage attack on pegs of illiquid pairs.
Selling on the bter peg is not an attack! It is one of the best ways to get CNY onto bter, as NBT is fast confirming, nonvolatile, and we keep the peg tight. The more people realize that, I think we will see more liquidity offered there.
Just need to get rid of these darn bugs first.
The parametric orderbook may mitigate legitimate concerns you have about what occurs in a peg-break scenario. I’m not sure if it’s being planned to roll out on tllp’s though. Creon once came up with a layered payment system where different spreads would be paid a different premium, such that people can run the parametric orderbook and get paid varying amounts based on the parameters and how much risk they’re taking.
That idea to resemble a kind of “parametric orderbook” could be implemented quite simple, I guess.
Your NBT/CNY pool at bter requires a very thin spread at the bot to be verified by the server.
Offering additional pools with different maximum spread and different compensations could create walls at different spreads.
While this is not exactly what a parametric orderbook tries to achieve, it would be - with sufficient participation in the different pools - quite similar.
The only nasty thing is that single users who want to provide funds in different pools, need multiple accounts at the same exchange - something that was troublesome at https://bitcoin.co.id. I don’t know whether that’s fixed now.
The point to aim for for me at the moment is for every tllp user to be using NuBot with the parametric order book. The client that creon created is fantastic and does work really well with the tllp server software (as would be expected). I have personal experience of the amount of effort and thought that has gone into NuBot though and put a lot more trust in its capabilities, especially once the parametric order book is implemented.
As we’ve seen, the tllp client isn’t bug free and, since croen handed it to the community, the knowledge of its workings and what may be going wrong isn’t as readily available.
From a personal point of view it would mean that effort could be concentrated on advancing the tllp server code (NSR compensated pools for example) without having to support the pybot client too.
That said, I am still going to be investigating the current bugs in pybot and trying to get a fix in place. The above is more of a longer term goal.
1 Like
How do you see compensation working with a tllp nubot?
The Tllp software already works with NuBot. It can create a configuration file and start the bot off. The compensation works in the same way as the pyBot. There could be a few tweaks made to allow for order verification to be easier but they shouldn’t be hard to implement.
1 Like