Faster Hashing - What's the Point?

[InterArmaEnimSil]

I've seen two recent releases, .36 and .38, mention faster hashing.  Why is this advantageous?  Won't faster hashing simply cause the difficulty to increase, and place us precisely back where we were before the "speed" increase, only with a higher difficulty number?

[kiba]

I've seen two recent releases, .36 and .38, mention faster hashing.  Why is this advantageous?  Won't faster hashing simply cause the difficulty to increase, and place us precisely back where we were before the "speed" increase, only with a higher difficulty number?

It's because some people have faster hashing engine than others. It is felt that it is fair to equalize this by giving everyone a faster standard hashing engine.

[Olipro]

I've seen two recent releases, .36 and .38, mention faster hashing.  Why is this advantageous?  Won't faster hashing simply cause the difficulty to increase, and place us precisely back where we were before the "speed" increase, only with a higher difficulty number?

Even if the difficulty increases, you will ALWAYS have an advantage over everyone else who cannot compute hashes as fast as you.

[nimnul]

If everyone's hashing is slow, I can write a faster hashing engine and get an advantage. If everyone's hashing is already fast I cannot get an advantage and everyone is equal.

The equality is important to protect the network from "attacks" by people like neholod.

[throughput]

If everyone's hashing is slow, I can write a faster hashing engine and get an advantage. If everyone's hashing is already fast I cannot get an advantage and everyone is equal.

The equality is important to protect the network from "attacks" by people like neholod.

Why everybody is so fixed on speed of hashing by a general purpose CPUs?
Why do you think, that x86 CPU is the optimal architecture for hashing?
It was proven, that bruteforcing 3DES is much cheaper not on x86 clusters, but
on specially designed hardware bruteforcers. Everybody is capable of manufacturing
ready to use device, just place an order with a proper design instructions for some Chinese fabric.
You will get it by mail, it is cheaper to order thousands. Design will cost you more,
than manufacture and delivery.

SHA2 is not different in that aspect.

If you want to make everyone equal - design, manufacture and distribute such hardware accelerator.
Bruteforcing SHA2 with x86 CPU, even with SSE, is not cost-effective.
And it is not the best protection of distributed truth.

[Ground Loop]

The reason the network must be large, and fairly competitive in hash speed, is that your fictitious Chinese-shopping hardware accelerator builder should not, at any given time, be able to dwarf the combined honest power of the network.

If we just freeze some old bitcoin app version and say "500 khash/sec is good enough" and everyone stops developing, then over time this becomes easier and easier to defeat.

You seem to be asserting that someone could, today, build a dedicated hash machine that can outpace the entire network.  To make this cost-prohibitive, the aggregate khash of the network needs to keep pace with the "value" of the bitcoins that could be subject to attack by a faster network.


But the more direct answer to your question of "why everyone is so fixated on speed" is that I want *my* own selfish computers to have a larger search chunk of the total network.   If I contribute 1% of the generation power, I have a 1/100 chance of finding each block first.  That's a huge reach, but an incentive to keep trying new code versions and doing development on the hash code.   For anyone that expects bitcoin to "take off", there will never be a better time than the present to burn energy and search for blocks solutions.

[nimnul]

Well, people work in this direction - there's CUDA experimental build to utilize GPGPU. Regarding other hardware platforms - there are ready to use FPGA accelerators, for example http://www.nallatech.com/pci-express-cards.html, and NVidia Tesla GPGPUs. Even though these devices are cost-prohibitive for most users, I doubt custom-built card will beat these in terms of price/performance. We'll have to spend many iterations of design before getting decent performance, so design will be VERY costly.

[lfm]

Why everybody is so fixed on speed of hashing by a general purpose CPUs? Why do you think, that x86 CPU is the optimal architecture for hashing? It was proven, that bruteforcing 3DES is much cheaper not on x86 clusters, but on specially designed hardware bruteforcers. Everybody is capable of manufacturing ready to use device, just place an order with a proper design instructions for some Chinese fabric.
You will get it by mail, it is cheaper to order thousands. Design will cost you more, than manufacture and delivery.

The x86 is not of course optimal for much of anything. The reason it is so attractive is obvious tho. Its already out there in huge numbers and since it is in general underutilized we get the cycles VERY cheap.

Your custom chip will need a PC anyway to be useful for bitcoins to handle the rest of the process, the networking, storage and even the GUI/UI to set up and control the system. So you actually are not saving money, you're spending more. Its actually really hard to compete with money already spent and people have already spent the money to buy the PC so they can do email and facebook and warcraft and so on. You want them to spend more money on hardware only useful for bitcoins?

[throughput]

I think, people here confuse cryptographic accelerators with hardware bruteforcers.

And some overestimate the cost of design and manufacture of such devices.

Don't forget, for an average $1000 PC at least $500 is for branding and marketing.
Particular model design costs are not visible in that sum at all, more takes the investment on underlying technology (patents costs).
Fabric in China may take another $400 for it's Chinese brand and marketing and the rest is
 $100 for actually manufacturing the device (work, materials, process).
This may be too exacerbated, but it shows the real picture.

So a motivated amateur may design that for himself (for free) and order the manufacture from
the cheapest no-name fabric. Delivery will add costs, surely.
Designing a PC is a more complex task, since there are a lot of interoperability issues, numerous buses, interfaces, standards, etc.
Designing a SHA2 block in circuitry is a moderately complex student-level task.
Combining 1024 such blocks on a crystal is a no invention. Or even more...
No need for fantastic 600Ghz, 100Mhz clock speed will be enough. How many clocks will single SHA2 operation require? Surprise!
It could be as small as 10 - 2 clocks. 100Mclocks / 10 * 1024 = 10 240 000.0 Khps/crystal.
OK, 64 clocks maximum, or you are bad, bad student => 1 600 000.0 Khps/crystal.
How much will it cost, compared to a super-duper-computer everyone is mentioning here?
Or monstrous server farms?
How many such crystals (mounted and assembled into a box with a power supply) he will be able
to order for the price of a single HP 8 core server (5000-10000 Khps) ?
Do you getting the idea of cost-effectiveness now?
There are only ~7000 nodes now, some of them are server farms.
But there is a huge gap between 10 Mhps and 10 Ghps, don't you feel?
I estimate the overall Bitcoin network perfomance is measured in tens of Ghps now, but no more.
But it is possible to produce a crystal with Ghps perfomance and pack 100 of them into a PC-sized box.
Oops, it will be hundreds of Ghps...

But then there could appear a motivated professional, as soon as Bitcoin make popularity...
No way.

[Cheater]

Why are you talking about chip fabrication?

All you want are a couple of FPGAs. You can pick some up for $80/each from Sparkfun.

[throughput]

Why are you talking about chip fabrication?

All you want are a couple of FPGAs. You can pick some up for $80/each from Sparkfun.

As I said, I'm not an electronics expert

BTW, I thought, that chip fabrication allows for very optimal and effective circuitry. Especially cost-effective.
But yes, FPGAs may allow you to start right now, no chinese fabric risks involved.