I will start by saying that altsource_probe is not an efficient way to communicate with the FPGA, so there is little practical point in optimizing its usage.  I occasionally use altsource_probe in my work because it is simple to use and quick to get working.

I don't quite understand this question.  There are two sets of altsource_probes in the Altera targetted designs.  midstate_vw_blk and data2_vw_blk provide the input the mining core needs to mine.  golden_nonce_vw provide a means for the mining core to report any gloden nonces it has found (nonces which result in a share that can be submitted to a mining pool).

The way that code is designed (specifically, this code), is that any found golden nonces are written to (and thus overwrite) the golden_nonce register.  When the host computer reads the golden_nonce_vw_blk altsource_probe, it's just reading the golden_nonce register.  There's no buffering or anything.  So in the current design, there's no way to buffer results.  Like I mentioned at the beginning of this post, this isn't meant to be efficient; just quick and simple.

Are you referring to this line?  Remember, all a miner is really doing is SHA-256 hashing a block header.  SHA-256 requires that the input data be padded out to a multiple of 512-bits.  On that line, the 384-bits are the padding that gets added to the block header.  They are constant, no matter what block header is being hashed, because all block headers are (currently) the same size.

Thank you for sharing your idea, Senseless.  I love getting people engaged in this field of engineering.

Forgive me if I misunderstand your design, but I believe you have replicated what the current FPGA mining designs are already doing.  For example, on the X6500 board, the jtag_comm module communicates with the mining core in the rx_hash_clk clock domain, and communicates with the outside world in the jtag clock domain.  You can see the Asynchronous FIFO that shuttles golden nonces from rx_hash_clk clock to jtag clock here.

There is certainly work that could be done there, though.  JTAG is not a good communication method for this sort of task.  On the X6500 it was simply chosen to reduce cost and complexity.

In this case, the DSP48E1's are taking care of the heavy lifting; three and two-way 32-bit addition.  The rest of the fabric only needs to handle registers, routing signals, and the non-linear math.  Obviously the Kintex 7 fabric is capable of handling these frequencies for modest logic, otherwise the DSP's would be unusable in the first place

But, as I said before, I already did a rudimentary implementation of this design and synthesized/routed it.  Timing reported ~400MHz on the devkit.

Quartus, ISE, and Vivado all have options to target minimizing power.  I don't know how good they are at it; probably not very.

Actually, unrolled cores are very straight-forward designs.  The issue is that FPGA's are routing constrained, especially in the Spartan 6's, and the tools aren't designed to handle these sorts of long chains.  The Kintex 7 chips are much nicer with respect to routing resources and consistency.  Also, the newer Vivado Studio tool does a much better job than ISE in my experiences with it so far.  It's a shame Vivado does not support S6.

In my opinion, Avalon was smart in this regard and did it right.  Using lots of chips is a very good thing for these early mining ASIC's; I would not have recommended it any other way.  This is because there are rather large Minimum Order Quantities when producing ASIC's.  If you sell 1000 units, each with 4 chips, you aren't going to reach the necessary MOQ's, which are at least 50K chips.  Selling 1000 units, each with 240 chips, puts you in that beautiful quantity where the fabs and factories start giving you the time of day.  And the cost of everything else goes down.  In the long-run, yes, bigger chips are a better idea since they require less overall supporting circuitry and PCB space.

Slightly related:  I would not recommend fully unrolled cores for an ASIC design.  It will certainly result in higher performance per area due to optimizations unique to the unrolled designs, but it means higher failure rates and lower clock speeds due to intra-die variations.  Fully rolled cores that can be individually enabled and clocked (or clocked in regions) should give better yield and overclocking.

Picking where all the logic goes in the FPGA yourself, instead of letting the Place and Route tools do it.  It's incredibly tedious and not very well supported/documented.

Sorry, I was talking about Kintex 7, which most certainly can.  Kintex 7 has similar performance to the Virtex 6, at less cost.

Your best bet would be to modify the code to use a serial interface that could be chained, instead of the altsource_probe.  You could do it with the current altsource_probe, but you'd need to modify this code to find multiple devices.  Also, last I checked, Quartus had issues handling more than one device plugged into the same USB controller.

Yes.  DSP48E1's can run up to 500MHz, so if you unroll all the calculations, replace all the additions with DSP48E1's, register everything, and throw in misc. logic for the non-linear calculations you can get about 500MH/s, depending on the speed grade.  It all fits into a Kintex-7 160 (the 160 has a higher DSP48 density than the 325).  Probably some room left over for a normal hashing core, though I'm not sure.  The DSP design requires quite a lot of registers.

EDIT: And yes, I implemented the design, so it's feasible.  It was never fully debugged though, because at the time the Xilinx simulator couldn't handle Kintex's DSP48E1's very well.

Quick note, kramble; the max is actually 511-bits.

It uses JTAG.  There is an FTDI chip on there that allows bit-banging pins over USB, and so compatible software bit-bangs JTAG to talk to the FPGA.  The entire protocol sitting on top of JTAG is described in jtag_comm.v.

I would recommend starting with the X6000_ztex_comm4 project.  That's the same code that generated the bitstreams on the fpgamining.com website.  You'll want to remove the jtag communication related code and replace it with serial communication, or something else.  You can then multi-core that and exchange some resources for DSP48s as iidx mentioned.

It's also possible to implement a miner using only DSP48s and misc. logic, achieving about 500MH/s.  I haven't released any code for that yet.

Feel free to ask your questions and I will answer as best I can when I have time to do so.

The code that compiles at 200MHz is about as close to efficient as you'll get without doing manual placement.

If I recall correctly the X6500 consumes ~20W, so you need more like 2amps at 12V.

https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L177

Contact the OpenSSL devs if you find anything: http://www.openssl.org/support/
As well as the implementors of /dev/urandom

Maybe 1MH/s or two, off the top of my head.

lapo.it seems to have a bug when it displays the octet string.  Hover over it and look on the right where it has highlighted the hex dump.  Copy that part of the hex dump, except for the beginning "04 20".

If you want to do it manually, without lapo.it, just search your DER encoded private key from the beginning for "04 20" and grab the following 32 bytes (64 hex characters).  Example:


EDIT: I'm assuming you're getting the DER encoded key from somewhere other than brainwallet, as obviously if you already have it on brainwallet you can simply copy the Secret Exponent directly into blockchain.info.

Open Source Vanitygen for FPGAs

Source on Github

Animated Github Log



April 13th, 2013
The first Open Source Vanity Address Generation for FPGAs firmware is now available on Github!  This first release targets the Altera Cyclone III C120 Development Board, and is more a proof of concept than anything else.  It's functional, but only runs at ~40Kk/s.  Feel free to dive in and port to your own FPGA boards.

I have more performant code under development (unrolled/pipelined).

See the OP for links to the source code and such.




Original Post, March 12th, 2013.

For my own clarity of thought, here are descriptions of the cryptographic systems currently in use by the Bitcoin Titan.  Obviously they may change, and some are missing (like all the schemes for firmware upgrades and such).


Deterministic Key Generation
The Titan uses a variation of the up-and-coming Chain Code ECDSA key generation schemes.  Traditional ECDSA generates key pairs by picking a random integer in the relevant finite field (slightly less than 2^256 in the case of secp256k1 ECC) and using that as the private key.  The corresponding Public Key is generated as follows using Elliptic Curve Arithmetic:


Where Q_a is the Public Key, d_a is the Private Key, and G is the Generator for the particular ECC field.  This scheme requires the generation and storage of every private key one wishes to use.  Such a scheme makes backups difficult, requiring the user to create frequent backups to ensure they do not lose any of their private keys as new ones are generated.

In the Titan, a random Base Private Key is generated (using a TRNG) in the usual field, along with a 256-bit Chain Key.  Generation of key pairs occurs like so:


Where d_b is the Base Private Key, Q_b is the Base Public Key, k is the Chain Key, n is a 128-bit Chain Index, d_n is the n'th key pair's private key, and Q_n is the n'th key pair's public key.  The Base Private Key is kept secret and secure on the Titan and never leaves the device unencrypted (it may leave the device in an encrypted backup).  The Base Public Key and Chain Key are shared with any Authorized Clients.  This allows the Authorized Clients to generate up to 2^128 Spendable Public Keys (using the last equation above), allowing Authorized Clients to receive Bitcoins.  However, without access to the Base Private Key, Authorized Clients cannot send Bitcoins and must defer to the secure Titan to do so.

Typically, Authorized Clients will use Chain Indexes starting from 0 and incrementing by 1 for every new Spendable Public Key needed.  This allows the Authorized Clients to re-generate all Spendable Public Keys at a future date using only the data stored on the Titan, and the number of keys to re-generate.  In case of data-loss, a Titan user only needs their Titan device, or a backup of it, to completely recover all their Bitcoins.

The usage of AES in this scheme prevents outside observers who do not have access to the Chain Key from knowing which Public Keys in the blockchain belong to a Titan user.

The only information that needs to be backed up in the typical usage of this scheme is the Base Private Key, and Chain Key.  Everything else can be re-created on demand.  Both of those pieces of data are generated exactly once on the Titan, and so need only be backed up once.  This means that a Titan user does not need to keep making constant backups of their wallet(s).

This scheme, in its typical application, also allows Authorized Clients to generate their own keys on demand without access to the Titan.  This differs from traditional ECDSA key generation in that access to the private key store must be granted every time a new Public Key is needed.

The risk factor with this scheme of key generation is that a malicious party who gains access to the user's Authorized Client compromises that user's privacy/anonymity.  However, this is the case even for traditional key generation.  The benefit of using a secure Titan still applies, preventing the malicious party from spending any of the user's Bitcoins.

Atypical usage allows for this system to be used in numerous other creative ways for enhanced security.  For example, if the user encrypts their Authorized Client, they can help prevent compromise of their privacy/anonymity.  Or, for the ultra paranoid, the Chain Indexes can be generated randomly, instead of deterministicly.  This is equivalent to two-factor authentication, requiring that the user have access to both their Authorized Client and their Titan to spend any money.  The random Chain Indexes may be encrypted as well.  The downside of this atypical usage is that constant backups are again required.  Or, the user may choose to never authorize their Client, and instead depend on the Titan to always generate Spendable Public Keys.  Or any mixture of these methods, along with CSPRNG generation of Chain Indexes, combined with external multi-factor authentication schemes.  Or ... etc.

NOTE: This usage of AES is based on Counter Block Mode ciphering, and as such behaves like a CSPRNG.  This differs from other Chain Code schemes that use a simple hash or other not CS scheme.  It should not make a difference, though; all that truly matters is that an attacker cannot predict the scalars used.  Also note that an IV is not required, since we aren't technically ever reusing the ciphertext.


Transaction Signing
Transaction signing can be one of the biggest weaknesses of systems like the Bitcoin Titan.  It is important to remember that while the Titan itself, and the information stored on it, is secure, the Client talking to the Titan should not be considered secure.  For example, a naive implementation would have the Titan merely receive an arbitrary transaction and sign it.  However, this allows an attacker to intercept the transaction before it reaches the Titan, modify the destination address (or any number of other modifications), and then hand it off to the Titan to be signed.

To prevent these kinds of attacks, it is necessary to display all of the necessary information about a transaction to the user.  To this end, the Titan has strict requirements on the types of transactions that it will sign.  This is to be extended in the future to support more complex and diverse types of transactions, but for the time being only one kind of transaction is supported.  Many input, single output with or without change output.

By restricting the transaction to only a single destination, and possibly a change destination, the Titan can easily display all of the relavant information about the transaction to the user.  The Titan needs only to display the amount of money being sent to the destination, and the address of the destination.  No other information can be manipulated by an attacker in such a way that the user would lose money.

Each input of the transaction is given to the Titan along with the relevant scriptPubKey (from the referenced Outpoint), and Chain Index.  The change output, if it exists, is not given to the Titan as a scriptPubKey, but is instead given as a Chain Index.  This prevents an attacker from specifying their own address as the change address.  By specifying a Chain Index, the Titan can be sure that the change address belongs to the user.

N.B.  Although the key generation scheme used by the Titan, described above, allows for Chain Indexes up to 2^128-1, this presents a risk factor to the user.  An attacker could specify a change Chain Index as some random 128-bit number.  Though the resulting change address would technically belong to the user, it would be impossible for the user to find the corresponding 128-bit chain index.  To prevent this type of attack, the Titan will typically restrict Chain Indexes to 32-bits.  2^32 chain indexes could easily be brute forced if need-be by the user.

The Titan returns a fully signed transaction, which any Bitcoin Client can broadcast to the network.


Backups
Since the data on the Titan may be encrypted, backups (which only need to occur once) can be made directly from the Titan's datastores.


Titan Encryption
The Titan must store on its internal flash the Base Private Key, and Chain Key.  Both are encrypted using either keys derived from the user's passphrase, or using default keys.  Encryption is performed using AES-256, and authenticated with HMAC-SHA256 (Encrypt-then-MAC).  The encryption and authentication keys are derived using PBKDF2-HMAC-SHA256.  It is important to note that generation of the derived keys is performed by first deriving a Master Key using a high iteration count PBKDF2.  The derived keys are then generated from the Master Key.  Creating the derived keys directly from the the user's passphrase reduces the effort required by attackers to crack the keys, and increases the effort required by the Titan to generate the keys.

Cracking the AES encrypted Base Private Key and Chain Key is estimated to be more difficult than usual, since the data being encrypted is completely random.  The only way to verify that an attempt is correct is for the attacker to also have a sample Spendable Public Key generated from that data.  Even then, the attacker must incorporate ECDSA calculations into his brute-forcing attempts, increasing the computational complexity and requiring specialized (and thus not likely optimized) software/hardware.  Attacking the HMAC is more straightforward, and is likely to be the primary target of brute forcing attacks.  Paranoid users who store backups of their encrypted Titan data may choose to discard the HMAC, making brute force attempts more difficult.

A user may choose to encrypt their backups with a second layer of encryption of their choosing, using a different key.

NOTE: The Titan stores TRNG generated salts for the relevant CS functions.


Emulation
If a user finds themselves in a position where all they have is a backup of their Titan, but no Titan to restore the backup to, it is possible to emulate all the behavior of the Titan in software.  Though this is obviously insecure, it could be performed on a cold, air-gaped machine in case of emergency.


Additional Risk Factors
The Titan system is designed to secure the spending of Bitcoins.  It is not designed to aggressively secure the receiving of Bitcoins.  What I mean is that an attacker can install malware on a user's computer that can do any one of a number of things to trick the user into giving out the attacker's receiving addresses instead of the user's own receiving addresses. (Fill the wallet with the attacker's public keys, manipulate the clipboard when copying addresses, etc).  The Titan allows the user to verify and confirm the sending of any Bitcoins, but it doesn't stop these types of receiving attacks.

In the future, the Titan could be enhanced to help fend off these types of attacks.  It could generate and/or display receiving addresses itself, preventing interference by a malicious party, for example.

Starting this thread got me dreaming about this project again. I scraped together a little free time over the past few weekends to make the progress I had wanted to make almost a year ago now! Last year I ordered a 2.4" color TFT touchscreen to replace the dinky little screen I had before, so I wired that up. The whole thing looks a lot cooler now. Check out that shiny Bitcoin logo!





I also ripped up some of the code to replace the original key generation scheme. It's now using a variation of the Chain Code systems. With that modification, my modified Bitcoin Client can generate keys on its own, without having to ask for permission all the time. Though the system is also flexible enough that I don't have to authorize the Client, and can still force it to ask for public keys. Plus, when not used in deterministic mode, it becomes a two-factor authentication scheme requiring not only the information stored on the device, but also the information stored in the Bitcoin Client to spend any money. A bit overkill I think, but the option is there.

And I also put in the framework for encrypting the data stored on the Physical Wallet (now codenamed the Bitcoin Titan).  That way, even if someone physically steals the device it's still completely useless to them without the password.  I designed in AES-256 with HMAC-SHA256-PBKDF2.  Thanks to the touch screen I'll be able to enter the password on the device itself, negating the possibility of digital interception.

Finally, I moved away from coding everything in IAR studio.  I now have a pretty nice dev environment using GCC, GDB, custom Makefiles, and Eclipse CDT when I want to do some visual debugging. If/when I release the code, that should make it easy for anyone to pick up and dig in.

*sigh* Still a lot to do though.

Nope, it's just an STM32F4DISCOVERY plus an LCD module I wired up.  Anyone could built it up with the code and some soldering (or run it without an LCD; less secure though).

That functionality is possible, but wasn't planned for the first revision.  I more envisioned stores accepting it like a credit card; you go to the local dinner, eat their delicious food, and then plug your Physical Bitcoin Wallet into their cash register to pay.  100% secure, 100% easy.

Friend-to-friend would probably be easier handled by interfacing the PBW with your friend's phone over bluetooth or something (if bluetooth were added).  That way your friend can immediately broadcast the transaction that your PBW signed to the Bitcoin network, and not have to worry about you double spending your coins.

If I get the chance, sure.  About the bitcoind interface:  I forked bitcoind off github, and made a set of patches that removed all private key functionality (as well as a few other features that bogged down the code).  Then I added a patch to the transaction signing code that calls out to a separate piece of code that talks to the PBW.  The modifications to the transaction signing code work, but aren't fully tested and aren't thread-safe so they aren't ready for production.

If I recall correctly, I did not use any, or very little of STM's libraries.  The MCU side of the project was split into three pieces: a hand-written crypto library (code named strong-arm), a USB library, and all the rest of the MCU code.  The crypto library is ARM optimized, and implements all of the crypto algorithms (ECDSA, SHA-256, CSRNG, Entropy Source, etc).  I wrote it by hand to ensure that it was performant, didn't use a heap, and didn't have any security bugs (unit tests, too!).  Ensuring that remote-code exploits aren't possible is paramount.

I'll see if any of the code is in a state where it can be slapped on github.  It's forked off a now older version of bitcoind, so I don't know how easy it would be to bring it back up.

Bitcoin Hardware Wallet
Codename: Bitcoin Titan
by: FPGAMiner


Protects Your Bitcoins From Hackers and Thieves

This thread documents the progress on my Hardware Wallet project, code-named the Bitcoin Titan.  The Bitcoin Titan is a USB accessory which connects to a desktop/phone/tablet and safely stores a user's private keys (optionally encrypted).  Even when a hacker compromises your computer, or steals your Titan, the Bitcoins it secures will remain safe.

I have been working on this project off-and-on since May 2012.  As of May 2013, the firmware and software has entered the alpha testing stage; fully functional, but requiring further polish and testing.  The hardware design is undergoing its first revision.




June 25th, 2013: First Board Spin Working

---

The first board spin for this project has been assembled and tested, and is working beautifully.  Previously I was prototyping the Bitcoin Titan using existing development kits and other components.  This moves it to a custom PCB; no more wires sprawling everywhere!


The board itself



With the screen attached and running



In case you're wondering, those pins poking out the top and bottom are only for development and aren't normally attached.

The above picture also shows off part of the UI redesign.  Once the UI redesign is finished I'll release another demo video.



May 16th, 2013: Video Demonstration of Alpha Software

---

Today I am releasing a demonstration video of the Bitcoin Titan, now that the software/firmware is in alpha testing.  I demonstrate how to set up the Titan for the first time, receiving bitcoins, and securely send bitcoins.  Click below to watch!

Click to Watch the Video Demonstration







Original Post:

---

Submitted for your entertainment, one of my old projects back in May '12:

http://www.youtube.com/watch?v=bhWVv7_ecMY

The project is long since dead, since I got too busy to finish it.  Luckily it looks like slush and stick announced a similar project a few months ago (Trezor), so at least the community can finally move past storing private keys on their PCs.

For the curious folks out there, this was built on an STM32F4 Discovery Kit.



EDIT: Project ever so slightly revived:

If anyone has trouble using MPBM's Stratum Work Source with the BitMinter pool, I made the following patch against the latest version of MPBM:
http://pastie.org/6112329

I have the patched code running well with the Stratum sources of Slush, BitMinter, and Ozcoin. On my Raspberry Pi and X6500!

I think I have SHA1 firmware laying around in one state or another. Been too busy to tinker with that sort of stuff.

Hey senseless, thank you for taking the time to maintain this list!