are the mining practices of this coin sustalinable some how? why is it called sustainable

is this still worth buying into?

Offering Steam games gifted to you at a rate of 1.25 BTC per $5 of Steam game.
I will also buy things on your Amazon wishlist for you at the same exchange rate.
I also have two Dota 2 beta invites I'm selling for 1.25 BTC each OBO.

It can be arranged for me to buy things with my credit card for BTC as well, it depends on your rating on #bitcoin-otc.
(check my rating on otc, I'm nonverba, we can talk on there so I can verify)

PM me if you're interested.

Probably belongs in a SHA-256 thread, but I think what you're referring to has to do with precalculated(or -able) round values, and the initial value for those.
If there's a problem with the core.vhd, well, that's cause it's a work in progress, it'll get worked out.  And smaller...

Sorry to do the double-post but here are some numbers from the Cyclone V series FPGAs:

5CGXBC7D6F31C7 (Grade 7): 215.84 219.93 MHz

I'm liking this device family already.  As always, more to come.

P.S. This design does not "take up too many IOs", taking up too many IOs assumes you don't use some sort of serialization, which is rather absurd.

P.P.S. When compiled for the Stratix III EP3SL100F1152C2, the fmax is reported as 229.52 MHz, if you were wondering.

*These values are sans optimizations... if anyone can tell me how to make Quartus not synthesize away multiple cores, please let me know, and then I can give you some numbers that more likely reflect reality. (Although there's probably a problem with the core.vhd I need to fix... I work way too much and I have an exam later... I need to leave this alone.)

Correction: the .zip file comes with only a quickly thrown together sdc and no qpf, just vhdl.
-Edit-
I can admit a mistake, you're right, with zero register duplication, no optimization, no resource sharing, etc, the core takes up 1925.  But let me be very clear: with optimizations that size goes down significantly, I've shut off all optimization in order to preserve logic that would otherwise be synthesized away.  To think that it won't use sharing with all of the XOR, AND, and + repetitions is absurd.
Apparently, however, I need to revamp my numbers, so I'll get something back to you on the core controller soon.
Also, in the design report the multiplexer restructure savings alone are 81 LEs, so 1925 -> 1844 for the current design.

In better news, I have my mining core shrunk from 768 -> 582 LEs as of today.


Does it port? Yes.  I don't have experience with the Stratix III series, does it use the same architecture (or similar) to that of the Stratix IV? If so the logic count would be decreased (compiling this on my Stratix IV gave me better numbers than the ones I've quoted).  I haven't looked into the pricing on that unit but work will continue and if Altera devices become advantageous, then we'll use them.

Not to be too advertise-y but my FPGA mining solution doubles as a dev board or a ucLinux PC.

And nobody's going to decrypt an AES bitstream... who was it that said that...?

FPGAs are good and reusable, even already soldered in, that might even be helpful (depending on what pins are accessible and/or what it's hooked to on the board).

Making a bitstream ain't so hard if you learn an HDL and download some free software.

As for FPGAs being unusable because of their bitstream, that's bunk.  It's encrypted so you can't reverse engineer or steal it, but if you want to stick your own bitstream into the configuration PROM/FLASH/JTAG/USB-Blaster, you can go right ahead.

I warn you all I've been awake for 72 hours working on my thing, so if any information here is iffy, don't kill me for it...
 

I've got a preliminary Nanominer bitstream.  I'd like to be clear about whether it works: the digester is functional and has been tested with fpgaminer's code.  The rest of it looks fine in simulation, but the final product's *control circuitry* (i.e. state machines) may need fixing.  That said, the digester, which is the heart of it all *definitely works* at the size and performance I'm quoting here.  To prove this to everyone, I'm linking a .zip with the design files so you can see what I've been working on.  I only guarentee the digester (working_sha256.vhd) works 100% but so far the rest looks good.
Also that digester is sitting in for a better, more pipelined one that is smaller and performs better, but is still in the works.  I thought I'd let you all see something that actually can produce bitcoin.  The *current* specs are as follows:

Note:
-Compiled with Web Edition, I need to go to school and put this through the subscription one
-The fmax *varies* with the chip
-I do not know if this is analogous to Xilinx logic consumption; if it is, things are going well for all of us.
-The code is run preserving nodes with lost fanout because I don't have decent input and Quartus wants to synthesize away the duplicate cores (which are actually working in parallel
-I'm posting this for your interest, peace of mind, and maybe to whet your appetite, this is not to be scrutinized; it's a work in progress.  Constructive ideas, go for it, but picking the hell out of my design really won't do much good
-The new core is very promising, I expect a ~15% increase in performance in the next week

So:
Control Circuit Logic Consumption: 289 LC Registers (One per chip)
Core Logic Consumption: 1844 LC Registers (Iterative, as many as you like)
Cycles per Hash: 128
fmax @ Speed Grade 6: 201.73 MHz  (Cyclone IV)
Hashrate: 1.58MH/core
--edited to fix size--

So, it's not completely groundbreaking, yet, but there's a lot more where this came from.  This little announcement is more to say that I'm working, and this thing is coming.  I have my core less than 800 LEs (which would mean a DE0 hashrate of >40MH/s, and a significant improvement past 210MH/s on a Spartan-6), but I need to get timing logistics down, so more to come.

In the meantime, I'll post the VHDL for you all.  As always, donations are welcome, I do spend a hell of a lot of time on this and the way things are looking I'll break more records than just the DE0-Nano speed record.  I haven't broken the 210MH barrier yet, but soon enough, I just need to put a little more time into it.

Edit: By the way, it's not commented, and it's got an SDC but no QPF or anything, just straight VHDL.  All rights reserved me etc. cheers!

I'd agree with you but it's not the best screen around, the cost is certainly negligible.  It's more so that someone using it as a standalone device can see what's going on with their miner without having to plug it in anywhere.

1 Mainboard, +4 Addons.
Expected power budget is 11W/board, but I'll try to cut down if possible.

How does $325 USD + shipping sound for the main board, and $275 USD + shipping for expansions?

Features (Main Board):
-LCD Display
-200 MH/s Hashrate
-Xilinx Spartan-6 XC6SLX150 FPGA
-Standalone Functionality
-More than capable of running ucLinux (2MB Flash, 8MB SDRAM, ARM M4-Cortex MCU)
-Modular Expandability
-Reconfigurable to do as you like, not just BTC mining
-USB and Ethernet interfaces
-Maximum 4 Expansions per Main Board (Firmware Imposed)

From the sounds of it, you'd be willing to pay a little extra for some bonus functionality.  Let me go back to the drawing board a little bit, and see what I can do about offering something that does it all on-chip, so that you can plug it into your router etc. at home and have it mine without a host.  USB will remain available for those who don't have an extra port on the router, and WiFi will be an *option* too, though it'll tack on a little money.
After some review, I'd like to make it clear that there will be a maximum of 4 expansion boards per main board. (Note that a specialized jumper tech is in the works, this number may increase)  This will be a limit imposed by firmware, and you can modify it if you like, but it will be unsupported.  The price of a main board won't be *that* much more, so getting 1 GH/s per mainboard-and-four-expansions isn't too bad for the price.  Not to mention the fact that it's modular.
As far as what my offering has that others don't, the modularity and Ethernet, as someone mentioned, are a plus.  Now, standalone functionality and WiFi capability will also be a bonus.  All of this in addition to the fact that my prices are competitive, if not cheaper than the going rate for FPGA miners.
Let me lay down a schematic that allows for standalone operation and I'll let everyone know what the price is looking like, so y'all have a better idea.  Spoiler: It will be more expensive given that it is standalone, but I can tell that that would be convenient for some of you, so I'll check it out.
Keep an eye on the post, and thanks for your comments!

The board, as advertised, already has USB and Ethernet functionality and connectivity with the firmware.

Yes, perhaps an expansion card with LCD capability could be arranged, no they are not that expensive.  Perhaps I will add a communications port for peripherals that can be purchased seperately on these counts (LCD, SD, etc.) without having to include them in the project and make the whole thing more expensive.  I will not, however, impose features on people.  It will be barebones, then will have the capability to expand with whatever fancy parts you'd like to have.

If something running without any host machine would be something you're interested in, I'll look into modifying the design.  It means it's going to probably cost a little more (not tons, but some).  It also means I'll switch over the MCU I'm using to something more effective for the job.
As far as an LCD, that's doable, as long as you understand that it's going to make it cost more.  Same with, say, WiFi compatibility.  Add about $20 per "feature" like this to the price of the unit (main board, that is).

I was asked about how the boards are expanded upon, and gave a short answer that summarizes the solution.  I'm well aware of the challenges that are encountered when transmitting signals.  I didn't going to go into absurd detail, but in anticipation of people getting irritated that I say that a bus is indefinitely extensible, I even said that to maintain performance there would be a limit imposed on devices per bus.  That's not to say there aren't other things in place to preserve performance, but I figured it would be sufficient to say that, at least.  Apparently it isn't, and I'll try to do better when answering questions in the future.


These I am taking into account, except for perhaps an SD card slot, but I figured the good folks around here would probably just be more interested in what I'm using for hashing, and maybe what I'm using for control, and not so much the infrastructure chips that will make it all possible.  The MCU in particular might get replaced with an AVR32 or an ARM device.  I won't be running Linux on the MCU, whatever it ends up being, because that's too much overhead.  However, given the board's specifications, I'll make sure that if people would like they can program the device with Linux, provided the resources to do so don't make the board cost anymore than it already would.

If you read the full description you'll see that one motherboard does not limit you to a certain number of devices.  They run on a bus, which is extensible indefinitely, at least in theory.  The bus can be connected with stacked headers, or via a jumper cable, so there's no capacity limit physically either.  There will be a firmware imposed limit to ensure performance.  Since the firmware will be open source, you'll be welcome to remove said limit.

Perhaps, if there's a lot of demand for multiple-miner boards, I'll adapt the design.  Until that time, as it's been made abundantly clear, I need to prove myself, and to do so I think a good place to start is affordable, easily extensible, single core miners.

Additionally, I'd like to know where these bulk FPGA discounts are from, I've yet to find a distributor who will give more than a pittance of a discount on large orders.

Exact control and mining hardware specifications are listed in the newly updated first post.  Specifics can be found there, but the control device will be a Microchip PIC32 and the FPGA will be a Xilinx Spartan-6 XC6SLX150 running at 200 MH/s with the current firmware.

Although I'm unsure of what Silicon Valley professional rates have to do with anything here, I appreciate the suggestion regarding improving the bitstream.  I did already say that the quoted 200 MH/s was a verified, proven, base rate, and if you read reasonably you'll find most of the numbers I have right now are preliminary numbers, numbers that are a worst-case scenario, numbers that I will try to improve, but that are not inflated because I do not want to promise what I cannot deliver.

Compatibility and integration with existing systems are a great idea, we want this to be as versatile and easy to use as possible. There will need to be a dedicated GUI/toolkit for Nanominer, if only for configuration and use of features unique to this system. As he's mentioned, Azelphur is my man handling the software side.  He does good work and I'm lucky to be working with him.  He's the one to talk to with ideas on how to make the user experience better .

As far as 28nm technology goes, Nanominer's first iteration will not be on a 28nm chip, it wouldn't be economically feasible.  However, to answer your question, in the future when it's within a reasonable price range, we'll be more than capable of delivering miners on whatever technology is available, 28nm or otherwise.  That is, unless my research, work experience, ECE degree (in progress), and hobbies all go to waste, which I doubt they will .

And no, as to the Nano running at 75 MH/s that figure was a well meant but frankly uneducated estimate on my part.  Maybe I should say here that I'd like to apologize for promising the moon in the earlier stages of this project.  I know that people offering more than they can deliver is not something you all want to hear.  That's why, with this project, I'm offering nothing more than what I know is possible.  If you'd like to know how I came to a decision about a feature, or have a question about how I intend to achieve what I promise, please do ask.  It's all being planned out with the help of others with various areas of expertise, and always conservative estimates.  I'll be happy to release something that outperforms what I promise, but in engineering there are always unforeseen hurdles, so I'm trying to be realistic, and even a little pessimistic.

More to come...

I'm based in Canada, however I know that the demand for these boards will be international. 
My goal is to mitigate some of the shipping cost by decreasing the profit margin, like I say my goal is only to make enough to be worthwhile and pass on the rest of the savings.
As well, small form factor and an off-board power supply will also help with this, though I know this holds for most FPGA mining technologies.

I'd also just like to make clear that an FPGA has not been chosen for this board in hopes that by the time things are ready, a chip other than the Spartan 6 might be cheaper or perform better. There are, however, candidates.

I am not planning on using a 28nm chip, either, unless something really, really unforseen happens.

In fact, so that there are no miscommunications, the current candidate FPGA device for Nanominer is an XC6SLX150.  That is subject to change.