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.
So I’m not sure why you’re seeing that. Here are the two addresses that have been paying out the last couple days:
http://blockexplorer.nu/address/B8DZADD7UrMkzEmTWyvn2cEoxcnog1D8MK/1/newest
http://blockexplorer.nu/address/BFqe2tA4wJyDsP2CG2yDtki4wpTzSaAgfX/1/newest
As you can see, there is 1 send from each each day, corresponding to the two pools. As you say, one of those pairs of sends seems to fail, so I’m definitely not double paying. Weird that you see that, I’ll check my records and logs later today.
@zoro @nmei Can I get confirmation that the CNY pool did not pay out properly today? I have the credit file, the bot thinks the payout went just dandy, so not sure what happened there. I think it’s cause I started the two scripts so close together in time, so if I just restart the CNY pool and do the payouts everything should be good.
I don’t use CNY pool for some days now, sorry.