I’m afraid I’ve done a silly thing. in creating scripts to automate the setup of ALPv2 for other pool operators I have inadvertently deleted the nud directory and wallet. Contained in the wallet was the private key for the address currently being used for voting on this grant.
I’m going to change the address in the OP and on daology. Apologies for the inconvenice.
The slightly better news is that the scripts are coming along nicely so automated set up of the ALPv2 software will be available soon.
if you have old backups of the wallet and your original 100 keys haven’t been all used, and your “lost” priv key was generated from the same wallet, the key should still in the backup. You only need to send some coins to it to activate the key i believe. (or get 100 new addresses after restoring the backup and pickout the address that had been posted in the old OP.)
Very bad that this is so difficult to pass. This service gives a great value to NU and it isn’t expensive in contrary with other more expensive proposal that is oftenly missing from Poloniex! @woolly_sammoth, will you consider lower the tolerance to 0.009, perhaps it will give a chance to be voted by more voters.
The ultimate aim is to automate the server parameters so that they change in response to market pressures during the course of the pool operation. That’s a little way of though and needs some work on what actions the software should take in response to certain market conditions. The upshot of that is that the tolerances will come down and the peg will get tighter.
This operation though is the first outing of a completely new software. It has had testing periods but the only safe way to see that it does the job it is intended to do is to run it in a comparable manner to the software it replaces. That is why the pool parameters have been kept the same, not from wanting to make Nu pay higher than necessary for the service the pool provides, but to allow us to see that pool mk2 is the same as pool mk1. Once that is confirmed, we can start tinkering with parameters.
This makes sense and I agree with Nagalim. There shouldn’t be any hesitation in voting for this. We need this passed so we can get the new software tested and ready to use for other operators.
Added to my datafeed as I like to support the developers and this was going to pass anyway. Hopefully speeding up the process assuming I had any subscribers to my datafeed left
Thanks everyone for passing this grant. The pool software is operational on https://eu.nupool.net:443. @willy is working on a tutorial for NuBot and it does seem that there is a slight issue with the NuBot Bittrex wrapper which appeared in testing yesterday, I hope to get that fixed tomorrow.
The pool is funded and payouts are active so do point NuBots at the pool if you are so inclined and know how to do so (the UI does make it really easy). Be aware though that there may be some changes required with the potential incoming NuBot fix. I’ll do a more formal announcement once the full system is felt to be solid.
I thought it would be related to Bittrex that my NuBot wouldn’t initialize orders (and doesn’t broadcast liquidity).
Is that slight wrapper issue related to initializing orders?
If so, I might raise an issue on Bitbucket next time I find something strange (am I allowed to do that?) to make you aware of it (even if I think it’s related to my machine or the exchange…).
Here’s a part of the log from one of my last attempts:
Ah. OK. This is because of the way Java handles ssl. It needs to know about the certificate in order to verify the connection.
To fix this issue, navigate to the <nubot_dir>/res/ssl directory and run ./updateKeystore.sh. That will fetch the latest ssl keystore form bitbucket and will make NuBot work properly.
