Done. Thanks for the support.
1 Like
Sorry for the delay in giving my feedback.
I never fully understood how the dutch auction worked inside the ALP rationale created by creon.
To me also, Fixed cost ALP’s concept is much simpler to understand.
I speculate that it would be also the case for anybody that wants to provide liquidity, therefore increasing the potential for NuNet to attract a much bigger liquidity.
187e547074c3fe0508a56d684dd705ec5d9929ee verified and voted.
Just a question. I remember that Creon’s ALP uses pybot as its default bot program.
Is it also the case for FC ALP and if yes, why not using NuBot?
1 Like
At the moment you can only use NuBot if you control the funds, you’d need to run an MLP, which is something completely different and requires either using own funds or account management.
ALP doesn’t require control over the funds (by the pool operator) that are used for liquidity providing.
The parts of the ALP software (server.py) that needed to be adjusted to make fc_server.py were small (on client side there’s no change required!):
diff server.py fc_server.py
39,40c39,40
< _wrappers = {'bittrex': Bittrex, 'cryptsy': Cryptsy, 'poloniex': Poloniex, 'ccedk': CCEDK, 'bitcoincoid': BitcoinCoId, 'bter': BTER,
< 'testing': Peatio}
---
> _wrappers = {'bittrex': Bittrex, 'poloniex': Poloniex, 'ccedk': CCEDK, 'bitcoincoid': BitcoinCoId, 'bter': BTER,
> 'testing': Peatio, 'cryptsy': Cryptsy}
141c141
< def liquidity(self, bid, ask):
---
> def liquidity(self, bid, ask, identifier):
146a147,150
>
> tier:pair:exchange:botsessionid
>
> Example of a valid identifier : 2:BTCNBT:ccedk:nubotsession3
149,150c153,155
< self.rpc.liquidityinfo('B', bid, ask, self.address)
< self.logger.info("successfully sent liquidity: buy: %.8f sell: %.8f", bid, ask)
---
> self.rpc.liquidityinfo('B', bid, ask, self.address, identifier)
> self.logger.info("successfully sent liquidity: buy: {0} sell: {1} "
> "identifier: {2}".format(bid, ask, identifier))
153c158
< self.logger.error('NuRPC: client not initialized')
---
> self.logger.error('NuRPC: liquidity client not initialized')
471c476
< maxrate = config._interest[name][unit][side]['rate']
---
> # maxrate = config._interest[name][unit][side]['rate']
481a487
> imprate = float(config._interest[name][unit][side]['rate'])
482a489
> maxrate = imprate * 10000000 / mass
599c606
< curliquidity = [0, 0]
---
> curliquidity = {}
602a610,614
> exchange = repr(keys[user][unit].exchange)
> if exchange not in curliquidity:
> curliquidity[exchange] = {}
> if unit not in curliquidity[exchange]:
> curliquidity[exchange][unit] = [0, 0]
604,605c616,621
< curliquidity[0] += sum([order[1] for order in keys[user][unit].liquidity['bid'][-(s + 1)]])
< curliquidity[1] += sum([order[1] for order in keys[user][unit].liquidity['ask'][-(s + 1)]])
---
> curliquidity[exchange][unit][0] += sum([order[1] for order in
> keys[user][unit].liquidity[
> 'bid'][-(s + 1)]])
> curliquidity[exchange][unit][3] += sum([order[1] for order in
> keys[user][unit].liquidity[
> 'ask'][-(s + 1)]])
607,609c623,631
< curliquidity = [curliquidity[0] / float(config._sampling), curliquidity[1] / float(config._sampling)]
< _liquidity.append(curliquidity)
< nud.liquidity(curliquidity[0], curliquidity[1])
---
> for exchange in curliquidity:
> for unit in curliquidity[exchange]:
> liquidity = [curliquidity[exchange][unit][0] / float(config._sampling),
> curliquidity[exchange][unit][4] / float(config._sampling)]
> _liquidity.append(liquidity)
> identifier = "1:{0}:{1}:{2}".format('NBT'+unit.upper(),
> exchange,
> config._pool_name)
> nud.liquidity(liquidity[0], liquidity[1], identifier)
788c810
< if curtime - lastsubmit >= 60:
---
> if curtime - lastsubmit >= 5:
1 Like
I see. Do you remember the difference between PyBot and NuBot?
I suppose FC ALPs will be using something close to PyBot but in that case how can the parametric order book that will be implemented in the next NuBot version be implemented and used?
NuBot is currently only working for MLPs (e.g. NuLagoon; soonTM maybe my NuBot on hitBTC).
PyBot is currently only working for ALPs.
NuBot has been soundly developed ever since development was started.
PyBot is hacked together code (correct me if I’m wrong) that acts as a proof of concept for an ingenious concept, invented by @creon: the automated liquidity pools (formerly known as TLLP - trustless liquidity pools).
NuBot requires a lot of CPU power.
[edit] But as I found out a few minutes ago: only if being run in server mode; without server mode CPU load looks like thison my RaspberryPi 2 (4 CPU cores):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22483 pi 20 0 321m 60m 10m S 101.8 6.2 9:14.09 java
2337 pi 20 0 680m 559m 32m S 32.7 57.5 5357:27 nudIf you don’t need the server mode (maybe because you run it on a headless RaspberryPi…), NuBot is more CPU friendly than with server mode and can run very well on RaspberryPi 2,maybe even on a RaspberryPi 1 (although that’s close to the limit of it)!
[/edit]
PyBot doesn’t require much CPU power.
Exactly that - with an adjusted server.py that’s called fc_server.py.
@woolly_sammoth is working on a solution that will integrate NuBot into the ALP client:
That should give ALP clients the same features NuBot has.
If you intend to run NuBot on a RaspberrPi, I recommend to get a RaspberryPi 2. The CPU load NuBot causes is at average on 75% on a RaspberryPi 2.That means 3 of 4 cores are constantly busy.
Here’s output from top:
top - 06:53:04 up 8 days, 9:26, 2 users, load average: 5.16, 5.21, 5.14
Tasks: 91 total, 1 running, 90 sleeping, 0 stopped, 0 zombie
%Cpu(s): 67.0 us, 3.1 sy, 6.6 ni, 21.7 id, 1.4 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 996848 total, 982224 used, 14624 free, 52212 buffers
KiB Swap: 102396 total, 1540 used, 100856 free, 191224 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2929 pi 20 0 338m 132m 11m S 277.4 13.6 2245:14 java
2337 pi 20 0 680m 564m 37m S 28.0 58.0 4120:01 nud
You could move nud to a different machine to reduce some CPU load (nud is required for broadcasting liquidity information into the network).
PyBot on the other hand causes single digit CPU loads:
top - 06:49:33 up 26 days, 14:26, 2 users, load average: 1,64, 1,41, 1,42
Tasks: 7 total, 0 running, 7 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,2 us, 2,8 sy, 1,8 ni, 91,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
KiB Mem: 998176 total, 974844 used, 23332 free, 17308 buffers
KiB Swap: 102396 total, 7028 used, 95368 free, 145900 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26259 pi 20 0 64036 10m 5912 S 4,7 1,1 125:46.88 python
22490 pi 20 0 63832 10m 5968 S 4,0 1,1 18:00.29 python
1 Like
socket error (111)
any change?
The server kills itself every night because I don’t have nud on. I’ll restart it tonight. This will not be an issue once I’m operating on nupond instead of a test server.
Tks for the tip about Pi.
So right now more than half of the liquidity is provided by a bot behavior different from NuBot. Doesn’t make NuBot as half
Valuable? If Pybot is lighter than Nubot, doesn’ t it make Pybot more efficient than Nubot and shouldn’t it make it the main bot?
I m trying to see to which extent Nubot is crucial to Nu.
I guess the answer is in the parametric order book…
Pybot is a server-client pair. Nubot is everything in one. They are different programs with different goals in mind, and both are useful if not vital to Nu.
1 Like
I’m very happy to finally see this idea articulated well and so I am voting for this proposal. I suggested the beginnings of a similar idea back in March but this is more relevant as I was considering the operator fee and requested funds as the same amount.
This is a superior method of purchasing liquidity that will balance liquidity targets and encourage lower interest rates.
Thanks for bringing this interesting discussion up. I think given long enough time and a static boundary condition all models will converge to the same interest rate. The feedback loop of the fixed cost scheme is much shorter, making price discovery much faster, giving us a more agile system in a volatile market.
1 Like
If this succeeds and reduces costs in the long-term, credit is due to yourself, Nagalim, Masterofdisaster, and all others who brought the idea to life here: Fixed total payout for liquidity providers to enhance liquidity security and pool operation.
1 Like
running the test client again
Hi @cryptog
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 604 (6.040000%)
Share Days: 243446099 (7.048140%)
Vote for this only if you think fixed cost should be explored experimentally using shareholder funds. It will not affect the total requested funds of NuPond Term 5, but is only proposing an alternative reward protocol, and only on the NBT/BTC pair.
1 Like
Voted
1 Like
Hi @huafei
Here are the details for the Motion Vote on 187e547074c3fe0508a56d684dd705ec5d9929ee:
##187e547074c3fe0508a56d684dd705ec5d9929ee
Blocks: 820 (8.200000%)
Share Days: 320881621 (9.325522%)