|
Do you know when it happen last time? +/- 12 hours ago I restarted the pool because of software update.
|
|
|
|
Looks like "Average hashrate in last 10 rounds" value doesn't change.
Good catch! Fixed, thank you. |
|
|
|
If you wish to see the old downloads you put in your git then just add "/downloads/" to your git address.
GutHub has disabled being able to add new downloads and will delete all download files soon.
I know that "/download" trick, I just wanted to make the announcement simple :-). But the important part is highlighted. |
|
|
|
Because Github no longer provides "Download section", I moved Windows binaries of Stratum Proxy here: https://mining.bitcoin.cz/media/download/mining_proxy.exeThis URL will always serve the latest Windows binary. I tried to update links on websites to this new URL, but please let me know if you'll find old link to Github download section somewhere. |
|
|
|
Is it ok that the block reward calculation is being processed for about 50 minutes till now?
Yes, I turned maintenance scripts to manual mode because of some debugging. Blocks are processed right now. |
|
|
|
|
Congratulation! Do you have prepared scenarios for doublespend attack? :-)
|
|
|
|
|
There's mining.reconnect(). It should work in proxy, poclbm and cgminer too.
|
|
|
|
|
Nothing happen now. Cosurgi just reminds me the issue with Linode year ago, where I lost over 3000 BTC because of Linode's security hole.
Now the pool keeps only minimum funds, currently around 75 BTC. The rest is in cold storage.
|
|
|
|
|
Okay, wallet seems to be fine, I just processed all pending payouts manually. Automatic payouts will be enabled in few moments.
|
|
|
|
I'm migrating pool wallet to another machine and to the fresh wallet file (current wallet.dat is over 40 MB  . The old wallet have some unmatured blocks, so I turned off pool payouts and I'm waiting until all block mature. Then I'll check if everything is fine and I'll turn automatic payout processing again. Payouts should be working again in few hours, I'll surely inform you here. |
|
|
|
|
It will be better to ask Eleuthria to add standard error messages for unknown methods. It's actually pretty easy and it will make the life easier.
Auth messages are a bit sensitive, because pool may need database lookup. Especially during the server restart authorization messages may take longer time than usual, because of connection storms.
|
|
|
|
Thanks. However what if it's the first command after the socket is opened?
Why there should be any exception for first message? If the miner knows any recent session id, it should send mining.resume(id) firstly. If miner don't have any session id, it should send mining.subscribe(). When the pool doesn't understand mining.resume message, it should respond with standard error, not by closing the connection. Is there really any pool which closes the connection on unknown message? |
|
|
|
Well of course I like that (since I suggested it) but the only disadvantage I see is the pool really does not have a flag now in its parameters to tell the mining software whether it supports resume or not, so the only way to find out is if cgminer tries the command first. That's ok too, but the issue there is what the pool does in response to a command it does not recognise: some will drop the connection, and I'm not sure what others do. I need some comments from the pool ops please?
Pool should not close the connection on unknown message. Like this: {"id": 1, "method": "mining.resume", "params": []}
{"error": [-3, "Method 'resume' not found for service 'mining'", null], "id": 1, "result": null}
Server should close connection only when the payload is corrupted (thus there's no way to identify messages and respond with standard error). |
|
|
|
|
...and I'll also fix proxy to ignore any unknown parameters in subscribe notification. It wasn't intentional, I'm sorry for such kind of issue :-/.
|
|
|
|
|
Database migration was smooth, website downtime was 20 minutes + few short restarts. Also OVH issues seems to be fixed, I see zero packet loss from many of network locations again.
|
|
|
|
|
The first parameter is the rest of original Stratum idea; to be universal overlay protocol with some extended publish/subscribe features. To be honest, there's still no real use for initial meaning of the first parameter and the whole idea seems to be a bit overcomplicated.
So I'm offering to change meaning of the first parameter, let's call it session_id :-). I checked all known implementations (stratum proxy, poclbm, cgminer/bfgminer) and all three seems to completely ignore the first parameter. Using first argument as session_id seems to be fully backward compatible.
Any ideas?
|
|
|
|
As for the time out problem, is this a frequent problem? I've not had any issues with my miners, and have not seen any pool wide problems.
Not sure if anybody noticed, but OVH (quite a big european provider) has network issues today, which affected half of the european internet, because OVH's internal traffic is re-routed over other companies. |
|
|
|
However, I think simple minimum difficulty settings available through the frontend solve problems for large workers. And at least with my implementation, the pool will adjust very high speed workers to an appropriate difficulty before bandwidth becomes an issue. They'll see a spike at the very start, but with aggressive difficulty adjustments you can prevent it from being enough to saturate even on a very slow connection (3g/dial-up).
I agree that this will work, too, but it requires that user knows what's the appropriate difficulty for his miners. For the most users difficulty is simply abstract number. In the end, pools will use some mixed solutions like a) suggestion provided by mining software b) minimum difficulty set by the user on pool profile c) using higher default difficulty for unknown connections (will affect slow miners until the difficulty settle down, but it will help fast miners during startup). |
|
|
|
|
No, except that slow devices using the same worker name as fast ones will have huge difficulty and it will take some time to settle on natural level.
|
|
|
|
|
Show Posts
