I would very much like to be wrong. It would be wonderful to not waste the resources of Proof-of-Work. It would be wonderful to not have hard failure (fork) at control of 51% of peers. I wish I was wrong, that is why I came over here to learn and analyze after making the conclusion below. But so far, I think the conclusion remains, until someone can show why it does not.
The seed could be the hash of all transaction in the previous CB.
The
last SH in that CB thus controls the hash.
I do not think you will be able to find a way that the
last SH in an period you choose, does not have control over the input entropy. That is the key distinction from Proof-of-Work, where the peers compete to the
first.
This is the point I made very early in my participation in this thread. The key difference is last versus first in terms of where the input entropy comes from. In Proof-of-Work, the input entropy is determining who is first, thus it can't be gamed. In these non-Proof-of-Work systems, the last peer determines the input entropy, and thus I am positing it can always be gamed. I am nearly sure this is correct.
It appears to be fundamental.
I like to reduce complex things to key fundamentals, so that I can understand clearly the differences that matter most when making a critical decision about my efforts.
You can't control the value of a hash, that's a major point of hashes: you can't find the content of a transaction which, when concatenated with the other transactions, will result in the given hash value. So you can't control the seed even if you control a part of the transactions.
Incorrect. If my SH controls the transactions in the last TBs for that hash, I can caused the hash to have any value I want (at some cost).
Furthermore, you have very limited control of IDs of your SHs. They're assigned by the order of their appearance.
But if I control the hash, then I have control over which IDs I want to target.
And they're decided before the seed for the next CB is decided.
Not that this is necessary. But still incorrect. If I control the last SH, then I can create SH deposit transactions (create new SHs) before I sign my TB which controls what the hash will be.
Since there is no control of the random generator, you'll have to resort to bruteforcing it.
It has deterministic values from every seed. All I have to do is compute from any seed of my choice, target my SH IDs to those values over any length of time that it takes for me to do so. Then just create that hash seed every time one of my SH is last. Thus disruption.
Additionally, once I do this, I might be able to continuously do it, because I can perhaps always place of my SH last from there forward.
In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof.
Then I only need to target those known patterns. I have as much time as I need to get my SH's IDs into that pattern.
Sorry but I think the issue of input entropy is FUNDAMENTAL in decentralized cryptography.
I saw this before I came to this thread. I had abandoned my Proof-of-hard disk, because I saw this fundamental problem.
P.S. Satoshi apparently wasn't working alone. I believe he had the resources of the NSA. I think they figured out that only Proof-of-Work was secure (up to 51%). The reasons I believe this are:
* very unlikely for one man to accomplish what he did
* he used military terminology and examples
* he said "we"
* his writing style was uniquely American english, not UK and the way a Japanese would write english
* he remained secret and covered all his tracks perfectly