namecoind keeps locking up. Sorry for delayed bitcoin payouts again.

Monit is running and detects a crash but not namecoind locking up. Working on it..

Bitcoin prizes have been paid out and winners contacted about the BTC trinkets.

If you didn't win you can still buy BTC trinkets. More info here: https://bitcointalk.org/index.php?topic=120686

The race is over!

Congratulations to the winners: Digigami, narousberg and MashRinx. Bitcoin prizes will be deposited in your BitMinter account in a moment. You will be contacted by email about the BTC trinkets.

Thanks to Isokivi and BTC trinkets for sponsoring the race !

MashRinx (5.2 GH/s) gets a good block, landing him right after narousberg in the current standings.

Then from out of nowhere comes a block from Digigami. One of the earliest miners in the pool, running with 2 GH/s. He catches the bigger miners by surprise and positions himself first.

nats989 (3 GH/s) then gets a very quick block, moving into 4th.

The smaller miners appear to be on fire.

MashRinx gets a very lucky block that earns him a solid looking second place.

With less than 4 hours to go, we are approaching the end of the race. Now's the time to get that backup mining rig out of the garage and get it mining. 

Zubilica sails into second position. Getting into the top three is looking more difficult by the minute. darkice and xxx got new blocks, but they were not better than their previous ones.

Fefox was having some issues at the beginning. For some reason something always goes wrong for him when there is a mint race. But he is up to his full hashrate and did get a block. It only gets him 16th place so far, though.

We see darkice and amazingdarko falling back to 100-110 GH/s. Meanwhile jddebug keeps going at 160+ GH/s, as he has been for some time now. His block so far has him in 10th place, but with that kind of hashrate this could quickly change. At the same time yet another hashpower lease is starting up, this time from the user HashPower.

The race now has 8 hours 25 minutes to go.

That's more like it, many new blocks coming. cdb000, deBaer, duckquack, Ferdinand, thph, jddebug, dynasty all get blocks, but none of them can touch the three leaders. Ferdinand is closest of the new ones with 6th place.

The top blocks are difficult to beat, but with 11.5 hours left of the race it can still happen.

I added the current BTC target to the standings so you can also see what value the hashes have to be below to create a bitcoin block.

narousberg and darkice make new blocks that are not better than the ones they have already. xxx and wickedxxl make blocks that end up 8th and 9th.

Looks like it could be an easy win for the minters currently in the lead unless the minting improves.

micheletegon squeezes into third place, pushing out WhitePhantom. But it only lasts 10 minutes before narousberg nonchalantly tosses a block into first place.


This new block from narousberg looks pretty solid. It may be able to hang on to first place till the race is over. But at the same time we see the pool hashrate rising, with the hashpower leases being almost constant. The competition obviously wants to give him a run for his money. Or trinkets, as the case may be.

(The first post has been updated with the current standings)

Good that you solved it. The important part is to have the OpenCL drivers installed.

The pool is unlucky with several long blocks. But darkice finds his own luck, slamming a block into first place, pushing amazingrando down to second, while WhitePhantom moves into third.

A 90% CDF block is finally finished by solari after more than 4 hours of mining. But WhitePhantom's luck holds for now, solari's block taking fourth place.

Judging by earlier mint races, WhitePhantom's position is very precarious. It is unlikely that this block will hold third place for long. We may even see all the blocks found so far get pushed out of the top three positions. In other words, this isn't over yet.

Despite several leases from hashpower.com the race takes a while to get going.

2 hours 37 minutes into the race amazingrando finally breaks the bad luck hex and gets the first BTC block.

Did you reboot since you installed Catalyst? Could be worth a shot.

Are those Catalyst drivers directly from amd.com or some crippled drivers from a laptop manufacturer?

Unfortunately Dell and HP force their customers to use Dell/HP mutated versions of Catalyst. At least a year or two ago they also tried to "help" you by removing useless things you don't need, like OpenCL. Maybe this situation has improved now, but I've seen that in the past.

I try to stick to Asus products when I can, as they don't suck, in my experience.

And they're off!

darkice and amazingrando are elbowing for pole position with roughly 130 GH/s each. That's a pretty massive hashrate. But we have seen before how surprises can come from small miners. At the moment this is anyone's race.

6 hours 10 minutes till start. Time for a last equipment check. Make sure those overclocks are stable.

Ok, I didn't think of that. But really, what is the worst that can happen? Mining 5 txes instead of 500? You can see that after-the-fact and I don't think that's a disaster.

Or maybe I am missing something that "dirty" jobs could contain?

I apologize, I missed that in all the noise.

I support your idea. Not sure if "suggested merkle root" is a typo. I'd suggest that on the wire this is a merkle branch that when combined with your generated coinbase tx gives you the merkle root for the block. You request work once, then send several times block header + coinbase. The server will know which txes / merkle tree this belongs to by looking at your work ID.

I believe you are right that the majority will not care to see or change the transactions, so it is a good optimization for the common case. Also, until pools support changing the transactions, it will be a good optimization in every case.

It appears that you are missing part of the discussion.


Come on, that's no technicality. Is this really where this discussion is right now?

If you get a virus over HTTP then you blame HTTP?

If you mine a small block over Stratum then you blame Stratum?

Let's be honest now. Does the GBT protocol/API really force you to make small blocks? Does Stratum?



Come on, how many transactions you decide to include in a block is up to you, not the protocol. Of course you can say that something about GBT is bad, but can you point at the place in the spec where it tells you that you must not include more than X transactions in a block? Which part of GBT are you actually having a problem with?

Do you want it to be a violation of the spec to mine a block with less than X transactions? If so, present your suggestion and make an argument for it. But I doubt there are many that want GBT to have anything to do with which or how many transactions are chosen for a block. Luckily that is not the case now, even though you claim it is.


Well, again, this is a way to be polite and open for cooperation with other developers. Instead of saying "THIS is the best solution and you better do things MY WAY" you can say "maybe this can help improve things?" You will find this goes over much better with most people. The way you are acting you look like a very angry man who hates the world and everyone in it. There's no need to say that people suck at programming, nor joke about someone's (?) religion.

If you had both a problem and a solution in your head, why did you present only the problem?

ckolivas said "this is a technical discussion about the disadvantages of GBT". Unless the point is to destroy GBT I think a better way to view it is that this is a technical discussion about what GBT is today and how we can make it better tomorrow.

For the problem of using much of the bandwidth on transactions when some miners don't even care about seeing them:

I guess this could be improved by having the client include something in its capabilities list to tell the server it wishes to mine "blindly" without knowing about transactions. If both client and server has this capability then the server sends a merkle branch instead of a list of transactions.

I'm not sure its entirely clean that if the user wishes to see transactions the client would leave out this capability. It makes the capabilities more like options than an actual list of capabilities, but perhaps that's alright.

What do you think, Luke-Jr and others? It could get bandwidth usage down for users who don't care to see the transactions.

Being polite and working together towards a common goal is crap? I am surprised that you participate in an open source project.


You like to make a lot of demands, don't you?

ckolivas wrote that if the miner selects transactions you have to send in every transaction with every share. This is incorrect and has been discussed enough already, I think. You said that GBT, a protocol, makes decisions on which transactions to include. How does a protocol make a decision like that? And GBT being "an abortion", I don't think that's entirely correct either.


I never said I designed GBT. I said I suggested a few improvements for it. And what does religion have to do with this?

You told me to "fuck off" because I don't contribute. I was merely stating that my contributions are already in the spec. Where are yours?


You picked 15 random blocks from BitMinter. They were 5 big blocks, 5 medium and 5 small. And so you come to me and demand an explanation? I find that utterly unreasonable.

If you don't like pools that filter out transactions, then talk to them, not me. I don't put any limits on transactions.


No, you said that, not me. What I said was that I include all the transactions bitcoind gives me, without filtering out the free ones or putting any limit on the number of transactions, like some pools do.

GBT and bitcoind are not the same thing. If a bug in a web server makes it give you half a file, do you blame HTTP?


Maybe that would be a good improvement for GBT. If the miner doesn't care about seeing the transactions or filtering/adding transactions, request a merkle branch instead that you can use to create a merkle root for mining. Not a single transaction goes over the wire, other than the generation tx.


Of course HTTP is a constant connection. Use persistent connections, and pipeline requests for speed. My miner uses 1 long poll connection and 1-3 connections to get work and send in proofs of work. For the work connections it will pipeline up to 10 requests at a time. All the connections are persistent. They get closed only if they have been sitting idle in the connection pool for a while.

The advantage of Stratum is that it is designed to be two-way from the start. Long polling in HTTP feels dirty and hackish.

The advantage of HTTP is all the network infrastructure, proxies, libraries that exist, and all the knowledge that developers have about this protocol. When you already know the protocol, you have a library for using it that you already know well, then it is much easier to get started.

That's a good point. And you basically answer it yourself. An alternative could be mailing lists. Either way it's probably important to make that a developer-only resource to get a good signal to noise ratio.