An update on the backend side... We are now the second pool to implement BIP 34 (block height in coinbase). Compatibility for BIP 22 (getblocktemplate, for decentralized mining) has also been brought up to the current draft, including support for BIP 23's "Basic Pool Extensions".

For the time being, Eligius will remain backward compatible with our old BIP 22 draft implementation (getmemorypool) as well.

Eloipool's gmp-proxy is not updated, and I do not plan to update it. Instead, I plan to enable Eloipool itself to run as a fully functional BIP 22/23 client and provide the same basic behaviour gmp-proxy did before, plus be able to use all its usual pool functions. This basically means you can run sub-pools under any other BIP 22/23-compliant pool (including nested sub-sub-pools).

Additionally, after I finish with the pool updates, I plan to implement a MIT-licensed library for BIP 22 and 23, which I will then use to enable BFGMiner to achieve a whole new level of efficiency, necessary and in time for the anticipated ASICs within the next month.

As for reward systems, we are still running on SMPPS. CPPSRB seems to have fairly good reception, so that seems like what we'll be migrating to in the coming week(s).

Just implement what you need in a way that doesn't encourage people to abuse the network. If someone wants to spend 50 BTC on your service, let them send 50 BTC instead of demanding they chop it up in 200 pieces. In some cases (this one sounds like one), it makes sense to keep a side-side balance so a single withdrawl transaction can be made when they are done.

The only reason I even found your service was because it was flooding #Bitcoin-Watch to the point of crowding out the normal traffic.

The only other one that has been as disruptive so far is SatoshiDice.

Yes, I've blacklisted other known attacks. (Edit: the blacklist is on the transaction relay/inclusion policy for the Eligius mining pool, #bitcoin-watch, and any other miners who have merged my patch, and not currently easily expanded to new addresses)

It's the only way that can be done overnight. Continuing to attack the network, and building up more attacks is certainly not the way to handle it.

In fact, I'm the only developer so far (AFAIK) who has even tried to take a stab at fixing the problem you are exploiting (though I found it to be too complicated to fix than I have time for at the moment). But that's not really all that important: what matters is that this disrupts the network for everyone and has could trivially be done in a way that doesn't.

Please stop attacking Bitcoin. I don't really want to have to implement an address blacklist.

Unfortunately, that feature missed the cut for 0.7.

The full details on each module (including internal counters for debugging) are exposed to the JSON RPC API.

It's usually sufficient to just get the git checkout linked under your eloipool directory.

That logic is improved on almost every other release. Currently, it is (over-)aggressively upclocked every 16 sequential good nonces, and downclocked when there seems to be something failing (too high % of bad nonces, or too long without any nonces).

Curious. Mine all sit at 200 constantly even though they would probably perform better at lower clocks...

Each module is handled individually, but because they share the same MCU, they are displayed together. In a future release, I hope to more clearly split them up into the existing "MMQ <board>.<module>" identifiers.

Wow, epic fail on your part. Imagine if it were Bitcoin and didn't have centralized control... "oh, you had us send to the wrong address? tough"

Be glad you'll probably see it back eventually at all.

In other words, you will continue to use the blockchain abusively knowing full well that it harms the network? That makes you no better than someone intentionally attacking to take Bitcoin down.

Bitcoin can scale, but it takes adoption, effort, and time. If transactions soar to 100x the rate reasonable given the current adoption (as it does with the poor design used with this and SatoshiDice), everyone suffers. A simple way you could make this more reasonable would be to allow people to send multiples of 0.25 BTC instead of spamming a ton of transactions. To help the long-term scaling, companies that need the higher volumes could financially support development of such improvements (the most obvious one today being the p2p protocol needs reworking to propagate blocks reasonably).

Might try (with 2.7.5):

This will scan every serial port it can. Beware if you have non-mining devices on your PC, though!

Unfortunately, ngzhang didn't want to donate a Lancelot so I can provide proper support (he did donate an Icarus - I guess he assumed Lancelot would just work in the same way), so there may not be much I can do if it doesn't work unless someone else wants to donate one.

Great, another outsourced DDoS on Bitcoin...

https://github.com/bitcoin/bitcoin/pull/415 was the original pullrequest; #1359 was just my keeping it rebased (ie, not maintaining it but just making it work with newer code)

No, Coin Control was found to be poorly designed (how can you control specific outputs held by the same address?) and its maintainer disappeared. Parts of it (grouping logic) were merged into the new raw transaction RPC methods. At this point, getting Coin Control in probably means someone needs to step up to adapt it and clean it up to provide the same functionality as the raw transaction stuff.

CPU mining is pointless on Bitcoin

Try running with bfgminer -D -T -d? and pastebin that.

And don't forget to mention what OS/devices/etc...

Please open an Issue with the full details (eg, how doesn't it work, what devices you mine with, etc)

Five of the ten commits between 2.7.4 and 2.7.5 are, as attributed, written by Con to fix bugs he had introduced, yes - so that's half if you're just counting commits. Line-wise, it's probably less than half. I can't even speculate on time spent. Unfortunately, I can't even speculate on "man-time spent" statistics.