Topic: Seemingly Inefficient Hashing Question??? (Read 2452 times)

There is a use for storing previous hashes and that use is attacking the hash function using the birthday paradox. http://en.wikipedia.org/wiki/Birthday_problem

Nevertheless, the attack is not feasible today for SHA256.

By the way, just for reference the block in the main chain with the lowest difficulty is:


That block would've been valid even if the network difficulty was 35,900,000,000  (yes, billion), even though the actual difficulty was 244,000.   

That may seem ludicrous, but it's actually on par with the approximately 2^68 hashes that the network has done up until now.  The last part of it (the 67.07) says that if you were to do 2^67.07 hashes, you'd have a 50% chance of finding a hash just as good...

Random luck.  Many block hashes are significantly smaller than their target.  The requirement is that they simply be equal to or smaller than the current target. 

Hash values are going to be randomly distributed between

0000000000000000000000000000000000000000000000000000000000000000

and

ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Umm, that's quite interesting for me, how the hell you did get that hash?

I doubt it. Bitcoin doesn't hash anything secret.

Isn't this the likely reasoning behind using a hash of the hash?

All miners do this. SHA-256 works by hashing the first 64 bytes of data, mixing this hash into the next 64 bytes of data, hashing that, etc. The first 64 bytes of a block header doesn't change very often, so getwork returns a field called "midstate" which is the hash of the first 64 bytes, and then miners just need to compute the remaining hash from the midstate and data. Using the midstate speeds things up significantly.

SHA-256's way of hashing arbitrarily-sized data allows for trivial "extension attacks". Given only the hash of "password; command", an attacker can trivially produce the hash of "password; command; attacker'sArbitraryData" (ie. he can append any data he wants without knowing what he's appending to).

Thanks!

The input isn't just "x" it is made up of 6 components
Version
Previous hash
Merkle root
Timestamp
Difficulty
Nonce

When you solve a block at a minimum the previous hash changes hence no prior inputs will ever be valid again.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

An example might help.

Essentially the header input is just one giant 640 bit input.  For example:
Version: 01000000  (version 1)
Previous hash: 81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000 (from the prior block)
Merkle root: e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b (based on tx in the block)
Timestamp: c7f5d74d (unix time)
Difficulty: f2b9441a  (difficulty is a compact bit representation)
Nonce: 42a14695  (a 32bit number.  your miner starts at 00000000 and goes to ffffffff before starting on a new header)

So that becomes one giant 640 bit input.

Input:
0100000081cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000e320b6c 2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122bc7f5d74df2b9441a42a146 95

Your miner double hashes it.
potential block hash = SHA256(SHA256(input)

Potential Block Hash:
00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d  (bitcoin does some weird stuff w/ endianess but lets ignore that)

Now difficulty represents how hard it is to find a block.  It is more for us humans the network looks at the inverse of difficulty which is the "target".As difficulty goes up the target gets smaller.  To solve a block the block hash must be a 256 bit number which is smaller than the target.


This block hash is smaller than the target so it "solves" the block (if and only if all the inputs are still valid - which they aren't).  
Actually this block hash is really small.  It would be below the target even if difficulty was in the hundred million range.

Thank you. In case anyone else is interested, this description of the SHA-256 algorithm is actually quite readable.

This is what I've wondered too.   If you know a given, known input x results in output y -- despite the fact that changing one bit in the input provides a different output -- couldn't this be useful if you know input x resulted in output y which solved a block?

I don't know much about cryptography, but let's say at current difficulty 1,000,000, input x results in output y that would solve a block at difficulty 1,500,000.   Knowing this, why couldn't you simply input known x repeatedly to provide output y and solve blocks repeatedly until the difficulty adjusts?

There is no such thing as a partial hash of the first few bytes.  Take a look at the SHA-256 cipher diagram and you will see why.

Is there a way to store the result of the first few steps? Suppose we stored the partial hash of the first few bytes, then looked that up to save time at the start of each new hash?

(cue sound of ASIC makers hastily redesigning their circuits)

to use the hashes for something else is only possible if you have to hash the same thing again and since bitcoin block hashes are kinda specific I don't think you can use the hashes again.

And there's another problem. Let's assume i've 1GHash/s and im saving all my hashes. That would be around 32GB EACH SECOND. No harddisk supports such high rates and even PCIE supports only around 1-2GB/s i think. So it's impossible to store the hashes and hashes without inputs are useless which means that it would be far more than 32GB/s .

It is expensive to create bitcoins because bitcoins resemble commodity money. It happens with gold, silver, wheat, copper... The price of one bitcoin (or gold) is equal to its marginal cost of production. The alternative is fiat money which history has proven it is not trustworthy.

From Wikipedia:
Bitcoin resembles commodity money in the fact that, at least during the expansion of the Bitcoin base, its value, assuming competing suppliers (miners), is equal to its marginal cost of production. On the other hand, fiat money commands a value far higher than its costs of production, which raises the risk of severe mismanagement by their monopolistic suppliers.

If the US were to drop the dollar and adopt bitcoin, do you think FinCEN would disappear? While I know it is impossible, you need to try to compare apples to apples. What is the true cost of securing the currency?

Additionally, most of the treasury's budget is in salaries. While you could get meta and say that those human resources were wasted when they could be doing something more productive, it is hard to argue that electricity used to attempt to solve an unsolvable problem is anywhere near the same level of productivity. It is quite literally burning coal to secure the network. And you have to burn more coal than the bad guys.

I don't see it as waste. 

If you run a bank and you pay 5 bank guards $50K each for an entire year and nobody robs the bank did you "waste" $250K?
The cost paid by all to support the network is like the cost of hiring bank guards.  It prevents a robbery (51% attack).  If we spend enough and a 51% attack never occurs did we waste money?

One can say the network has a high cost but high cost doesn't necessarily imply waste.  Waste would imply there is a method to do it cheaper yet we continue to use the higher cost option.

I did not say it was useless, but the original question as I understood it was about waste, and you may agree there is a lot of waste heat produced. So one answer to the OP is that he can use it for whatever thermal energy is useful for, e.g., something as simple as heating a room.

Well the digital portion also has significant cost.  The Treasury dept budget is ~ $1.6B per year.  The fastest growing segment is FinCEN.

With fiat money though most of that cost is hidden.  The "users" pay for it in taxes and inflation.  Then for all its cost it is not very useful for anything outside of large acount to account transaction or face to face transaction so you have the rise of systems like VISA/MC which add another hidden cost. 

The smartest thing VISA ever did was shift the cost to the merchant.  If consumers paid the 3%* out of pocket directly they would have given up on CC a long time ago.  Granted they still pay it but it is hidden and there is no advantage to stop using the CC.

* well more like 10% when you consider costs above and beyond the discount rate including fraud and chargeback fees.

To be fair, these costs are related to only 3% of the money supply whereas the other 97% that is digitized is a hell of a lot cheaper.

You've raised an interesting question in my mind though: if we get down to the brass tax, how much money must be thrown at a certain value of transactions to be considered secure in the sense that it would cost more money to attack it? If we have millions+ in transactions per hour, what is the ratio to secure those transactions? What percentage of bitcoin GNP is wasted in unrecoverable, worthless resources? Would it be less than than the cost of paper money? Would it be less than the resources squandered on mining gold for reserves?