1. If you require that hash(X) < Target, then one needs to iterate over parts of X in order to find suitable result thus proving certain amount of "work" has been done to find that solution and secure the transactions, making this a PoW coin.
2. There have been numerous discussions in this and litecointalk.org forum whether or not hash function should be memory hard and consequently deterring developments of asics. Although I'm personally on the anti ASIC side of the fence I believe there is more than one argument to consider here which is why I like your idea.
3. Allow me for a brief digression here: I'm not buying the argument that high hash rate makes network any more secure as for example I could develop a super machine that hashes at 100x the speed of all other miners in the network and by the logic of the hash rate=security network would be 100x more secure once I deploy it, however if I really did this I doubt anyone would consider the network (with one miner only) more secure.
4. So only a distributed network with lot's of users and miners makes the coin secure, assuming no such disruptive technology with potential 100x (or 1'000'000x) speed-up can be easily developed. (Which is a stretch I know)
5. ASICs clearly work against this principle as no one I know can tomorrow buy an ASIC device for mining bitcoin or other coins that would actually make a ROI. Just for the sake of example everyone I know can buy a PC with a GPU in any number of local stores tomorrow and mine some X coin with reasonable expectation of making a ROI. If I (and others) could buy an ASIC in a local store and use it to get my investment back I would sit on the ASIC side of the fence. ASIC developers over price their products making ASICs not friendly to miners.
6. Please note that mining pools also work against point #4 as due to economies of scale large pools are by definition: better funded thus more reliable and secure, better developed, probably offer better customer experience and offer lower variation when mining, so they attract more miners creating a situation where top 5 pools by size control more or less most of the hash rate of a coin. So attacking say Litecoin would probably require taking out top 5 pools which is lot easier than developing "100x" machine from point #3.
7. So I think your idea would be perfect if it could solve both those problems. As someone on this thread correctly pointed our that adding a hash of some previous block to the header before hashing it would not do the trick as hashes of previous blocks could be precomputed I would go further to say that adding arbitrary memory requirement to the hash function would not work in the long term either as there is no real reason why ASIC developers could not bolt arbitrary amounts of memory (even DRAM or disk) to the ASIC as well still this makes development of such machines more difficult. I believe current term for such a coin is "ASIC resistant".
8. I propose (as you have) that the hash function only works efficiently when miner has access to the whole blockchain. For example sha256(block_chain_data(sha256(block_header))
9. I propose that hash function does not work efficiently in terms of forming pools (this may be impossible)
10. Thus miner variance should be made small by other mechanisms. Small block time does not work, but making the whole network act as a one giant p2p pool probably would. I was thinking something along the lines of allowing all miners to submit blocks with lower than network difficulty. Such blocks would not be considered as final as long as someone actually submits a block with lower than network difficulty. Then all miners would be paid proportionally to their contribution. This would open up problems with coinbase transaction which in an naive implementation could not be properly hashed, but this could be worked out by for example coinbase transaction would not be left to the arbitrary address generated by the miner but would rather be automatically generated to send coins to contributors of the previous round. Since all clients are aware of who these contributors are or rather what are their addresses everyone should be able to verify if coinbase transaction is correct at the time block is mined.
And yes this should be a new coin. Bitcoin will never accept change of this magnitude. Question is: can we put together a team to develop it? Personally I would join in. My suggestion would be that we spend a lot of time planning before we take on coding.
Name: BlockChainCoin or BCC
Any thoughts? Anyone?
Wow, I take a few days off and suddenly the thread wakes up again.
There was some discussion about prestoring the history block hash as a way of defeating keeping the entire blockchain on hand. That leaves me to think there was some misunderstanding of my original "option 3" or computing the hash. A better formula expression of that option would be:
sha256(sha256(block_header)+sha256(history_block+sha256(block_header)))
Or, here is another way to look at it:
var inner_hash = sha256(block_header);
var index = floor(chain_height * (inner_hash_last_32_bits / max_uint));
var history_hash = sha256(blockchain[index] + inner_hash);
var final_hash = sha256(inner_hash + history_hash);
You can't keep a prehashed copy of the blockchain as you would need to have the block along with the inner hash from the new block's header in order to calculate a new history hash.
As to the points above:
1: Yes, it is still proof of work, just that it requires a lot more information on hand to do the work.
2-5: My problem with most of the altcoin development is that it plays cat and mouse by swapping in different algorithms instead of stepping back to ask what can we do to improve the overall network.
7-8: Discussed above on how to put the hash together.
9: I think it would still be possible to mine in a pool but each miner in the pool would have to have the entire blockchain on hand. The way I would see this working is that the client (aka, Bitcoin-QT or bitciond) would have an API which could return a block based on the height of the block. This API could be done as a network connection, but that would be awfully slow. Better to do it via an interprocess communication mechanism. The miner software can make an outbound call via this IPC to get the block.
10: Block time is one of the areas giving me heartburn. I've seen arguments in favor of the Bitcoin 10-minute block time and I've seen arguments in favor of small block times. To me this comes down to a weighting of how fast a block can propagate out to sufficient nodes and how fast a transaction can be confirmed by enough points in the network for point-of-sale transactions. Needs much more discussion.
Now, as for development, I'm going to be backed up for a very long time, unfortunately. So far, the farthest I've got is compiling the Bitcoin-QT client on Windows. No small task in itself with all of the dependencies, but fortunately there are some good how-to guides out there. Looking through the code itself brought up another issue I'll have to contend with. I spent years working on C before going to some other languages for a number of years and then switching to C# a few years back. My day job is all C#. Reading the C++ code in the Bitcoin client is possible but not intuitive for me. Someone who works daily in C++ will be much quicker and finding the necessary bits and pieces.
I had originally said I prefer to do a clean code base rather than starting with the Bitcoin software. I'm starting to lean the other direction now. The Bitcoin node software has years of work behind it which makes it a great starting point for something new. I'd keep it a goal of segregating out changes well enough that as the Bitcoin software evolves this new fork can still utilize any improvements with mostly clean merges.
Finally, planning vs. coding, agree entirely. I've been floating a lot of ideas on this thread and I'm sure there are plenty of lessons learned from other efforts as well. A full plan of action should be worked out before any coding starts. Question would be where to have this discussion. This thread disappears into the noise within a couple of hours. Not sure if there is a better place on this site to have a deeper, organized discussion, if there is a better site for this sort of planning, or if we should setup a completely separate site.
