The hash that comes out of a strong hashing algorithm has a random distribution. Although it is less likely, it doesn't take any more work to find a 000000000000000001.. hash than it does a 0000ffff.. hash, only luck.

The blockchain requires each block to meet the proof of work. To replace ten past blocks, you would have to generate ten blocks of your own. This is a much higher bar than a single lucky hash being able to replace ten blocks.

With a more-difficult-hash chain instantly winning like proposed, it would be an orphan free-for-all, you could get one lucky hash attempting to build on blocks from a week ago and replace tons of transactions. As described, a miner could attack for free by

1. constantly be transferring a large balance between new addresses in every block they mine,
2. find a "lucky" hash much smaller than the average and withhold it, and
3. make all sorts of purchases that will be wiped when they publish the chain-erasing block find that sends the money back to the miner.

OP already annoyed everyone with his great ideas based on a poor understanding of mining here: https://bitcointalk.org/index.php?topic=823544.msg9204175#msg9204175

There's nothing magical about the number 6, as I'm sure you're aware. 7-confirmation reorgs or attacks could happen, they're just less likely than 6 (and more likely than 8 ).

I don't think your idea is bad per-se, I just don't think that the advantages it confers outweigh the new vulnerabilities it introduces, but that's just my opinion.

[EDIT]
Thanks to btchris for feedback

As a measure of performance of a curve/blockchain in order to avoid the above attack we could sum the sign changes between two curves +1,0,-1 comparing curve values point wise and assuming max value were a curve lucks a point.

the scores of the curves would then became

(A)-(C)=+1+1-1
(B)-(A)=+1+1-1
(B)-(C)=+1+1-1-1

 

You're proposing that the total work be based on the value of the individual hashes, instead of the hash targets, is that correct?

This could incentivize a miner who happens to find a hash with an unusually low value to refrain from immediately broadcasting it. See, for example, this attack proposed a few years ago by casascius, which becomes viable with this proposed change.

	Block Hash (as big integer value)
		|(y)
		|
		|   
		|       -------------------------------+
		|       --- *           #---#---# (C)  |
		|            \         /               |
		|             \       /	               +---------------------(Difficulty bound)
		|              \     /    
		|               *---*---*---* (A)
		|                \
		|                 \
		|                  \
		|                   +---+ (B)
		|
		+---+---+---+---+---+---+---+---+---+---+---+---+----+---+-(x)
					   n-1  n  n+1 n+2 n+3
										n - Height

You're proposing that the total work be based on the value of the individual hashes, instead of the hash targets, is that correct?

This could incentivize a miner who happens to find a hash with an unusually low value to refrain from immediately broadcasting it. See, for example, this attack proposed a few years ago by casascius, which becomes viable with this proposed change.

Yes, but the hash target doesn't necessarily move from 135 bits to 136 bits, it moves from 135.1 to 135.4.


The total difficulty of a chain (for the purposes of determining which chain is longest) is the sum of the difficulty targets, and has nothing to do with the "luck" of the miners / block hashes.

The concept of "a better pow algorithm" is relative. Some may argue that "memory hard" pow algorithms are better for crypto currencies.

The problem is that you don't understand the very fundamental concept on top of which pow algorithms are based.
And that concept can't get any better because it is AS SIMPLE (and elegant) AS IT GETS.

Please don't paraphrase what I said... what I said was "we already have a way to slow down hash generation: increase the difficulty. Keep in mind that difficulty is not a bit count [emphasis added], it's more finely granular than that."

In other words, I completely agree with deepceleron.

This.

Also an advice to anyone who thinks he can come up with a better or fundamentally different or even slightly different pow algorithm...
Learn the very basics!

This is a wealth of nonsense that shows a complete lack of understanding of how mining, target, difficulty, or even binary math work, which then conjures up a nonexistent issue.

A SHA256 hash is 256 bits long. 256 bits can represent a number between

0
-and-
115792089237316195423570985008687907853269984665640564039457584007913129639935.

A hash of arbitrary data will return a hash with a value within this interval, seemingly at random, with equal distribution.

Difficulty specifies that a lower number threshold is required to "win", that a found hash value must be significantly smaller than the maximum. If we make the threshold 100 times smaller, only one in 100 hashes will win. The starting point with Bitcoin at difficulty 1 requres a hash value 4295032833.000015 smaller than the maximum, meaning only 1 in ~4.3 billion hashes will meet the difficulty 1 challenge.

The actual difference between steps can be easily calculated. Bitcoin encodes the difficulty target with nearly six significant figures in hex. I won't try to explain how it is actually encoded.

Here we show the next possible difference increment after difficulty 1 is difficulty 1.000015259254738:
>>> (0xffff * 2.0**208) / (0xfffe * 2.0**208)
1.000015259254738


The current difficulty target is:
0x00000000000000001F6973000000000000000000000000000000000000000000
which is difficulty 35002482026.13323

The next possible difficulty target increment is
0x00000000000000001F6972000000000000000000000000000000000000000000
which is difficulty 35002499029.10224

The ratio between these two is 1.0000004857646665, which is enough accuracy that even a one-second difference in the two-week mining period measurement will result in a different difficulty.

I think many would disagree with the premise of the statement that using a central server is an improvement, whether it be for time or anything else.  Likewise, most enjoy discussing well thought-out proposals that could be used.

Centralization opens up more attack vectors and is the antithesis of the protocol design, so I think you'll see a lot of resistance to anything that centralizes things and many people wouldn't switch to a fork that includes centralization by design.

:-)

The problem here lies with "at given time intervals". How do you ensure that all miners have synchronized clocks? And how will you deal with network delays, when a miner submits his block but it takes considerable time to cross the network. How long do other nodes wait to collect hashes from miners before they determine a winner? And how do you enforce that all nodes make their decision at the same time?

The current system works because it doesn't depend on all players having their clocks properly synced and there are clear rules that establish what happens when, for example due to poor network connectivity or whatever other reason, there are multiple competing branches of the blockchain.