Quote from: eldentyrell on October 16, 2012, 05:44:44 PM

Quote from: wizkid057 on October 09, 2012, 07:52:14 PM

The server performs the needed hashes to determine which bits of the nonce are the correct bits to be sent back to the user and keeps the sneaky bits.
...
its still quick enough for a share or so per minute of normal mining, OR it could be used for a speed boost for your own setup finding a valid nonce through other means by eliminating work exponentially, then the next encrypted work abort that sneak, etc etc.

No.

This is the double compression fallacy. The only way this works is by my servers doing part of the hashing work, in which case what the heck is the point?

First, this isn't a compression fallacy. You have the bulk of the data already (the work) and you're matching up a hash based varying a small portion of that data. This is no different, really, than some forms of advanced memory correction. Please examine what I write before passing summary judgement on it in an effort to devalue my post. I have significant experience with hardware development, embedded systems cryptography, and other related fields. I wouldn't bother posting something that didn't make sense or could be so easily discredited.

Now, for example, using my method in my previous post, to get a nonce decrypted server side, you would hash the work with the decrypted nonce in place to determine if it is:

a) a valid share that achieves difficulty 1 or better, if so send that back to the client (no sneaky data gained) or
b) if it isn't a valid share, that means that there is probably sneaky data bits starting at the MSB, so strip bits starting with the most significant bit and hash (up to a max of 32 times) to find the nonce that the client actually wanted which meets the share target, which will also tell you how many bits of data were sneaked out.

So, in case "b" lets say you strip off 4 bits before you find the nonce that meets the client's target for their work. Well, you now have 4 bits of data from the chip that you didn't have before ((decryptednonce & 0xF0000000)>>28), and the client has their valid nonce (decryptednonce & 0x0FFFFFFF). Repeat this for additional encrypted nonces from the same chip and eventually you'll get the data you desire back from the chip. The data could really be any length, as long as time isn't an issue.

Now, assuming the data desired is a bitcoin mining nonce for a work of your own, you'll have a time frame in which that needs to be returned, generally about two minutes. Now, its entirely possible that you'll get the full 32-bit nonce back in that time frame. However, it's possible that you may not get it quickly enough to be useful. So, here's what you do. Lets say its 75 seconds to the deadline and you have only 8-bits of the nonce. Well, now you've dropped the nonce search range from 32-bits to 24-bits. 2^24 is only ~16M remaining possibilities. Well, a single CPU can scan that in less than the remaining 45 seconds left on the work. And you've basically taken a CPU miner by a factor of 256. So, a 1MH/sec CPU can mine that share at the equivalent of 256MH/sec thanks to the chunk of data gleamed from the remote chip. Do this with enough 3rd party boards feeding data, and you've got yourself a decent pay stream.

And my example above is only based on sneaking 8 bits of the 32-bits out of the chip before getting the share with a CPU... lets say you get 10-bits out. (Its actually quite possible to get far past the half way points on average.) At 10-bits your 1MH/sec could mine that share at the equivalent of 1GH/sec. 1024x normal speed. On a CPU. Again, with enough end users you could potentially get some pretty decent returns, on avg.

If any more clarification is needed on this, I'll provide a step by step example, but I'd hope that I got the concept across this time.
But suffice it to say, this is definitely possible. And since we have no way to verify that this is not what's going on, then it is possible that this is what is going on in the TML bitstreams.

Sure, there are plenty of other closed-source firmwares in commercial hardware. However, it must be noted that there is so much more potential for sneakiness here in particular because of the potential for direct profit. To cite your particular example of a hard drive's firmware, this wouldn't really work because the hard drive's firmware doesn't have an internet connection. Perhaps if the designer hid a Wifi chip on the board, then maybe, but that would be a blatant and obvious violation there. There is also a difference in hardware/firmware from a trusted commercial entity and the TML bitstream. If Western Digital hides something detrimental in my hard drive's firmware, they can be held accountable for that. This bitstream on the other hand...

So, while I personally don't care if you open source the bitstream or not. It's obvious you're not, so, I'm not concerned. Especially with alternatives right around the corner.
I'm just making sure that everyone who uses this bitstream does so with the understanding that they may be utilizing and wearing their hardware more than they're bargaining for, and only because of the signcryption/closed source/etc. And we all have to admit, there is a lot of shadiness that goes on in the Bitcoin community.

-wk