You seem to be implying that I am attempting to interfere with "allow[ing] us to run our pool the way we choose to."  That implication is false, just like the assertion that changing the ask rate from 5 to 20 or more seconds "would find more shares" (direct FairUser quote).

You are and have always been free to run your server however you choose.  I don't have the power to interfere with that, nor do I want to.

On the other hand, I and others are free to hang out in this forum thread and point out things like the above quote.

In any case, long pooling in slush's and Tycho's pool looks interesting.  If it takes off, maybe that will eliminate the need for policies like this, in your pool.

Yep, OSX is known broken at this time.  Waiting for someone to fix it, in a way that doesn't break everyone else's build...

Instead of bolding an unsupported claim, how about presenting this real-world proof that sha256 has been broken, and certain hashes are acquired more rapidly than others?


Did I ask you to change anything?  No.  Simply stating the facts.

This is simply not true.

Your chances of finding a suitable H==0 hash are the same, regardless of whether your ask rate is 1 work unit per nonce (a few nanoseconds), or 1 work unit per 0xffffffff nonces (minutes, on a CPU).

Furthermore, the chances of working on stale work increase as you slow down the ask rate.  A 60-second period means a lot of CPU miners could waste 59 seconds worth of electricity and CPU cycles, only to discover their solution is stale and invalid.

Well, it benefits the network, which benefits the node.

But I agree:  it should be off by default.

This server averages 80-100 connections normally.  I modded the outbound limit, it's not behind a NAT, and it advertises itself on IRC.

So it is designed to be popular.  But 360 block chain downloads per day?  I have no idea if that is realistic or not for this server.

Relaying blocks, relaying TX's, and a lot of initial-block-downloads, I suspect.  I don't have hard data besides "bitcoind was the only thing running on that VPS."

Mining consumes very little bandwidth.

Running a bitcoin P2P node consumes a noticeable amount of bandwidth -- my VPS ran out of its 1000GB allocation this month.

Patch updated, to remove lower bound on TX fee.

Directly storing the information in DNS is much faster, with newer network lookups and connections.

The official bitcoin client simply isn't designed for storing and serving lots of little bits of static data to the general public.

Blockexplorer agrees with your gettransaction output, too:
http://blockexplorer.com/tx/2a59d5910721dd5729d19737f300bf9b953fc55d32e6cd16dabb8bd5885280be

Sounds like a rounding issue somewhere...

EDIT: nevermind

If you are using a provider, then the provider can use TXT records.

I agree it should be change-able at runtime.  Long-running nodes will want to adapt to changing network conditions, without needing to restart bitcoind.

Here's a patch:  http://yyz.us/bitcoin/patch.bitcoin-settxfee

Any volunteers to test ?

Added to DNS seed list.  That's just the sort of DNS seed I was hoping for, thanks.

Just use TXT records and the current x-btc: URI specification.

It does not seem prudent to enshrine a "reboot it frequently!" policy as part of standard operating procedure.

The Scottish would say yes.

Is the pool remotely near capacity?  If not, then it makes zero difference.

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.