Are you certain that an offset of 0.001 will not result in collisions with others running nubot? Because that will drastically lower your NAV.
Is there ever a point in time with 0.001 offset when a buy order you have on the books is at a higher price than the price feed? Because if this were pybot you’d definately have collisions at that offset.
I have no idea.
What is the minimum offset that will not result in collisions?
Depends on who you ask i suppose. I usually talk about deviation of 0.25% and that an offset equal to half the deviation will result in collisions. That’s my model of it, i dont even know if 0.25% is what’s used in nubot though (my analysis comes from using pybot in alp v1). @willy might know.
Does this mean your recommendation would be to get comfortably above 0.00125 then? Such as 0.0015?
Sure. There’s a txn fee going on inside the bot too, so im really just not sure about it all. But yah, I’d say that 0.0015 offset would give me confidence that your operation will not have NAV lowered by collisions with other instances of nubot run by other operators.
Based on your recommendation I just altered to the motion to specify a 0.6% spread, which will be done by setting the offsets to 0.0015 just as you suggested.
Sorry for the late change, but nobody wants wall collisions.
The new hash is: 29d364f8677c7c955d423747fcf5005fd00f2e6b
Great responsiveness thank you
Did you check this recommendation:
I’m suggesting this because of:
I don’t see any reason why I would need to increase the spread. Things will already like you have suggested because I am getting paid after the fact.
This reply is a little late but, for information, I don’t think there is a minimum offset in NuBot that would absolutely guarantee no wall collisions. There is too much variability in the price feeds that can be used. That is why the multicustodian option was developed. It was intended that this be used when multiple NuBits were being used on a single currency pair. It will force a minimum offset (just for safety) and will synchronise the NuBots so that all order movements happen each minute on the minute. That is intended to stop walls of different bots moving into each other.
@masterOfDisaster, ALPv2 uses NuBot as a client but isn’t based on it. To my mind, tolerance is a term used by the pool server to see why an order price is within a certain rank. Offset is used by the client to provide spread.
I should have looked up the right configuration parameter.
I’m talking about this client parameter:
"wallchangeThreshold": 0.1,
Which is according to NuBot documentation:
Parameter | Default value | Description | Admitted values
wallchangeThreshold | 0.15 | how much the price needs to change to trigger a wall-shift. | double. Expressed in absolute percentage. 10 = 10% , 0.5 = 0.5%Results as of 31/05/2016:
NBT Balance: 20,429
BTC Balance: 0.0012
Simple NAV: 20,430, a 2.15% profit
Bitcoin Price Adjusted NAV: with current price of 529.38, the adjustment is -2563, so 17,866, a 10.7% loss
Bitcoin Price Adjusted With Pool Payments NAV: NuPool rewards total 578, so 18,445, a 7.78% loss. Annualised and compounded rate of loss is 55%.
The adjusted NAVs have fallen a great deal over the last week because the account has been all NuBits while Bitcoin has risen.