If you haven't already, you have to delete/remove WiFi, not just disable/stop it.  Network->Wifi->Remove

Obviously: Make sure you have set up and are running over LAN first.

Well that's disappointing.  Looks like the c-scape based boards will ship before Metabank's design ... and those are U.S. local and were bought much later. 

On the other hand, we paid less, so it's not all bad.  I'll keep dreaming and hope Metabank can deliver early September.

Thank you for keeping us up-to-date, digitalmagus!

Check the System Log.  Do you see any errors with the error code -71?

Please search before asking; it saves everyone time.

NMW is just another kind of hardware error.  Best to just ignore it.

In for 10, more if possible.  I'll wait a bit before sending payment; want to see what other details we get from friedcat.

Arklan, I can front the 50 BTC to cover a 500 unit order from friedcat, if everyone wants to get this thing ordered and shipped ASAP.

Thanks for the link, retep!  I was not aware of RFC2289, and it's great to see a standardized wordlist like that.

I describe the internals on the github README.  By default, PBKDF2_HMAC_SHA256 (50k iterations, no salt, 32 bytes) is applied to the input data.  The resulting 256-bit hash is converted to an integer and then used to create the phrase.  So it's resistant against second pre-image attacks.

Can you give a concrete example of how that kind of tampering could be used by an attacker?

Hash Phrase spits out a series of words.  It's not possible to fiddle with the letters in the words to give a different hash; you would just get an invalid hash doing that.

The applicable use cases occur when you have a known good Hash Phrase, potentially manipulated data, and a trusted way to calculate the Hash Phrase of that data.  The only thing an attacker can really do under that situation is try to brute-force similar phrases.  So if the real phrase is "Random baptism coaches seymour parishes", they might expend computations to brute-force data that hashes to "Random baptism coaches electric parishes."  But doing that would require ~1x10^21 iterations of SHA-256, which would take thousands of years on a modest farm.

While working on my Hardware Wallet project, and while using Bitcoin in general, I often found myself manually comparing destination Bitcoin addresses.  This is a good practice, to ensure the destination address is not tampered with by malicious software.  However, addresses are base58 gibberish, and thus difficult for a human being to compare; they could be fooled by a partial collision attack.

In addition to that, I had the thought that a browser extension which displays a webpage's hash to the user would be helpful for security critical, static websites like brainwallet.  That would help prevent tampering.  But nobody is going to memorize a hexadecimal hash.

One solution is a human readable hash function; one which is easy for humans to read, memorize, and compare.  My first implementation, Hash Phrase, outputs a phrase composed of common English words.  For example, the Hash Phrase of my sig's Bitcoin address is "Random baptism coaches seymour parishes."  Easy to read, memorize, and/or compare!

I'm interested in discussion on this particular implementation, alternate solutions, and applications.  For example, this implementation suffers from entropy starvation; it can only reasonably represent ~64-bits.  Its phrases are also sometimes confusing and weird, which makes them difficult to remember.  A procedural image based hash function would likely be a better solution, but is more difficult to implement well.

DoctorDoom, I'm going to be straight with you.  Beyond learning/fun, there is absolutely zero reason to invest your time in optimizing a design for the Spartan 6 LX150 platforms.  As I said before, BitFury's open source design for the Spartan 6 LX150 is already at the zenith and will not be surpassed by any meaningful margin.  That design achieves ~300MH/s and should work on all existing Spartan 6 LX150 based miners (X6500, Icarus, Lancelot, Quad, etc).

I say this, because, from what I gather from your posts, you sound like an intelligent, creative, and hard working fellow.  I do not want to see those talents burned on a fruitless task.  If you're only doing this for fun/learning, then by all means continue.  But it sounds like you seek to benefit others from your work, and to profit from your work.  To achieve either or both of those goals I encourage you to focus your efforts elsewhere.

BitFury's design needs porting to the existing FPGA mining platforms.  It's really minimal work, and would boost everyone's performance by 50%.  That would benefit people very immediately, and I'm sure people would pay you for it.

Or you could focus on a strictly ASIC design, an scrypt miner, SL3 cracker, etc.  There are plenty of fruitful opportunities around.

Sorry if this post sounds malicious.  That is not my intention.  I'm not normally this blunt, but I've seen one too many threads like this.

Get a white noise machine.  It's perfect for people who sleep better with some background, wind-like noise.  That particular model (I own one) generates a hollow, wind blowing through a cave, sound.  Covers the mid to high frequency range pretty well. 

That said, in my personal situation, I have to go a step further since my goal is not sleep assistance, but noise cancelling.  I have a huge subwoofer playing a looping white noise track off an old iPod.  The subwoofer fills my entire apartment with a dull drone, blocking almost all "apartment living" noises.  Very effective.  But for you, if sleep is the concern, that puppy linked above should be enough to slay your sleep demons.

Thank you for the comments!

Progress Update

• UI redesign is done, so the user interfaces looks half-way decent and user friendly.
• The touch detection code is fixed, and now touch detection is rock solid; important for the on-screen password keyboard!
• USB code is fixed, and has been rock solid since.
• Optimized the code. Transaction signing is much faster now.
• PBKDF2 iterations increased to 50,000.  This makes it difficult in the extreme for hackers to crack your wallet or backup password. For reference iOS 4 used 10,000 iterations.
• Code audited for the ~millionth time.
• A hundred other things.

First Open Source Code Released

Strong ARM

In the fullness of time, all of the code for the Bitcoin Titan project will be released publicly.  Users of such a device have a right to know what code is running on it, and Bitcoin deserves a healthy ecosystem of open source code.  Today, I am releasing the crypto library codenamed Strong ARM under the Open Source MIT license.  This library contains all of the underlying cryptographic functionality of the Bitcoin Titan project.  It's built to be lightweight, for easy auditing, and use on embedded platforms.  I built it from scratch to ensure my intimate understanding of every aspect of the Bitcoin Titan device.

For the curious souls, this crypto library is not currently built to withstand side-channel attacks, nor is it built to pass any standards like FIPS 140-2.  Those features are considered future, but non-critical improvements, within the context of the Bitcoin Titan project.


What's Next?

I will be recording and posting a new update video, to showcase the new PCB/form-factor, and UI.

More importantly, I'm looking into the case design.  This is an area I do not have much experience with; I'm open to suggestions/help here.  The case will certainly need to be custom to fit the unique form-factor.  Hopefully there are some useful services out there to assist in designing and manufacturing the case.

It's a lot of fun down there!  It's a shame the Spartan 6 architecture is so limited.  I suggest you take a look at the 7-series FPGAs, like the Kintex or Artix.  The architecture is nicer, and performance is much higher.  For example, I was able to implement a miner using the DSP48E1s on a Kintex.

Also, have you looked at bitfury's code?  He has the most performant code for Spartan-6 LX150 chips, and I would be shocked if anyone beat his record (in MH/s) on that chip.  It's optimized down at the slice level and manually placed.  https://bitcointalk.org/index.php?topic=228677.msg2417706#msg2417706

Unfortunately, or fortunately (depending on how you look at it), FPGA's will never beat ASICs in terms of performance per dollar, or performance per Watt.  So FPGA mining is a curiosity and plan-B sort of thing now.

I coded up a quick SL3 cracker about a year ago.  It either ran on my Spartan 6 devkit, or the X6500, I can't recall.  I could probably dump the code to github if people are interested.  I didn't optimize it particularly well, just got it working.

You mean https://github.com/fpgaminer/Open-Source-FPGA-Bitcoin-Miner?  That's not converted C.

Thank you for the update, digitalmagus!

I'm holding out hope that they ship two of those boards per unit and underclock them to 1.25GH/chip, like the cscape design, for future overclocking

Not really, no.  Extra cooling will only marginally improve hardware error rates, power consumption, and longevity; probably not worth the extra electric bill.  Based on your quoted hashrates, it sounds like you've already clocked up to ~350MHz, which is all you will get out of a stock Avalon, cooling or not.  Going past ~350MHz will require overvolting, which cannot be done without modifying the electronics in the unit.

Regarding the spikes, those are just due to variance and don't indicate potential hashrates.  Remember, these are mathematical slot machines; sometimes you win a lot, sometimes you lose a lot.

Thank you for the response, ckolivas.  Enjoy your trip!

ckolivas, thank you for all of your hard work!  I had a question about your latest Avalon firmware (20130703).  I upgraded one of my Avalons to it tonight (was running ~20130624 at the time).  I noticed that suddenly the numbers reported under MHS5s lost a lot of variance.  This is a graph of MHS5s over time:



8pm is when I upgraded the unit to 20130703.  You can see that it suddenly quieted down quite a bit.  Before and after the upgrade I was using a constant clock frequency (345).

I'm curious, did you change any of the code related to that particular statistic?

I hashed so hard
And got so low
But in the end
It doesn't even matter

Humax:  Try connecting your sick Avalon directly to a PC.  That means:

1) Switch the unit's power off, and unplug from wall.
2) Open the case.
3) Remove the "P5 jumper" (labelled J1 on the board) located immediately behind the USB port on the FPGA controller board.  See: https://en.bitcoin.it/wiki/Avalon#FPGA_controller
4) Either a) disconnect the USB cable from the TP-Link and connect to a PC, or b) disconnect the USB cable from the FPGA controller and use your own USB cable.
5) Power on the unit.
6) Make sure your PC recognizes the Avalon (it comes up as a serial port).
7) Get/compile a copy of cgminer for your PC; make sure it includes Avalon support.
Run cgminer (e.g. "cgminer -S /dev/ttyUSB0 -o stratum.btcguild.com:3333 -O xxxx:yyyy -D --verbose --avalon-options 115200:24:10:45:282")


Of course, you'll need to adjust how you run cgminer depending on your PC's OS and what port your OS assigned the Avalon to).

In case you're wondering, I had to do the same thing for one of my Avalons.  It constantly restarted, due to the dreaded -71 errors.  That particular Avalon has been running with no problems ever since I hooked it up to a Raspberry Pi instead.

NOTE: If you choose to reconnect the Avalon back to its TP-Link, DO NOT forget to reattach the P5 jumper.  If you don't, it definitely won't run

Nice   Pics of the sexy, bare PCB would be eroticfun to look at!