Thanks I fixed that.
That’s basically what I am doing: https://github.com/creon-nu/nu-pool/blob/master/python/exchanges.py#L111
So if the current nonce is too large then it targets the average value of the bounds and otherwise it tries to place itself in the third quarter of the allowed range. It however still happens that it overestimates the nonce first and then underestimates it in the second round and so on. It probably should have some memory and fall back to the dumb but at some point always working method by setting
new_shift = ( (old_shift + 7) mod 200 ) - 100
Unfortunately trial and error is more or less the only option with those ideas.
Absolutely, I am trying to imitate the NuBot’s selection here. Right now the clients get their price from the server (get /price) and blindly follow it, so currently the server operator could fool the clients and propagate an invalid price. Therefore both, client and server, need to check the price and if the client sees that the server price deviates too much from the real price, then no orders should be placed.
I think you can write the client logic without NuBot functionality and statistics in about 50 lines of code. I also see the whole project here as proof-of-concept, the server client communication is far from being efficient by using json objects (compare to stratum for example). If someone wants to launch a GHash scale liquidity operation with thousands of users then a more sophisticated server communication protocol and serious development efforts are required.
This would be really great!
Of course I will not abuse my custodian address to submit pool liquidity, that would be irresponsible without the agreement of the shareholders. So if I am planning to do this then I will create a new grant proposal and ask for the OK to run this operation - and for the corresponding funds of course (after the operation).
This sounds more like a more public version of the Nu Lagoon, since the pool operator has the private keys and could run away with the coins.
