i agree with Cybnate here.
we either try to profit by keeping the peg (paying by NU) or profit by wider spread (paying by speculation)
i am afraid by “using” both is too greedy 
(and destroy the peg eventually)
As described above, it’s impossible to keep both nbt/cny and nbt/btc stablly pegged while having an abnormally high btc/cny (which basically is an result of abnormal cny currency control by the PRC government).
This insight should make us think how cn-nubit is going to work. Nu might never, at least seldom, have a peg for it inside China.
OK , NBT price base on BTC/USD market , but at CNY poon ,the price base on CNY/USD from yahoo
@mhps is correct. The issue here is that there is a black market cny price that differs from the yahoo price feed. What I will be doing with this pool I hope will be generally applicable and will usher in new waves of attempts at understanding what it means to offer a peg. I have yet to have a really good dialogue about the concept of the ‘shift’ parameter and I think the only way I’ll get that conversation is by implementing it and just seeing what happens.
We have a chance to make a lot of money here. Block consensus if you like, but I think enough shareholders understand that something here both has potential to be big news and is currently broken in this incarnation.
I don’t really care about what cmc thinks nbt are worth. What I care about is that people can buy and sell nbt at fair prices. If cny is really valued 3% lower than the price feed says it is, we should be selling our nbt for that much more cny. However, that’s the obvious part. The beauty is that we need to pick up the buy side as well.
Offset>shift. With a 1% SAF I can do a 0.65% shift for a 1.5% tolerance.
The other option for automating shift is to use more price feeds to dynamically find the black market feed and simply peg to that instead of yahoo. We would need to put the server on that feed, whereas the other option keeps the server feed the same and just lets the custodians shift around it within an envelope.
You can hardly convince any (none pool op) shareholders with these jumbomumbles.
Tolerance is something shareholders can understand: it is the allowed fluctuation for the price that shareholders support. If I run a 1.5% tolerance, I could potentially be paying custodians that are buy nbt at $0.985.
SAF is spread after fees. We’ve been calling this 1% for btc pools and I’d argue that my pool is the first fiat pool to really experience a good bit of volume. Asking for a 1% SAF should not be that out of the question.
Shift is a the shift an individual custodian applies to the price, making it shift from the server pricefeed. Automating the shift parameter is a way to decrease the actual spread we see on exchange. The idea is that custodians have incentive to rebalance funds under fixed cost conditions and this is away to smoothly apply pressure to rebalance.
With these parameters, a custodian with 0 sell side on the NBT/CNY pool would be putting up orders at:
sell $1.0135
buy $0.9995
Is this the deviation in the config file? If yes why is it changeable by the user?
It is in the server config file, it is not changeable by the user.
The user currently has two parameters for trading in their client config file:
Offset
Deviation
I will be adding a third parameter to the client config file:
Shift
I intend on providing 2 things in my grant application:
Tolerance
SAF
The thing is, the operator isn’t actually in control of SAF, the participants are (within the constraints set by the tolerance). However, there is a concept of defaults and it has been shown time and time again that the LPs will basically run whatever the operator either tells them or puts in the default config files. This may change in the future, but for now the operator basically has full control over what the clients are running simply because the LPs aren’t concerned enough to change them. That’s fine for me, because I’m doing my best to ensure optimal parameters in my default files anyway. That is one of my strategies for keeping LPs on my pools: provide better software than the other pools.
some time there are 0ppm
2015/11/07-03:20:06 INFO: bter - balance: 0.76676203 rate: 0.27% ppm: 0.00011274 efficiency: 100.00% rejects: 0 missings: 0 - btc - ask: 59.4200 x 0.27% - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:21:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:22:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:23:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:24:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
What offset and deviation are you running? For it to go smoothly from paying you to not paying you like that, the price probably changed and you went outside the tolerance. At least, that’s one possibility.
deviation = 0.0025
offset = 0.005
no shift? Your settings are actually tighter than normal. Still, I’m not sure why you’re having that problem. Anything in the logs?
I’m going to be upgrading a bunch of stuff later today, there will be a server restart (a bit more than just a restart hopefully).
set shift=-0.002 now
Ok, would you mind deleting shift from the config file and trying that? This will result in a vanilla bot with an SAF of 0.6% instead of 1%.
I just got the latest alpcollectiom git update.
I don’ t see the price update messsages i used to see in teh log file and I get
WARNING: unable to update BTC price from bitfinex
my walls don’t seem to move unless I restart client.py
config has
deviation = 0.0025
what does it mean? if feed price is away by 0.25% then move the wall?
What is the tolerance? 1% ?
Everything you’ve said is correct. I haven’t changed anything about how the bot updates the price from bitfinex, so I’m surprised you get that with alp-collection and not with the other branches.
If the bot is not updating price properly, that would explain the issues @huafei is experiencing.
this is network issues
Can you please confirm that your price updates using this:
and not this:
yes.