I gotta say, it’s pretty sweet to be the original LP on a pool. I’m making over 8 cents an hour on less than $10. Well, hypothetically anyway.
Be glad about your head start. Will be there quite soonTM
I should trademark ‘now’.
BTW I’m afk, but feel free to play around client side. I only changed a few key lines in the ‘credit’ subroutine of server.py, so you should be able to use the standard client without issue.
I’ve already updated https://github.com/Lamz0rNewb/alp-collection/tree/experimental/unix to make it easier for others to play with the new pool
Looks like this so far:
2015/09/13-19:36:48 INFO: starting PyBot for cny on bter 2015/09/13-19:36:49 INFO: successfully deleted all orders for cny on bter 2015/09/13-19:36:49 INFO: waiting 10.58 seconds to synchronize with other trading bots for cny on bter 2015/09/13-19:37:03 INFO: successfully placed ask cny order of 20.9000 nbt at 6.40774792 on bter 2015/09/13-19:37:48 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 95.00% rejects: 0 missings: 1 - APIKEY 2015/09/13-19:38:48 INFO: bter - balance: 0.00075569 rate: 6.51% ppm: 0.00094461 efficiency: 95.00% rejects: 1 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:39:48 INFO: bter - balance: 0.00167528 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:40:48 INFO: bter - balance: 0.00261988 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:41:48 INFO: bter - balance: 0.00356449 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:42:48 INFO: bter - balance: 0.00450910 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:43:48 INFO: bter - balance: 0.00545371 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:44:48 INFO: bter - balance: 0.00639831 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:45:49 INFO: bter - balance: 0.00734292 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY 2015/09/13-19:46:49 INFO: bter - balance: 0.00828753 rate: 6.51% ppm: 0.00094461 efficiency: 100.00% rejects: 0 missings: 0 - cny - ask: 20.9000 x 6.51% - APIKEY
The rate of 6.51% is the expected daily reward, right?
If I try to derive the (expected) daily compensation from the ppm of 0.00094461, I get 1.3602384. And 1.3602384/20.9 = 0.06508, which is 6.51%.
I need more money on that pool!
Did you ever try to rename a github project?
I think I’d like to change it to alp-collection.
Let’s try. If I mess it up, I go crying. If not, I’ll update the link above.
ninjaedit: it worked. we now have a alp-collection github project
Disclaimer or whatever: this pool will never pay out and any funds you lose are your problem.
(I.e. it worked!)
That was clear. I was just trying to make fun when I wrote
I think the made that clear…
Your adjustments seem to have worked. Great!
The alp-collection is up-to-date, albeit not really tested. But hey, it’s in the experimental branch
Looks like I hijack the test of the fixed rate pool to have the alp collection tested as well
You guys are fast. Will test it in a day or so.
My zero-rate offer is constantly declined.
weird. You’re saying because the pool is full? Have you tried using like interest=0.000000001? It’s supposed to take the cheapest liquidity first.
Anyway, that’s actually one of the reasons I really like this setup: it’s actually less buggy. When a pool reaches target it does all sorts of weird stuff. By lifting the target, we are able to have a lot smoother of an experience.
The biggest concern I have is that I’m worried there’ll be a bug in the program and it’ll pay out a high rate to a bunch of people. I don’t think that should happen, but only testing will tell I guess.
Edit: Speaking of bugs, I got a seg-fault and server.py killed itself. I don’t know why, nothing in the logs or anything. I’ll figure it out at some point maybe. It may have run out of memory; Nud is such a pig.
In the initial trial period maybe one can run the old and the new setups in paralell, letting the new one dry-run (with liquidity info feed, calc everyone’s balance, but don’t actually pay).
Then switch to the new one but make actual payment tx like every week so there will be enough time to watch how things go.
I was basically planning on doing exactly that (without the liquidity info though, I’m not feeding this a custodial address without a grant). A user could theoretically get credited on both pools if they both were shareholder funded at the same time.
But yah, I have it up and running to play around. Again, this was a super quick bandaid fixup just to see how it goes. If it looks like there’s interest, I’ll mess around with it more. I’m hoping I don’t get any more of those seg faults.
This is gonna end up being a can of worms, but I think it’s worth pointing out that this method exacerbates the ‘switching’ issue. The switching issue is such that if the peg is unbalanced it will cause providers to start trying to switch to the other side of the peg using the peg itself, causing LPs to burn up all their funds to exchange fees. It’s a phenomenon we haven’t really seen, but was talked about theoretically a while back. Creon came up with one of my favorite solutions to the problem:
We may be able to ignore this issue unless we start seeing it happen.
Why does the method exacerbates the ‘switching’ issue?
@creon’s method also discourages someone to convert NBT to USD not using the peg, e.g. selling NBT for BTC then sellling BTC for USD.
@creon really put a lot of thinking into TLLP.
Let’s make some names. Fixed Reward ALP’s are the normal kind and Fixed Cost ALP’s are this new method, OK?
So a fixed reward pool that hasn’t reached target on either side has no switching problem because the incentives on both sides of the pool are the same. Dutch auction and Fixed Cost models both have asymmetric rewards when competition on the two sides of the pool is drastically (or permanently) different. There is very little preventing an LP from selling to another LP the moment they buy nbt of the rate is different enough. That causes the LP’s to play hot potato.
You’re right that creon’s idea isn’t really a solution either. The best solution is to keep a moderate peg spread and to try to keep global buy and sell side balanced so that competition on the two sides of the peg are similar. The unseeded auction will help with that by providing buy/sell side network rebalancing on the order of days.
OK got it.
Obviously and the ALP (formerly known as TLLP) software runs remarkably well.
He was a brilliant mind, which others also recognized:
But be was a kind of rebel as well.
As much trouble as it might make to integrate the thoughts and work of rebels as much might this kind of thinking be required if Nu wants to become big.
We need controversial thoughts and discussion.
I believe only that way Nu can work and grow sustainably.
So the server restarted for some stupid reason last night. The funny thing is, I reboot it this morning and now I’m the only one running on the pool. Rewarded for providing a shitty service, hell ya!
I’m pretty satisfied with the implementation at this point. It’s not an amazing piece of code, but it leaves basically the entire bot intact. The operator can even set a target at which dutch auction takes effect.
If I can get 2 testers other than me for a few days I’ll test btc/nbt for a bit and post a motion. And if you like big numbers registered on a server with no true value, boy have I got a deal for you! We’re now crediting 7.5 Imaginary NBT per day per side!
Disclaimer: Nothing is real.
Can you or @masterOfDisaster point to me the best pool client for switching between NuPond fixed cost, LiquitBits, and NuStream? I think I am using @masterOfDisaster’s NuPond fork but I am not sure (how do I find out? README.md doesn’t tell) I tried several version a while ago.
For fixed cost pool to work optimally when liquidity is low, it is best if LPs from other pools can jump in easily.
It’s super easy. If you’re already running on Bter’s CNY pool, just change the ‘server’ parameter at the bottom of the config file from NuPond:3333 to:
I can recommend to try the experimental branch of by “ALP collection”:
It contains a collection of all ALP operations I’m aware of, e.g. the windows and the unix version of this pool (including recommended settings for offfset, server settings etc.).
But this obviously just a shameless plug, because @Nagalim is right with his last statement.
ninjaedit: I just checked my ALP bot on the fixed pool and it looked strange. I restarted the bot and it still looks like:
2015/09/16-04:06:15 INFO: starting PyBot for cny on bter 2015/09/16-04:06:16 INFO: successfully deleted all orders for cny on bter 2015/09/16-04:06:16 INFO: waiting 13.45 seconds to synchronize with other trading bots for cny on bter 2015/09/16-04:06:32 INFO: successfully placed ask cny order of 20.9000 nbt at 7.23150780 on bter 2015/09/16-04:07:15 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - [...]