So, has any theorizing about attack vectors n the like or studies been done on this form of mining algo?
What are its downfalls etc....
Im thoroughly interested in this method of securing a crypto, this coin has peaked my interest greatly =) too bad I dont have TB's and TB's of storage lallygagging around lol!
So far there are no known attacks, however there are a few weaknesses, although some of them can be solved with an updated algorithm.
1. Not much at stake.
Many people consider the ability to mine multiple chains at the same time without a significant increase in resource consumption to be a major weakness in PoS algorithms, and this would apply partially to PoC as well. In PoC you could mine multiple chains at once, although do to disk bandwidth limits you would be able to mine significantly less chains than you would with PoS as you would be reading different parts for each chain, and therefore electricity consumption would also increase from doing so. This puts it in between PoW and PoS, although much closer to PoS in the 'nothing at stake' argument.
2. Block verification cost
The strategy of hashing the nonce and account many times in advance and saving the result may result in a constant low computational cost for checking the nonce later, but everyone else still needs to run the whole hashing cycle on that nonce to verify the block. This results in very high computational cost for verifying blocks, and blockchain syncing being cpu bound.
3. Inability to scale to higher processing power
Over the life of bitcoin, hashrate improvements have been much more significant than improvements in hdd capacity. The amount of work added in advance in PoC is constant, so if a similar arms race was to occur, significant enough processing power advances could cause PoW mining to become more efficient than mining PoC as intended. One user ran some calculation trying to estimate how the most efficient sha256 asics would compare in efficiency to hdd mining. Although the calculations were flawed, as they assumed 1 sha256 hash == 1 shabal256 hash regardless of the number of rounds done for the hash, if adjusted to assume 1 round of sha256 == 1 round of shabal256 they estimated those asics would have about 2x the efficiency of using hdds. Although having it within the same order of magnitude isn't too bad, and wouldn't provide enough of an incentive to actually design the hardware, it does show that it may already be possible to achieve better efficiency that way, and the gap could widen in the future.
4. Higher PoW resistance requires higher portion of data being read
Under the current PoC system, increasing the number of scoops(which would decrease the amount of data read each block) would also decrease the effective hashrate/TB, however the hashrate from trying to mine it PoW style would be unaffected. This is a bad trend as reading higher portions of the disk each block provides higher PoW resistance, which is also worse for HDD life.
5. High blocktime variance
Due to the high amount of diskspace used per nonce, the total amount of nonces checked per block is very low compared to PoW coins. This leads to higher variance in block times.
And this is why we need PoC2.
PoC2 has only been mentioned a few times publicly, but is a second hdd mining algorithm I plan to add in addition to the original POC. The original PoC will continue to remain as long as problems related to it don't start. PoC2 should solve points 2-4 above. A (very slow) miner for it was hacked together for it a few weeks ago, although it has not yet been implemented in the client.
PoC2 started on irc some time ago during a discussion about the block verification cost, mczarnek posed the question about whether plots could be generated similarly to how PoW mining works, so verification would be just comparing a hash to a target. The end result of this once thought out was that plot files could store nonces instead of hashes, and there would be constraints on the nonces that could be used, so you'd be storing allowed nonces. When mining, you would only be able to use nonces where hash(account concat nonce) < target, and hash(hash(account concat nonce)) mod totalscoops == currentscoop. Plotting would then be similar to PoW mining for that target, and then sorting the results into buckets based on the second hash. The appropriate bucket could then be read each block and network state, account id, and nonce could then just be hashed together looking for the lowest result.
2. Block verification cost
Verification would be cheap. 1 hash would be needed to compare to the target, another would be needed to calculate the scoop, and a third would be needed to check the deadline.
3. Processing power scaling
The target can be set to slowly decrease over time. Although this would change the current rule that you never have to re-plot, users would able to plot setting the target knowing how long the plot would be usable for. Both mining with the finished plots and verifying the blocks would remain constant cost regardless of the target. As plotting and PoW style mining would become harder over time it would help prevent gains in processing power from causing PoW to become more efficient.
4. Under PoC2, changing the amount of scoops also directly affects PoW mining hashrate the same way. This allows it to be scaled to higher or lower portions of the disk being read each block without decreasing PoW resistance. Initial testing showed that storing nonces as 4 byte differences between the previous one in each bucket should be doable, which if the scoop number was adjusted to have PoC and PoC2 have the same hashrate/space used would require only 16MB/TB/block to be read, instead of the current 256MB/TB/block. A scaling factor could also be applied to the base difficulty to lower that even further, however it would make variance even worse.
