You should. I have 545 NBT left in the account, I had 583 yesterday.
There might be a bug or two. If the price is out of tolerance or moved out of tolerage because the feed price changed, bug 1) the order wonāt get canceled. 2) new order is still placed when the old one is not canceled. I think this is might be related to fillfactor implementation.
so the orders donāt get deleted when the price changes by the deviation? Thatās surprising.
Fillfactor messes up occasionally, but it should be good most of the time and is fixed by a restart.
only those orders that are out of the payable bands donāt get deleted. you can reproduce it buy placing orders there and see what happens
so if you place an order at 0.0000000001 NBT/BTC, it will never be deleted by the bot until the bot reset?
@nagalim, you appear to be good at tweaking in a way that LPs get higher spreads for the same price.
Iām wondering whether it is possible to have the server giving preference on those providing a lower spread over those with providing a high spread. I believe a tighter spread is in the interest of the Shareholders.
Which brings me to the question, what would it take to tweak the software to just do that? I assume that requires changes at the server side?
Having different tiers of reward is something Sam is working on for nubot. I have kinda this concept in the back of my head of ways to stimulate price discovery near the price feed that uses several tiers, possibly hundreds, and a function for different reward at different spread.
I donāt think Iām going to try implementing it in the current alp sodtware, but I appreciate that youāre thinking about this stuff too.
Ok, was not aware of that.
It is not that hard to model, but I wouldnāt be able to code it.Hope the new ALP software brings it allā¦
1 Like
The thing is, coding it up is actually a near-infinite endeavour. Let me explain. There are two pieces of software, the client and the server. The server side is actually relatively straight forward: rank the tiers with different weights, add up all the weights times all the liquidity at each weight to get a total normalization factor, then divide the fixed cost rate by that factor and distribute. That way, if only one person is providing in Rank 8 they will get paid the full amount but if you have some funds in Rank 8 and some in Rank 3 they will get paid different fractions of the full amount divided based on weighting and liquidity provided.
So thatās the easy part, and probably the part you were talking about. The hard part is the client side. Now, the client needs to weigh profitability via trading with profitability via the ALP. It will need to be up to snuff like any other trading bot on EMAs and risk-reward strategies while also needing to measure the opportunity cost of moving funds from one pool rank to another. This can get complicated.
And finally, the feedback loops. Ideally, the server side will actually change its rank distribution to accommodate new users. Basically, it would use the presence of a custodian as a feedback to understanding where the price is and where to offer the highest rewards. Essentially, this would look like offering higher weights to the rank that has liquidity and all the ranks closer to the price feed, while lowering the weights of those ranks farther away. This will stimulate the next custodian to place their order one rank closer to the price feed than the last custodian, rather than one rank farther away like would normally be the case (to minimize volatility risks). This is ideal, and a fix for the continually shifting bots jockeying for position that we would otherwise result in.
Anyway, there are levels of complexity here. Sure, just having two different payments for tight and wide spread sounds great and simple, but it points at such a bigger and more magnificent method of liquidity provision. All we have to do is implement it right, and Iām pretty satisfied that Sam is doing just that.
1 Like
@Nagalim cnypool
2015/12/16-00:21:08 ERROR: submit: socket error (111)
2015/12/16-00:21:08 ERROR: submit: socket error (111)
2015/12/16-00:21:09 ERROR: submit: socket error (111)
2015/12/16-00:21:09 ERROR: submit: socket error (111)
2015/12/16-00:21:09 ERROR: submit: socket error (111)
2015/12/16-00:21:10 ERROR: submit: socket error (111)
2015/12/16-00:21:10 ERROR: submit: socket error (111)
2015/12/16-00:21:10 ERROR: submit: socket error (111)No clue. The log file literally just ends for no reason. The other CNY server was misbehaving too. I wonder if theyāre related; they shouldnāt be but itās possible I guess. Anyway, restarted the CNY script and did manual payouts.
I didnāt restart. The bot paid out 9.9 NBT on that pool last night automatically (as it should because the ask side is broken). The logs seem to all be fine. Do you still think there was an issue?
BTC server is down?
Bad timing, Iāll look into it as soon as I can.
āError caught in main loop:ā I donāt have time to troubleshoot this right now. Hereās hoping it goes away on its own.
I restarted the btc server and did manual payouts.
1 Like
@Nagalim after check my log file , the balance lose for no reason
2015/12/18-05:47:46 INFO: bter - balance: 1.11939084 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/18-05:48:46 INFO: bter - balance: 1.12014704 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/18-05:49:46 INFO: bter - balance: 1.12090324 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/18-05:50:46 INFO: bter - balance: 0.00000000 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/18-05:51:46 INFO: bter - balance: 0.00075620 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/18-05:52:46 INFO: bter - balance: 0.00151240 rate: 0.23% ppm: 0.00075620
efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.9090 x 0.23% - 81C5
AE35-21D1-48F3-9F3D-24EA0A303194
and date now of my VPS:
[root@vps ~]# date -R
Fri, 18 Dec 2015 20:33:29 -0500
notice that the time is not a autopay time
and turn to zero again:
2015/12/19-05:48:13 INFO: bter - balance: 1.11490192 rate: 0.23% ppm: 0.00075585 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.5250 x 0.23% - 81C5AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/19-05:49:13 INFO: bter - balance: 1.11565776 rate: 0.23% ppm: 0.00075585 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.5250 x 0.23% - 81C5AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/19-05:50:13 INFO: bter - balance: 0.00075585 rate: 0.23% ppm: 0.00075585 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.5250 x 0.23% - 81C5AE35-21D1-48F3-9F3D-24EA0A303194
2015/12/19-05:51:13 INFO: bter - balance: 0.00156146 rate: 0.23% ppm: 0.00075585 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 469.5250 x 0.23% - 81C5AE35-21D1-48F3-9F3D-24EA0A303194sorry , It is send to my new address when i reset payment address few days ago:sweat:
1 Like
Great! That one was a puzzler, I was about to ask you for your nbt address.
If you think that BTC on Bter is consistently underpriced compared to OKCoin, you can try to manually put in this pricing difference. For example, the shift line might become:
shift = {āautoā:0.0005,āmanualā:-0.002}
As long as the sum of āautoā and āmanualā is 0.0025 or less, you can play around with it and still get credited by the server. A negative manual shift corresponds to lowering the price of NBT with respect to CNY (a lower price on the NBT/CNY market, as expected). So if the price feed reads 6.5 and you put a -0.002 manual shift, the bot will treat the price as 6.487 before applying the offsets for buy and sell orders.
What are these strange payments?
exactly the same payouts from the nupond server, but it is like they are sent 2 times!
The first time they are unsuccessful. Yesterday was the first occurance.