Ah, so this setting does nothing at the moment?

Right now I see an option to set the failure threshold between 1 and 3600 minutes, but not to disable it altogether.  (Of course, 3600 minutes is 2.5 days, and I doubt I'll be off the pool for that long, but still...)

Email.  I like the idea of XMPP notifications, but I'd rather have them someplace where retrieving them isn't subject to my physical location.  (If I'm online at work and not at home, and I leave work without taking my IM client at work offline, I won't get notifications until I go back to work.  Also, yes, it's called XMPP -- Jabber is the legacy name and its use is discouraged. )

d) None.

I am running a home-grown PHP mining proxy that will let me centrally manage my miners and which pool(s) they will mine, with failover.  It does its own monitoring, and I would rather not receive notifications from two places.

Really sorry to hear that man.  I can't in good conscience keep everything I've earned from your pool, so I'm sending half of it back.  (Which isn't much to start with since I mainly ran CPU miners in your pool, but hopefully it will amount for something.)

Hopefully others will do the same.  Best of luck to you.

Nevertheless, capturing the traffic might be enlightening.  You could even compare the traffic with what poclbm generates.  This could be useful information for a bug report.

Hmm, maybe you should try capturing the traffic with Wireshark and see if there's something going on that's not immediately obvious.

"Timed out" likely means that a firewall is dropping the SYN packet.  Are you at work?  Is outbound TCP port 8334 open?

I find it very amusing that you call me a troll and then essentially agree with my post.

Let's consider the possibilities:

1. slush hates you, and is cheating you.  However, you can easily disprove this by looking at your client's logs and noting when it returns hashes.

2. Your deity hates you, and is causing you to be unlucky.  Blood sacrifices should fix that.

3. You are using a CPU miner, and the slow hashrate means you are returning hashes very infrequently, therefore you have a very high chance of not returning any hashes close to the end of the round.  Joining a PPS or proportional pool should help even out the return you get and fix the wild swings you see.

Let Occam's razor decide...

I can also check in my Bitcoin client.  I'm not sure what your point is.

I hope this is sarcasm.

[citation needed]

I developed the script on Firefox and not Chrome.  I don't currently have Chrome (I used it for about an hour a long time ago and wasn't terribly impressed).  If it claims to support Greasemonkey and doesn't run this script, I would say there is a bug in its Greasemonkey implementation.  I might get around to patching it to support Chrome's broken implementation, but I don't really feel like installing another browser right now.  (Maybe I'll fire up a VM tomorrow and hack on it there...)

In slush's pool it's 2%.  (1 BTC for every 50 generated.)

It should show up above each graph on the graphs page:



If it doesn't, verify that the script is installed and enabled.  If everything is set up right then it might be a bug in the script.  (But it's working for me...)

I wonder if it would be a good idea for pool payout transactions to receive high priority within that pool.  For example, if you just issued 50 payouts, those 50 transactions should always be part of the next block your own pool generates.  Inter-pool this doesn't make sense, but intra-pool -- you know they're not spam, don't treat them as though they might be. 

I hacked together a quick Greasemonkey script to extract graph data as CSV: http://userscripts.org/scripts/show/99852

Click the export button, copy content, paste into a .csv file, and open it.  It's not as automatic as downloading a file, but it's better than converting a JS array to CSV by hand.

A simple idea might be to write a proxy that, if the remote server returns failure or an invalid getwork response, generates some random crap and throws it at the miner so it will keep churning.

Hey all.

I've started working on a C# mining library.  I've seen the idea tossed around a few times, and as a newer Bitcoin user with a strong background in programming (it's my job after all) I figured I'd dive in.

Three git commits later and I have a working, purely managed implementation optimized a tiny bit by using unsafe code.  It's getting ~200khash/sec on a mostly-idle 2.66Ghz core.  So not great, but not terrible for a JITed language either.  It's mostly an exercise for me, but hopefully the community will have some use for it...

The miner and data source are hidden behind interfaces; I'm trying to make it easy for someone to come along with an OpenTK-based GPU miner, for example, and allow it to be used with my miner with no modifications to the core library.  Or even write a mining routine in C and p/invoke it.  Likewise, it'll be easy for someone to come along and write a data source that doesn't use JSON-RPC if they wanted to, for whatever reason, and have it work with any of the miner libraries installed on the system.  Since the large majority of the expense in terms of computing power isn't getting into the mining routine, but actually running the mining routine, a native or GPU-based miner should see close to zero overhead, even running in a managed environment (.NET or Mono).

Further, since it's a library and managed, it can be easily consumed by other software and should run ~everywhere.  (The managed miner only supports little-endian architectures at this point, but that doesn't mean addin miners won't work on big-endian.)

The source isn't yet released.  I'm hoping to release the git repo in the next week or so, under the MIT license.

Thoughts on this idea are welcome.  Note that, as someone interested in this kind of thing, I'll probably keep writing it even if you all think it's a horribly stupid idea. 

Is this related to the fact that I got a payout early this morning, but no email about it, nor any mention in the payout history on the website?  I'm pretty sure that this payout was correctly processed at least when it comes to all the critical financial data -- my confirmed balance appears to have been adjusted correctly, for example.