Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 10. (Read 119421 times)

Then must be some reason for not releasing that has nothing to do with commission.

Actually, I'm pretty sure that the math on this one doesn't lie.  700 BTC > All Possible commission profit.

I am not good at discerning some humor in English, so I do not know if you are making joke about bragging.  My joking is my drop-out of law school.  Point is, don't take self so seriously.  If you are not joke, then apologies for confusing you.

The imperfect information is exactly and precisely demonstrated by primary statement.  Is commission Dr. Tyrell's means of making money from bitstream?  That is big assumption.  We know he is working on project, and he has said he devotes time to project at expense of miner.  If project uses bitstream IP and makes more than 700btc, then no point to open source at this time.

At least two sides to every issue.  I am trying to think of Dr. Tyrell's motivation for not release open source.  Seems most obvious case.

I claim mob because much anger directed by many people who have no claim to Dr. Tyrell.  Other word better, is fine.  It is appropriate to my eyes.

+1

Well, 700 BTC may not be adequate, but it's more than getting almost nothing from commissions. (Are commissions actually enabled currently?)

Do you know what's not adequate for sure? Calling us "mob". Looking at your signature it seems like you need to brag about things - just FYI, I'm currently making a master degree in physics.

Is interesting, with such imperfect information, that angry mob assumes 700btc (7700 dollars?) is adequate compensation for Dr. Tyrell's time and creation.  That is less than week of consulting income.  How many hours spent developing?  How much mining does Tyrell do with bitstream?

Dr. Tyrell may have to rely on Zhou to make eyes, but he has assembled his own hardware that uses bitstream.  He has healthy advantage that mob needs to understand before price of open-sourcing software is smart move on his part.

Want is different than deserve or earn.

From what I remember the reason chrisp stopped development was because the DCM was failing to lock which is an inherent hardware flaw and the current working enterpoint bitstreams either implement another clock source or a watchdog.

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

By the way, wizkid, if you're worried about your hardware's firmware spying on you, you'd better not read Ken Thompson's lecture about self-infecting compilers.  You won't be able to sleep at night

And your hard drive's firmware?

KVM is open source software.

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?

The bitstream for enterpoint boards was released months ago.

The only issue is the software drivers.  Ask Enterpoint for those.  The ModMiner manufacturer wrote a driver for their board; Enterpoint is dragging their feet.

I have a partially-completed but non-working driver written by ChrisP.  If they want that code as a starting point I'll send it to them.  ChrisP has not responded to my emails for more than two weeks now, so my offer to share commissions -- which was clearly and explicitly conditional on his code working -- does not apply yet, although I hasten to add that if he reappears and finishes the job I'll be happy to reinstate it.  If we wind up with some solution that is a hybrid of his code and somebody else's I'll figure out some commission-sharing arrangement based on how much work it took to finish the job.

And you've audited the KVM firmware?

That would be the more appropriate analogy.

ET plz release bitstream for cairnsmore1 boards, ty.

Elden,

I hope you are doing well, I just heard this amazing story about open source hardware on NPR, I really think you should listen to the NPR story and then watch the TED talk.

http://www.npr.org/2012/05/18/152872160/can-we-open-source-hardware


This guy has who happens to have a PHD in fusion physics engineered and designed open source hardware to build a self sustaining village with locally sourced and even recycled materials - he not only released the schematics but also has a wiki with full instructions - at any rate in the NPR story he gives some excellent points on why open source is so important.


Feel free to respond privately or publicly after you listen to it.


thanks!

Tom

Well, because the work itself is encrypted before the FPGA sees it, you can obviously shift in any data to the FPGA.  And you're pretty clever.  I personally can think of at least a couple of ways to sneak bits out through the encrypted nonces almost every time, at the expense of minor amounts of processing on the server side. We all know that the average nonce found is below the half-way point (mainly due to discarded work), and that should give a hint.

Hell, I'll give you one of my possible ways, just so you can't say it can't be done. Each time the FPGA finds a nonce, if there are two or more leading 0's, the first is set to 1 indicating sneaky work. The remaining are set to the bits to be sneaked out.  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.  At most a few dozen hashes.  Even at the rate a full nonce could be sneaked out this way, 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.

I estimate that this specific method could be used to get at most about 5-10MH per LX150 if done fully.  Far more if done partially (ie: reducing the nonce search window by a factor of 2^16 or so for your own hardware... which could make a normal CPU able to mine at profitable speeds with enough LX150s sneaking out partial nonces.) In addition to the commission work planned, this could be almost profitable.

There are better methods, and I didn't say a lot of data could be sneaked out, but, you can't say it can't be done.  And unless the source is available, you can't prove that it isn't being done.

-wk

Or, more likely, trust that the number of other third-party developers who have reviewed the code would have caught anything stupid. My main system is 100% open source, except for BIOS and firmware. Yay for Intel APUs. My Radeon GPUs can be locked down nicely inside KVM.

then you have to trust the open source programers not to code bullshit into it

Incorrect
All the software I use on my desktop except for the nVidia driver is open source.
No trust issue with anything I use - just a 'lazy' or 'not lazy' (to read the code) issue.