There is a motion which states no alp running on poloniex can require an offset lower than 0.7%. If you dont like that, you’ll need to pass a motion nullifying that spread regulation motion. Saying you wont support a motion unless it goes directly against existing motion is a difficult place to put operators in.
Are you referring to this motion?
As Polo is going to offer <0.15% fee for market makers the minimum spread is going to be 0.65%. Hopefully the liquidity situation is will be more transparent as more people place open orders rather than dump directly on the walls. Though I suspect some code about matching orders might go against that.
Yes, I remember that highly contentious and debated motion. See my response to it here: [Passed] Motion to regulate spread values for liquidity operations. I supported some sort of guidance but this went too far in my opinion and now appears to be unnecessarily constraining as I suggested at the time.
As I’ve shared my position in that thread I’m not going to debate this again or raise motions to nullify. Instead I will call for the minimum offset this motion allows in order to have my support, which I understand is 0.7%.
@woolly_sammoth and the NuPool team
For few weeks I have seen this error running my client, and even with the reset timer or using the Nagalim client does not fix the problem. This happens only with poloniex.
INFO: poloniex - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - xxxxx
The only way to overcome this issue is to reset the client manually, but now, possibly due to poloniex api issues, it has to be restarted every 30 mins / 1 hour on average.
I believe it is affecting also other LP as mentioned on the NuPool 7 thread.
This could be the main cause why we see very unreliable ALP behaviour as shown in the charts as @masterOfDisaster pointed out elsewhere.
Has this problem been corrected with NuPool8 ALPv2?
Will the use of NuBot be encouraged? Any detailed tutorial for begineers in the plan on how to use it specifically with our biggest pool? (NuPool)
It will be forced. Maintenance of pybot is discontinued.
I am currently drafting Nu tutorials which will go live with the beginning of this operation.
This is indeed a problem. I noticed it a couple months ago and I was hoping my restart would fix it, but you’re right that it didnt. We will be doing basically a rolling reboot of liquidity operations as ALP v2 comes out, and the software should be a lot more robust.
Looks reasonable to me and it is in accordance with my belief that we should reduce the liquidity provided by ALPs.[quote=“masterOfDisaster, post:15, topic:3631”]
product to USD(expressed in BTC), but to USD.
What is the difference?
The supported trading pair.
BTC/NBT != NBT/USD
As long as wel support BTC/NBT (which will likely go on forever - B&C Exchange will have no USD…), there will always be a more losely pegged NBT in that pair than in a NBT/USD trading pair.
But a peg to USD (NBT/USD) is what Nu promises saying “…always a Dollar…”
I’ve amended the title of this post to explicitly put it up for voting. I had thought that voting would start naturally but I can’t find reference to this grant in the current custodian votes.
The funds for the current NuPool operation have run out. I’m going to stop the pool server and make a start on updating the Operating System and making the switch over to the ALPv2 software.
As I’m doing that I will create an Ansible playbook which will be able to automate the process. I will then make that available ot othe rpool operators so that the process of making the change to v2 can be as smooth as possible
Apologies for the slightly shambolic change-over. I am continuously sorry that Nu falls to the bottom of my priority list. That is just where I am at the moment but, sorry, again.
I feel confident that FLOT and the NuBot gateways put up by @zoro and @masterOfDisaster will be able to hold the peg while NuPool takes this break. I think the combinations of Liquidity provision available to shareholders show an increasingly healthy ecosystem within Nu. I hope that ALPv2 is able to live up to the promise and bolster the ALP portion of that.
Well, the problem now is in Bittrex. It has no LP support!
Oh wait! There is a passive dual pybot gateway there:
I almost forgot
But it needs FLOT’s funds.
@Nagalim, can you send some T3 funds there and ask them from FLOT later?
Firstly, id need to decide on a price. Which brings me to the next point, the T3 gateway is set up so that I can charge whatever i want based on whether i want to make the trade or not. So if I charge a 10% markup, how do i know it wont later get rejected and then we’re all in a sticky predicament.
I think FLOT should make a 1of-8 btc address with $5k btc in it for sending to gateways.
Let’s say 3-of-8 or at least 2-of-8; trusting you and trusting every single person in FLOT with $5k is quite different. One compromised key and all will go in a puff.
What about 2 2-of-3 groups with $5k or $10k each?
That way both agility and relatively high security together with the need to achieve consensus for executing transactions could be achieved.
Alternatively one could think about singlesig FLOT addresses with smaller amounts of funds, although I think this is not the way, which Nu should go.
But a subdivision of FLOT with more agile multisig (e.g. 2-of-3), where only relatively small amounts are kept, makes sense.
##It looks like the whole NuPool is down:
##maybe already for hours:
Oh my - I missed one of the important posts when I replied to a multisig topic here…
I’m sorry for the confusion.
You forgot to sleep again?
Bittrex has 0 liquidity that is why we need FLOT to send funds to @Cybnate 's nubot there