Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 147. (Read 903163 times)

It's that time of year, where the payout wallet is getting so fragmented it is occasionally timing out when trying to process a payout.  At 21:00 GMT, payouts will be paused for 2-3 hours (depending on network block rate for confirmations).  Earnings will continue to accumulate, it is only the actual payment processing that will be paused during this time.


EDIT:  Moved up to 20:00 GMT after finding a number of failed payouts in the last few hours.

Depending on size and manual vs auto, it is either every 30 minutes or once an hour.

Hi, I'm sure this question has been asked many times before, but :

How often are payments processed ? Approx every 30-60 mins ?

Well, looked like it wasn't quite ready for prime time.  Rolled back to the old software.  A bug that I thought was fixed happened again, where the libevent listener completely stops responding to connections/accepting new ones.  Always fun to debug something that you can't figure out the exact cause of since it isn't crashing anything.


EDIT/UPDATE:
Added a *ton* of logging to the US validation server, hopefully I'll get woken up around 4 AM to it freezing and the logs will tell me where this timeout is occurring.

In the meantime, time to start planning out ScryptGuild while waiting for the bug to resurface on the validation server.  All backends are back to the known stable code, sorry again to any users who were disconnected as a result.

Awesome. Well done.

The beginning of a new era:  https://blockchain.info/tx-index/6be69ab8b3faad4ee99c2323a25402413f00409efa0bc4641e84cd416dedab13

The first live block solved with the new software.  It has been deployed on 2 of the 4 public servers now.  I'm also comparing two slightly different variations of the backend on those servers to compare CPU load on the primary thread (network i/o processing).

These new servers are wired in very heavily to the alarm system so that they will alert me if they become unresponsive (not just crash).  After a few days, the remaining backend servers will be updated once the benchmarks between the two variations have enough data available.

The new stratum server has now been deployed on *one* of the public servers, with heavy monitoring in place.  I am sorry to the quarter of users who experienced a disconnect as the backend was switched over.

Again, it is on your end if you are seeing issues right now. All servers are functioning normally and nothing has been changed on the back ends in weeks.

It started during the night. It was OK before that... And it is OK on other pools... I don't think it is a setup since I didn't change it for weeks... And it is not one miner


On all miners only pi is a bit different since it is not win but still about the same...

I can only suggest inspecting your setup. No server is having any issues and the pool speed is not reflecting any regional connectivity problems.

My Pi is getting problems and crashing all the time. My computer(and Pi) are suffering from stales, unknowns, old difficulty(no changes to difficulty or new block) with up to 18% rejects... After miner restart it takes up to a minute to get work... What is going on... I'm loosing 200GH...

Well, the great news first:  The new stratum code has not crashed in the last 3 days while being exposed to the most volatile server (the frontend used for filtering botnets/ddos/validating miners).

Good news:  The new code is also now interacting with the website properly for all Worker management functions (renames/payment method/difficulty).

Bad news:  It hasn't been deployed to backends yet.  I've been spending all day trying to break the new code in a way that would allow a user to get credited for shares they shouldn't.  So far, this hasn't worked (which is good).  Everything used for share validation was copied from the old code, but some changes to the structure of work assigned to miners have required rewrites on areas which I know other pools have screwed up in the past (50BTC accepting lower diff work and crediting it at the adjusted diff, for example).


It's been a long project (2 weeks instead of 1), paired with some downtime from illness, but I think all this time will be worth it in the long run as it expands how much can be done with the pool backends.  ScryptGuild will be expanding on the backend even more, experimenting in some additional interaction between frontend & backend, and the changes which work well will be ported back to the BTC Guild side if they're more efficient or more responsive.

Implementation? Yeah, that would be good. I supposedly purchased a .bit domain in September last year and paid 0.1 BTC for the privilege. After hearing nothing back from them and chasing up the supposed contacts on their wiki page and even sending a PM to someone allegedly responsible for the endeavour on this forum I heard nothing back. I've still got the email and the bitcoin transaction ID so if anyone happens to know someone who's skilled enough to actually respond to people that buy their alleged product, please feel free to mention it here or send me a PM please.

I suppose this is why you very appropriately used the past tense, Eleuthria, "it had a good idea." 

thanks @el

I'm still not a huge fan of NMC itself.  It had a good idea.  It does still work.  But the implementation feels so terribly inefficient for what it's being used for.

However, at least it had a good idea, and does have a purpose outside of market speculation (even if bulk of its price is pure speculation).  DVC/IXC have no such redeeming qualities.

says had/has so its take it as you want... 

had?

NMC had/has a purpose.  DVC/IXC are just garbage coins.  Big difference.

hey @el,

think similar was said about namecoin, then btcguild implemented it and then btc skyrocketed and nmc rode btc's coattail from cents to dollars....
I think btcguild helped give namecoin some street cred....

maybe same can happen with those others??

Sounds like the "Please try again." Solution worked. This is something that will likely be more streamlined in the new stratum back end being deployed. Instead of asking the user to try again it will add failed attempts to a retry queue.