Although my general policy is not to discuss the signcryption technique, I'll bend the rules this one time...
By the way, I don't believe that EldenTyrell modifies the INPUT of the double-SHA.
I do.
Changing even one input bit will change all output bits in a non-trivial, seemingly stochastic, way.
After all, this is the very idea of SHA-256.
You are correct: if you can predict the change in output bits caused by a change in input bits (or vice versa), the function you're using isn't a good hash function.
The full 64 rounds of SHA-256 are a good hash function.
The
first eight rounds of SHA-256 alone
are not a good hash function.
In fact, there are
pretty serious attacks that work against even 46 rounds of single-SHA-256; I suspect that this line of research might be why Satoshi chose double-SHA. SHA-2 really isn't a hash function until you've done a lot of rounds.
One cannot modify the 512 input bits of the SHA-256 algorithm, because otherwise nonce-detection would be impossible. A golden nonce would still be computed, but it would be a meaningless golden nonce.
I realize, however, that one can add some pseudorandom bits, which may or may not be a crypto hash of some or all of the 512 legitimate input bits, to the input bits, and thus "extend" SHA-256 with respect to its WIDTH.
In an unmodified SHA-256, what percolates down the 64 stages are 512 bits of w and 256 bits of ABCDEFGH.
By adding a few bits (how many bits has not been disclosed, but this will be trivial to find out) to these 768 bits, one can "extend" SHA-256 without messing it up. In other words, a kind of mini-SHA can be run along the full-fledged SHA, keeping the full-fledged SHA intact.
Similarly, for the second SHA iteration.
Then, at the end of the 2nd iteration, the pseudorandom result of the mini-SHA can be used to encrypt the golden nonce, making it unsuitable for direct submission to a pool, requiring submission to the ET-owned server farm instead.
At the ET-owned server farm, the quite-trivially-but-still-sufficiently-encrypted nonce is quickly decrypted, and 95% of these nonces are then returned to the miner, while 5% are retained by ET.
So, in other words, while I don't believe ET is adding any STAGES to the double-SHA, not even one, as that would directly impact the hash rate, I now think he's running a "mini-SHA" alongside both stages of the double-SHA. Maybe 16 bits wide. Maybe 32 bits wide. Maybe only 8 bits wide, partly relying on security-through-obscurity.
While undoubtedly ingenious, such an approach would needlessly increase the power consumption of the FPGA, which is already hitting various limits, mostly thermal ones, but in the ZTEX case also an Amp limit.
With BFL's June 15th announcement looming, however, I believe that all these speculations are mostly academic and of little practical importance. FPGA miners, including the Spartan6-based miners, will soon be obsoleted by ASIC miners, just like CPU miners were obsoleted by GPU miners.
