Quote from: BombaUcigasa on April 26, 2014, 08:13:37 PM

Quote from: StuffOfInterest on April 17, 2014, 07:31:05 PM

Second, there is no incentive for people to operate a full node with blockchain history.
Third, specialized hardware (ASIC) is causing a runaway in difficulty and removing any possible RoI for small miners.
What if we tried a proof of blockchain (PoBC) model? In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.
...
Id like to see a hash generation done this way instead:
sha256(sha256(block_header)+history_block_hash))
...
1. Use the hash of the selected block (smallest amount with only 32 bytes per block needed).
2. Use the header of the selected block with the current block inner hash appended and then generate a hash on this (80 bytes per block needed).
3. (my favorite) Take the entire selected block with the current block inner hash appended and then generate a hash on this (requires the entire blockchain to be available).

So, why would we want to do this?

First, it should stop the ASIC miners in their tracks.

1. Store hashes of each block in the memory, no need to keep the blockchain. You can even have a full node and thin miners accessing it to bootstrap and update. There are 297838 blocks with 256 bits for each hash, requiring at least 4Mb of RAM... easily possible to store inside most ASIC miners.

2. Same as above.

3. This requires some extra latency and some variant of 1. You only need to request the block on demand, store it (less than 1Mb of RAM and hash it).

You should also consider this:

ASICs will always exist for EVERYTHING and ANYTHING. Building a computer with only the minimal components required for this job (no fancy CPU cache, no RAM slots, no fancy chipset, no audio or peripherals) will be possible at a lower cost than generic brand computers. There will be companies making these, and people buying them, and the same thing will happen as it does now, these computers will be single purpose (or hardly re-purposable and up-cyclable). It will be just more complex and less efficient.

As for efficiency, the same economic sunk cost into the security of the network will provide the same results no matter the method. But hashing slower than current methods, and involving extra steps will cause the clients to boostrap slower (they need extra database seeks to obtain and confirm blocks) and will cause more orphan blocks (as each node needs to seek the blockchain and confirm the block is correct).

Forcing more resources for a more wasteful and less eficient method of securing blockchains is just silly and won't have the results you want.

Options 1 and 2 I threw out there mostly to show why they wouldn't really work, for the exact reason you listed.

The bootstrapping and orphan block issues are very interesting. Bootstrapping will be slower. Not sure if there is a way around that. Orphans I think could be offset by having a higher number of nodes. If you only have a few hundred nodes then the difficulty will stay very low and orphans will be a common problem. I can see this with some altcoins even on Script, such as "SXC" and "WDC". But, what happens if you have 15,000 nodes (such as Bitcoin)? My hope is that the number of hashers out there will drive up the difficulty enough to keep the orphan count down. Of course, this depends on fast network propagation. I'm not sure if the Bitcoin software currently does network structure balancing to keep the path between all nodes the shortest possible but something like that may be needed to communicate out new blocks as quickly as possible to reduce the number of orphans being generated.