Seemingly Inefficient Hashing Question???

[JusticeForYou]

You know at a lumber yard, there is a lot of waste (byproducts). Lumber yards figured out how to use this waste to increase the efficiency.

Question:

In order to get a hash at the current difficulty some Input(x) is hashed can compared to the difficulty requirement, Output(y) = equal required difficulty? If so then Block(N), if not dev/null?

Point being, if you saved the Input(x) and the resulting Output(y) for all hashes, couldn't there be a way to use the waste?

I thinks there might be a way. Isn't that data useful in any way?

[jixapori]

How would random hashes be useful?

Unfortunately bitcoin mining basically wastes a lot of perfectly good energy

[etotheipi]

I thinks there might be a way. Isn't that data useful in any way?

No, not useful at all.  If you change one bit in the input, you get a completely different, unpredictable output.  By definition, if the hashing function is good (an assumption on which the Bitcoin network relies), there is absolutely nothing useful about saving a hash unless you need to compute that exact same hash (same input) later.  By definition, hashing value A, should give you absolutely no information about hashing A' which is even slightly different.

[JusticeForYou]

I thinks there might be a way. Isn't that data useful in any way?

No, not useful at all.  If you change one bit in the input, you get a completely different, unpredictable output.  By definition, if the hashing function is good (an assumption on which the Bitcoin network relies), there is absolutely nothing useful about saving a hash unless you need to compute that exact same hash (same input) later.  By definition, hashing value A, should give you absolutely no information about hashing A' which is even slightly different.

Referencing the Bold highlight.

[etotheipi]

I thinks there might be a way. Isn't that data useful in any way?

No, not useful at all.  If you change one bit in the input, you get a completely different, unpredictable output.  By definition, if the hashing function is good (an assumption on which the Bitcoin network relies), there is absolutely nothing useful about saving a hash unless you need to compute that exact same hash (same input) later.  By definition, hashing value A, should give you absolutely no information about hashing A' which is even slightly different.

Referencing the Bold highlight.

Unless you explicitly plan to hash something twice, you're not going to.  Every hash you perform on the Bitcoin network will be different.   If it's not, you're doing something terribly wrong.

[gmaxwell]

Unfortunately bitcoin mining basically wastes a lot of perfectly good energy

Because securing the worlds only completely decentralized currency, which is already inherently forgery proof, against reversal is a waste?

I can only imagine what you think about the costs of handling cash, armored cars, and flying treasury agents around to deal with counterfeiting. 

People have proposed alternatives to bitcoin that do additional useful work at the same time— but they're all insecure/vulnerable to cheating. The best we've got is merged mining.

[Etlase2]

I can only imagine what you think about the costs of handling cash, armored cars, and flying treasury agents around to deal with counterfeiting. 

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?

[DeathAndTaxes]

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.

[jixapori]

Unfortunately bitcoin mining basically wastes a lot of perfectly good energy

Because securing the worlds only completely decentralized currency, which is already inherently forgery proof, against reversal is a waste?

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.

[DeathAndTaxes]

Unfortunately bitcoin mining basically wastes a lot of perfectly good energy

Because securing the worlds only completely decentralized currency, which is already inherently forgery proof, against reversal is a waste?

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.

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.

[Etlase2]

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

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.

[Shawshank]

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.

[wabber]

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 .

[ribuck]

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)

[DeathAndTaxes]

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)

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.

[the joint]

I thinks there might be a way. Isn't that data useful in any way?

No, not useful at all.  If you change one bit in the input, you get a completely different, unpredictable output.  By definition, if the hashing function is good (an assumption on which the Bitcoin network relies), there is absolutely nothing useful about saving a hash unless you need to compute that exact same hash (same input) later.  By definition, hashing value A, should give you absolutely no information about hashing A' which is even slightly different.

Referencing the Bold highlight.

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?

[ribuck]

Is there a way to store the result of the first few steps?

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.

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

[DeathAndTaxes]

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?

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.

Code:

Current Target: 00000000000009AE020000000000000000000000000000000000000000000000
Block Hash:     00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d

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.

[the joint]

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?

The input isn't just "x" it is made up of 5 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

Thanks!

[theymos]

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?

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).