In a surprising move we see PasProfeta, a miner who is not even on the top 50 by hash rate, delivering excellent minting work. The hash is much lower than the first prize hash from the previous mint race. Can he have already secured first place so early in the race? There is still plenty of time left, but finding another hash that low won't be easy.

Also gigavps, salcox, miscio84 have excellent hashes that are below the first prize hash from last race. It will be interesting to see if those will all stay among the 10 winner hashes.

We see manny following up with a namecoin block, but that will likely fall in the rankings fairly quickly.

(current standings updated in the original post above)

Ah.. knew there had to be a reason for it.

Well, hashrate still went over 1100 GH/s just before start. And we have now passed 20:00 UTC and the race is on!

May the best minter win

16 minutes to go. I don't think I can make it! 

With 2.5 hours left before the race we can already see miners jockeying for position.

In pole position we have amazingrando, a new miner on the pool. With 10% of the hashpower he should have a good chance to win.

After him we have the usual suspects, our regular miners in the 40-60 GH/s range. We can see Entropy now pushing up to 74 GH/s though, just in time for the race. But what is this, farfie is falling back, he appears to have lost about 20 GH/s. We can only hope this is not a repeat of the previous mint race where one of Fefox's rigs caught on fire. I must remind everyone that every machine has its limit. Don't push things too far or you'll end up spending all your mining income on repairs.

Quick update, we now see amazingrando responding to Entropy's move, pushing up to 112 GH/s and keeping a good lead.

Interestingly we are not seeing any GPUmax runs yet. At the last mint race several miners were plagued with mistimed GPUmax runs both before and after the race.

2.5 hours left before the race. Final equipment check, guys.

Yeah, you got it.

We have to wait and see if something will happen with the hash rate. During the first mint race some miners used GPUmax to boost their hash rate. But that's a bit unpredictable as you can't control exactly when it starts running. Some might also overclock their machines. But be careful, we don't want any burned out rigs like last time.

Just a few hours left now till it starts.

Nice


Not the lowest hash rate but the lowest hash value. The hash is used as an identifier for the block, so you can see it in all the links in the height column of the block list at http://bitminter.com/blocks

The hash is also used on blockchain.info, example: http://blockchain.info/block/000000000000057c1134e054dc94fbff521b54921b4ab9fcab6daa2033508d40
Both in the link and on the page (upper right, "hash")

Yep, full rollntime support is coming first, then >1 difficulty work. These are the two simplest changes a pool can make to support higher hashrates. The more complex stuff will come later.

Higher difficulty work won't increase the efficiency of your hardware. It will reduce the number of requests you make to the server which is good. But it will also give you higher variance for your proofs of work. Your proofs of work per time (and hashrate estimate on website) will vary more than before. This can make it look like your hardware is running very quickly or very slowly (depending on luck) when watching the hashrate shown on the website.

I don't think it's a good idea to use difficulty 10 for everyone. Best is probably to set a goal for how often a miner should find a proof of work, and adjust the difficulty accordingly. It would be possible to let the user choose, but I think automating it makes things easier for the user. Maybe auto-adjust difficulty for each worker account so that you find a proof of work every X seconds on average?

At first I was thinking every 10 seconds, but maybe once every 60 seconds would be ok? Not sure if that creates too much variance for non-24/7 miners. If you are having a (network?) problem and you are watching the miner you also don't want to wait forever before something happens. But 60 seconds might be ok. It would totally break hashrate estimates on the website though. I think I'm talking myself into something like 10 seconds.

Nice to see old minters thinking about returning. I believe some already did as the hashrate went up. Low hashrate seemed to be the main reason that people left.

QoS might help, but I think most routers don't give you enough options to differentiate between different types of traffic. HTTP file transfers and HTTP mining should not be handled the same.

What I do with Shorewall is limit my outgoing rate to a little below the limit I have with my ISP. This puts the bottleneck on my side, so that I control what goes first if things queue up. Then I give high pri to small ACK packets, SSH connections, etc. I give low pri to file transfers. And a middle pri to everything else. The high pri stuff gets guaranteed a part of the available bandwidth. I've been using it for many years now, makes a world of difference for me.

I do have to deal with it. Where do you think all that traffic is going.


Yep. When everything is implemented it may be possible to run a cluster of ASICs on a 14.4 kilobaud modem.

But also, if you are running a lot of other stuff on your connection, I would look into prioritizing traffic. For instance if you are running on Linux or sending your traffic through a Linux machine, have a look at this doc for the Shorewall firewall: http://shorewall.net/traffic_shaping.htm

Basically you want to avoid clogging up your outgoing pipe with high bandwidth traffic as that will give you really high latency. This can increase reject rate of proofs of work. It will also kill download speeds as it takes much longer to send ACKs to the computers you download from. You want to prioritize small ACK packets, interactive stuff like SSH, plus of course mining.

If you ever wondered why your downloads get painfully slow the moment you start to upload something, this is why. Same thing with playing games or typing on an SSH connection while uploading. Linux traffic shaping is what you need. I'm DrHaribo and I approve of this message.

It starts friday at 20:00 UTC.

That would not be a problem. A problem might be running a minirig on an old modem or non-3G cellphone connection.

The important thing is to reduce the rate of requests in time for ASICs. That's when this will really matter. It will get done on this pool.

That's good, should be useful stats.

As for mini rig owners needing to avoid this pool. We have several of them and they use both BitMinter client and cgminer. Mining away happily.

What I'm working on right now is putting abusive miners with extremely low efficiency (proof of work to getwork ratio) on a slow response queue so they don't slow down the entire pool. Once that is done, rollntime will be enabled for everyone.

This isn't some dumb move to hurt cgminer. I'm temporarily disabling a feature to ensure pool uptime. It only means a little more bandwidth usage for miners. It's affecting the server much more, but even that's not too bad.

You had a bug in cgminer (happens in all software). It brought down my pool. Lukejr found the bug. It was fixed. Some miners upgrade slowly so affected versions of cgminer are still in use. I'm taking measures to ensure that's not a problem. That's all.

I never came to your forum thread to spread FUD about it like you are doing here now. I never told people not to use cgminer, like you are now hinting that miners should avoid this pool. I only asked miners to upgrade to the latest version where the bug is fixed. Sure it wasn't fun the pool crawling to a halt. But I'd rather focus on the positive side of it, now the server software will become better than it was before.

I guess they reconnect as the same USB device and are not seen as "new" devices. May not be the best behavior. You could try in settings choosing on startup to start automated devices, and under automated devices put a tickmark on all the FPGAs.

Also a dirty hack would be to set up a scheduled action to start automated devices every 5 minutes. It's not meant to be necessary though.

I should look at always doing the "new device" thing even if the device has been seen before.


That's not going to kill you, but yes, it uses some more bandwidth. I am working on this right now.


Sure, Java 6 runs BitMinter client just fine. Also you could disable java (not javascript) in the browser and instead start the miner from the commandline with Looks like Oracle learned from Microsoft. Wait a long time for the regularly scheduled update even while security holes are being exploited.

Yeah, you just mine as usual. Just like a low hash can let you create a block, now it can also get you a prize.

I am working on a new server version with rollntime for all miners. Not finished yet though.

It's mostly for the server this is important though. I don't think the bandwidth reduction is that great for one miner?

A new mint race starts friday: https://bitcointalk.org/index.php?topic=104189.0
We have prizes from Bitcurex - check it out!


Hope you get it ready in time.

A new mint race starts friday: https://bitcointalk.org/index.php?topic=104189.0
We have prizes from Bitcurex - check it out!


That is bad timing. Try and get it going a bit earlier if you can.

Mint race #2 is over. Congratulations to the winners!

Bitcurex is kindly offering their BCC cards as prizes for a second Mint Race on BitMinter. It will be similar to the first mint race. The finest quality minting work (lowest hash value) will win.

Start: friday 31.08.2012 at 20:00 UTC
Finish: sunday 02.09.2012 at 20:00 UTC

Prizes:
1st place: Bitcurex BCC card + 5 BTC
2nd place: Bitcurex BCC card + 3 BTC
3rd place: Bitcurex BCC card + 2 BTC
4th through 10th place: Bitcurex BCC card

Total value is about 38.7 BTC (price, as of this writing, is 2.87 BTC per BCC card)

If you win a Bitcurex card you can choose the currency (USD, EUR or GBP). If you don't win you can of course still buy a card from https://shop.bitcurex.com. You can sell bitcoins on Bitcurex and withdraw your money (USD, EUR or GBP) through the BCC card. Thanks to Bitcurex for sponsoring the Mint Race. You can read more about them at https://bitcurex.com and https://shop.bitcurex.com.

Win conditions:

• Just like your hash must beat the difficulty to produce a block, it must beat the other miners to win. The best (lowest) hashes during the race will win.
• As long as your work is accepted by the server it is valid for the race, even if it ends up "stale" or "orphaned" in the block list.
• Each person can only compete with one (their best) hash.

Verifiability:
Hopefully your mining software will show if you have created a block (BitMinter client does). Your block will show with your user name in the block list at http://bitminter.com/blocks. You can click the height number for the block (leftmost column) to see details. There is a link there to blockchain.info where you can see the hash value of the block both on the page and in the URL. The lowest hash value wins. Hash values are shown in hexadecimal. 0-9 is lower than A-F. A is lower than B. Pretty simple.

FINAL RESULTS:

Place	Name	Hash (lower is better)
1	Isokivi	000000000000007FE04B5867A04D88FAC07F314B2157FFDE65FE841CBE276E11
2	PasProfeta	00000000000000E2292F2798A1D277E42C08D67138B5F142937CA2DC96916011
3	salcox	000000000000012FE112E6FD081B6E4CF2713C2EB28BB9CD9E890CB42795B83A
4	darkice	00000000000001BD5F0F7AEBCA6640E4B7EDCEA81497438C46CCA38D2C619C8A
5	gigavps	000000000000024C8DE303E240DDDA8612DE3E0FB6D282783DDAFF309D50E866
6	Fefox	0000000000000277C7D84C74A82E624662305DCACA1F62332167303842123639
7	WhitePhantom	000000000000028FE9E42B3D05A1ADDBAAEB592DA8C2F03107333A0B3789DB31
8	slipbye	000000000000035132ED7900B22D1CF41308CCBD066FEF3BDD3CFBDB9B1AF797
9	gazza	000000000000042047C86D261109FC3CADBC1D0095AAC2BC1744FDF9D768BDE6
10	kujayhawk	000000000000051955C2915741ADEB4D86B506068FA10D6A5191D6C61D708FEC
---	---	--- no prizes below this point ---
11	miscio84	00000000000005785B7210D23435261F9981B367673D81964085D84357D9C8F4
12	filip	00000000000005ABA288C959766E107D49B28E2E9932855145E885C98DEAC62D
13	lenny	00000000000005AC7A6CFEE6487540B92BFCC4947CF922AF74B7CA5D20716B7F
14	zopyx	00000000000005B71D5366F00ABC42FBF555D1BE267A61ECF99951403BA53D10
15	Phraust	000000000000061CE6206AFEDC04D0A502B5E78F46A0A0AD50A01CB124F52C8C
16	benny32	000000000000064259533442DB63F5ACA7DFE370C89CF3091AD1C9CE0D5E25D8

Quick website fix. Some miners noticed the livestats was showing shift at 100% complete when it was 50% complete. This is of course due to the recent change in shift size. Now fixed - refresh the page and it should be correct.


Thank you, sir, and welcome to BitMinter