Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[wizkid057]

Is interesting, with such imperfect information, that angry mob assumes 700btc (7700 dollars?) is adequate compensation for Dr. Tyrell's time and creation.  

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.

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.

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

[Borzoi]

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

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

[wizkid057]

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

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

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

[Borzoi]

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

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

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

Does not have to be illegal or shady.  Could be ASIC of his own.  If I can afford ASIC run, he can, especially if he has mined many bitcoins with improved bitstreams.  Could also have access to better FPGAs with more gates that better to suit algorithmic approach.

Think if BFL mined instead of selling.

[MrTeal]

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

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

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.


Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.

[wizkid057]

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

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

This is exactly what I've been saying.  The only reasons, that make any sense, to turn down such an obvious route to profit would be if there were either a) more profit to be made from shady code running on the device, or b) the code running on the device is in some way illegal to use or release in the first place.

Does not have to be illegal or shady.  Could be ASIC of his own.  If I can afford ASIC run, he can, especially if he has mined many bitcoins with improved bitstreams.  Could also have access to better FPGAs with more gates that better to suit algorithmic approach.

Think if BFL mined instead of selling.

First, none of this has anything to do with opensourcing the bitstreams or not.  Regardless of how much hardware he has personally, this wouldn't change either way.  I fail to see how this is relevant.

Second, BFL does mine on unsold hardware prior to shipping to customers, and also if they didn't sell hardware they wouldn't have the money from poor pre-order fools to make any hardware to mine with themselves.

or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.

Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.

That's the problem though. This particular IP's purpose is to generate profit directly.  Therefore, the IP actually doesn't have any other value outside the amount of commission he would make with it unless it is sold entirely, such as through the bounties offered.  That's the point.  The only way it would have an increased value to the creator is if it is somehow generating more profit than we're led to believe.  Regardless of how someone may feel about their IP, it's worthless if in the end there is little to nothing to show for it.

You can't compare Windows XP to this bitstream.  Windows XP was successfully sold to millions at a profit already, and XP licenses are still valid.  Windows XP has turned a profit for MS, so, they have no reason to accept a "couple thousand bucks" to open source it.  The difference here is, assuming this bitstream legitimately does what we're told as advertised and nothing more, then the creator has not profited from it and will not profit from it more than the value of the up front bounties offered to simply release it in source form.

[Borzoi]

First, none of this has anything to do with opensourcing the bitstreams or not.  Regardless of how much hardware he has personally, this wouldn't change either way.  I fail to see how this is relevant.

or c) He feels the IP has value outside just the amount of commission he might make, and he might want to leverage it for something else.

Just because MS isn't selling Windows XP anymore doesn't mean they're going to GPL the source if you cut them a cheque for a couple thousand bucks.

That's the problem though. This particular IP's purpose is to generate profit directly.  Therefore, the IP actually doesn't have any other value outside the amount of commission he would make with it unless it is sold entirely, such as through the bounties offered.  That's the point.  The only way it would have an increased value to the creator is if it is somehow generating more profit than we're led to believe.  Regardless of how someone may feel about their IP, it's worthless if in the end there is little to nothing to show for it.

You can't compare Windows XP to this bitstream.  Windows XP was successfully sold to millions at a profit already, and XP licenses are still valid.  Windows XP has turned a profit for MS, so, they have no reason to accept a "couple thousand bucks" to open source it.  The difference here is, assuming this bitstream legitimately does what we're told as advertised and nothing more, then the creator has not profited from it and will not profit from it more than the value of the up front bounties offered to simply release it in source form.

I try one more time.

Imagine Dr. Tyrell has invented new shovel design.  It can move more dirt than every other shovel and is ergonomic so user can work all day.

If he sells Stakhanov Shovel as design for $7700, that is all he makes.

If he rents shovels for percentage of improved dirt moved, he makes x dollars minus cost of production and maintenance (signcryption services).

If he hires 500 people and gives them shovels to mine own land, he makes full profits of improved output, minus cost of production and maintenance of shovels and cost of labor and land use.

Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?

[ShadesOfMarble]

Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?

Good read: https://bitcointalk.org/index.php?topic=49971.msg1253774#msg1253774

[Borzoi]

Math homework for you.  How much rental makes him 700btc?  How much makes for him 700btc for custom hardware he keep private?

Good read: https://bitcointalk.org/index.php?topic=49971.msg1253774#msg1253774

Excellent!  I pay price for not reading all of thread.  I will review now.

EDIT: After review, if take 5000 eligible units and increase throughput from 210 to 255 mhash/sec, will generate almost 74btc extra per day at current difficulty.  If take all extra, exceed 700btc in less than ten days.  With real commission, inverse ratio for break-even.  19 days for 50%, 38 days for 25%, and so on.

5000 units is 1250 4-chip boards.  That is acceptable estimate.

[Keninishna]

In psychology the more you argue with someone the more energy they are going to put to defend their position. I believe people have put lots of energy in asking ET to release his bitstream and he has said no, he's probably not releasing it just simply because he doesn't want to change his position on open sourcing it. People are irrational beings.

[eldentyrell]

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.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.

You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.

[eldentyrell]

Well, 700 BTC may not be adequate, but it's more than getting almost nothing from commissions.

I am really tired of responding to this, so this is the last time.  Please see The Ultimatum Game.

[eldentyrell]

My Radeon GPUs can be locked down nicely inside KVM.

And you've audited the KVM firmware?

That would be the more appropriate analogy.

KVM is open source software.

And your hard drive's firmware?

*crickets*

[2112]

I've found a good link that will help to understand curious people why eldentyrell is unwilling to open source his Xilinx toolchain.

First, you have to really notice the world "algorihmically placed" in the title of this thread. It means that he had developed his own tool to do placing of the primitives and uses the ISE only for routing and the following stages of bitstream generation.

Second, the source form that enters the Xilinx ISE tool chain is in his case XDL, not VHDL or Verilog. XDL is the textual version of the NCD (Native Circuit Description) format used internally by the Xilinx toolchain. Try running the "xdl" tool on any .ncd file from any other open-sourced Xilinx project to understand that this format can hardly be called human-readable.

Here is the link to a very good 8-page document explaing what is XDL and why to use it:

http://www.mn.uio.no/ifi/english/research/projects/cosrecos/publications/paper/recosoc11beckhoff.pdf

I would venture to guess that the total value of the "algorithmic placer" replacement tool for the ISE toolchain greatly exceeds the BTC sums mentioned in this thread. It is quite possible that even the documentation for it (if it exists at all) would be considered extremely valuable and could be used to redevelop the actual custom placer tool for cheaper than it took to develop it originally.

[kano]

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.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.

You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.

Hmm - so since there seems to be an interesting discussion going on here - I thought I'd add into it

Firstly, yep the amount of money made from this would probably be pretty small ... but that's not my point of interest

ET is using Luke-jr's game of word play correctly saying that it is a double compression fallacy

'Compressing' 2 nonces into a single one is quite simple taking the stance of having the server do the missing work that wasn't sent back - so it isn't compressing, but rather working around losing half the data.

When you hash a block header you simply roll the nonce value from 0 to ~4billion (32 bits 2^32) and from that you know which nonce value you want - which clearly EVERYONE knows ...

So e.g. putting 2 half nonces into a full nonce, then having to regenerate the missing half of each nonce (65536 hashes x two) is really something quite simple for any CPU to do - since it is 32768 time faster for the CPU to do both, than having to work out the full nonce for one of them from scratch
As long as the server's hash rate is at worst 32768 times smaller than the network hash rate sending data to it, the servers can handle that.
So if a server can hash at 20Mh/s then it can handle 650GH/s of incoming half missing nonce data.

So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.

[Borzoi]

So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.

 

[eldentyrell]

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.

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.

Unfortunately I have not been able to get ChrisP's code working.  It finds the FTDI chip and thinks it is shifting the JTAG chain, but what comes out is all 1's.  There could be a variety of reasons for this; it's not actually shifting the chain, it's not reading the output correctly, etc.

I have only remote access to the Enterpoint board (and no, I don't want one, so please don't offer to send me one), so I can't do stuff like flip DIP switches or put a voltmeter on key signals.  It's a bit like stumbling around in the dark.

Also unfortunately, the time I'm able to devote to this comes only in small, short bursts.  It may be a few weeks before I am able to try again.  Hopefully ChrisP re-emerges before then.

[wizkid057]

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.

Yes, that's exactly what it is.

I'm not going to write a post explaining the double compression fallacy to you.

You have the bulk of the data already (the work)

Nonces-which-are-shares are statistically random and therefore incompressible.  Every possible 32-bit integer is equally likely to be the solution to a randomly chosen piece of work.  You're trying to claim that knowing which piece of work it solves somehow effortlessly adds information.  It doesn't.

Given a nonce-to-be-transmitted, the Shannon entropy of the additional foreknowledge of the work which it solves is exactly zero bits unless you actually do the work -- subject to the assumption that SHA-256 is a one-way hash function.  So the only way this is not double compression is if you've somehow found a way to invert SHA-256 and it isn't a one-way hash function anymore.  If you have figured this out, you shouldn't be wasting your time here on the forum -- you should be coding up that inversion function, mining 99% of the bitcoins, and rolling in piles of money.

Call me when you're rolling in piles of money.

Hmm - so since there seems to be an interesting discussion going on here - I thought I'd add into it

Firstly, yep the amount of money made from this would probably be pretty small ... but that's not my point of interest

ET is using Luke-jr's game of word play correctly saying that it is a double compression fallacy

'Compressing' 2 nonces into a single one is quite simple taking the stance of having the server do the missing work that wasn't sent back - so it isn't compressing, but rather working around losing half the data.

When you hash a block header you simply roll the nonce value from 0 to ~4billion (32 bits 2^32) and from that you know which nonce value you want - which clearly EVERYONE knows ...

So e.g. putting 2 half nonces into a full nonce, then having to regenerate the missing half of each nonce (65536 hashes x two) is really something quite simple for any CPU to do - since it is 32768 time faster for the CPU to do both, than having to work out the full nonce for one of them from scratch
As long as the server's hash rate is at worst 32768 times smaller than the network hash rate sending data to it, the servers can handle that.
So if a server can hash at 20Mh/s then it can handle 650GH/s of incoming half missing nonce data.

So ... I don't see the flaw in this concept (other than if you are totally fixated on money) and the fact that it isn't 'compression' - it's simply throwing away data that can be regenerated within an allowable short amount of time.

At least someone understands what the hell I'm talking about. Thanks.

[eldentyrell]

TML v1.13 has been released.

The only significant change is that I have included ChrisP's partial implementation of support for the Enterpoint proprietary USB interface.  If anybody can get this working beyond the "JTAG-stuck-at-1" point, I will resume trying to figure out the clocking issues.  But at the moment I can't even get it to talk to the FPGA, so we're still in "dealing with vendors' proprietary interfaces" land where most of you guys are far more skilled than I am.


19.Oct.2012  Release v1.13
             fix division-by-zero bug reported by TheSeven
             Add various difficulty-manipulation utilities in com.triconemining.bitcoin.work.Difficulty
             Add libFtdiNative for amd64
             Add ChrisP's code for Enterpoint proprietary USB (not working right now)

[max in montreal]

anybody ever get this to work on an x6500?