the Pybot can avoid to eat other side’s order with a price check, nubot cann’t do this.
a tiny spread need a stable pricefeed avoid different price between main feed and backup feed.
a question about voting:
why SDD is over 50% so quickly in all proposals?
Has something changed in voting mechanism?
Has any meaning now?
A stable price feed was developed (the price streamer) which both NuBots and ALPv2 can hook into. That has been unavailable for the duration of the current NuPool operation. As far as I know it just needs a restart but I don;t have access to do so. I’m hoping that @desrever will see my requests to do so soon and restart it but I know he’s been very busy with other projects.
The MultiCustodian setting in NuBot was designed for this exact problem. NuBots synchronise themselves using NTP and move orders during a small window each minute (if a move is necessary). That should prevent wall clashes but the setting does impose a minimum spread
INFO - Forcing a 0.01$ minimum spread to protect from collisions
That may need revisiting if this setting is to be used with whatever happens with spread discussions.
@masterOfDisaster of disater: you asked in another thread about the ‘WallShiftThreshold’ parameter, I’m going to answer here I’m afraid. That affects the point at which NuBot decides a wall move is necessary. For multiple NuBots on a pair, the Threshold should be the same otherwise Wall shifts will move into other bots walls and we end up trading with ourselves. All bots on a pair should move at the same time to the same price. We should be using the price streamer as intended and will do so once it is back and working. Faling that we should all be using the degfault price feeds as coded into NuBot and ALPv2 to ensure the price is valid.
I assume some old shares being used to vote.
Apologizes for the huge delay.
Voted.
But to me the total target of 6k NBT is too small.
I d like to see a much higher target for next proposal.
The target was lowered in response to the lower cost. Liquidity providers get a smaller maximum reward but it is easier to reach the maximum reward. Seems to balance out and make providing liquidity still attractive
1 Like
The target is a minimum not a maximum.
I disagree. And for a lot of reasons. Let’s start with the big one: centralization. As you can see, the price streamer requires a ‘restart’ from a central body. Almost no matter what, in order to keep everyone on the same price at the same time there has to be centralization, unless we make an entire blockchain just for nubot. This is woefully less robust than what we have now, people using their own derived price feeds.
My ideal LP is one where people design their bots themselves to take advantage of the market and slightly move their orders around in the allowed spread band to either reduce or increase their exposure to market orders.
Furthermore, if everyone moves their orders all at once it looks a lot like manipulation. Sure, if they go and read all the threads in Nu and keep up on the nubot development, maybe they’ll know about price streamers and a bunch of other complex concepts, but likely not. Image on the orderbook is very important and the image of a single wall moving at once is one of centralization. And funny enough, that’s because it is (see first point).
If i add in a line in my bot to wait 1 second before placing my order on top of everyone else’s order I can almost guarentee that I will never participate in a trade unless the entire liquidity is eaten. In fact, this would be very profitable because i would likely be one of the few remaining on the weak side and get paid the most.
I very much prefer the spread band model to the individual spread model. Note that so far every operation but the Tube has been using the spread band model without really talking about it. That’s what all our deviation conversations were about.
The best way to avoid collisions is to set an offset that gives a reasonable minimum spread when you take into account wallshiftthreshold and similar parameters and factors.
I showed that these fluctuations die out reasonably fast if the active shareholder stops voting incorrectly. More importantly, such a misconfigured vote will not pass unless ~50% of active voters vote for it, in which case if the majority of active shareholders are voting for it how can you tell it’s misconfigured from a blockchain perspective? The only case where it spirals out of control is for really really high apathy percentages like 99.9%.
The “server stats” page needs to show more info.
- the current users’ liquidity for both walls in order to be able to rebalance and to achieve max payout!
- the actual ask and bid reward for each user, now it is the same for both walls.
a lot of trade fee at swing of BTC , i am out of ALP v2 
No! Don’t let me get all the rewards 
check the trade fee at order history please…
always 0.25%fee
025% is for the traders.
For us (makers) is 0.15%
offset+txfee should cover for this.
Have you seen something else?
my nubot alway eat the order at other side , It is take fee by 0.25% 
Then your offset is too small - or you make a good deal by buying cheap orders.
“bookSellOffset”: 0.005,
“bookBuyOffset”: 0.005,
is that too small?
Nope.
Maybe there’s an issue with the price feed you use that is off from the price feeds others use, which causes the strange placement of orders?
done now! sorry for the delay…
Someone trusted should get in touch so I can give him instruction to restart the service in case I get hit by a bus ! @Ben also has credentials to access the VM
eat the sell order by nubot, no BTC at account , good luck
here is my setting , Is there something wrong ?
{
"apiKey": "xxx",
"apiSecret": "xxx",
"mailRecipient": "",
"exchangeName": "poloniex",
"dualSide": true,
"pair": "nbt_btc",
"rpcUser": "",
"rpcPass": "",
"nubitAddress": "",
"nudPort": 9091,
"nudIp": "127.0.0.1",
"mailnotifications": "NONE",
"submitLiquidity": false,
"executeOrders": true,
"verbosity": "NORMAL",
"gitter": false,
"multipleOperators": true,
"txFee": 0.2,
"priceIncrement": 3.0E-4,
"emergencyTimeout": 60,
"keepProceeds": 0.0,
"wallchangeThreshold": 0.2,
"webport": 8080,
"bookDisabletier2": false,
"bookSellwall": 1000.0,
"bookBuywall": 600.0,
"bookSellOffset": 0.005,
"bookBuyOffset": 0.005,
"bookSellMaxVolumeCumulative": 0.0,
"bookBuyMaxVolumeCumulative": 0.0,
"bookBuyInterval": 0.008,
"bookSellInterval": 0.008,
"bookSellType": "EXP",
"bookBuyType": "EXP",
"bookSellSteepness": "HIGH",
"bookBuySteepness": "HIGH",
"poolModeActive": true,
"poolURI": "https://eu.nupool.net:443/",
"poolPayoutAddress": "xxx",
"poolSubmitInterval": 60,
"mainFeed": "bitfinex",
"backupFeeds": [
"blockchain",
"coinbase",
"bitstamp",
"kraken"
]
}