Bitcoin Forum
September 27, 2016, 01:54:36 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Faster Hashing - What's the Point?  (Read 2301 times)
InterArmaEnimSil
Member
**
Offline Offline

Activity: 77


View Profile
August 06, 2010, 05:18:58 PM
 #1

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?

12aro27eH2SbM1N1XT4kgfsx89VkDf2rYK
1474941276
Hero Member
*
Offline Offline

Posts: 1474941276

View Profile Personal Message (Offline)

Ignore
1474941276
Reply with quote  #2

1474941276
Report to moderator
1474941276
Hero Member
*
Offline Offline

Posts: 1474941276

View Profile Personal Message (Offline)

Ignore
1474941276
Reply with quote  #2

1474941276
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1474941276
Hero Member
*
Offline Offline

Posts: 1474941276

View Profile Personal Message (Offline)

Ignore
1474941276
Reply with quote  #2

1474941276
Report to moderator
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
August 06, 2010, 05:21:46 PM
 #2

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
Member
**
Offline Offline

Activity: 70


View Profile
August 06, 2010, 05:26:22 PM
 #3

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.

Bitcoins accepted to 18em7jEuKe1W74ChAZMFShUuqmwudWmpgu Smiley
nimnul
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW
August 06, 2010, 05:39:48 PM
 #4

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
Full Member
***
Offline Offline

Activity: 158


View Profile
August 11, 2010, 03:59:03 PM
 #5

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
Member
**
Offline Offline

Activity: 112


View Profile
August 11, 2010, 05:28:18 PM
 #6

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.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
nimnul
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW
August 12, 2010, 10:20:39 AM
 #7

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
Full Member
***
Offline Offline

Activity: 196



View Profile
August 12, 2010, 10:42:46 AM
 #8

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
Full Member
***
Offline Offline

Activity: 158


View Profile
August 12, 2010, 12:28:57 PM
 #9

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
Newbie
*
Offline Offline

Activity: 13


View Profile
August 12, 2010, 11:06:36 PM
 #10

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
Full Member
***
Offline Offline

Activity: 158


View Profile
August 13, 2010, 06:42:13 AM
 #11

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 Sad

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!