It is indeed low-level (perhaps a bit too low level). But that's because it's a wire protocol for an embedded device. The need for abstraction is diminished greatly because a lot of the low-level details (eg. transaction format) of Bitcoin aren't likely to change, and if they do, any embedded devices will become incompatible by virtue of their essentially fixed firmware.

Here's a bit of the motivation behind the wire protocol. By separating transfers into type-length-value packets, the device can skip any unrecognised packets. This allows for some extensibility. For example, if a new wallet feature is implemented which requires an extra byte in the "new wallet" packet, old wallets will see this extra byte, skip the entire packet and return "unrecognised command" to the host. The host can then tell the user "your device doesn't support this new feature" and perhaps fall back to not using the new feature.

IMHO, the biggest flaw with the wire protocol I've proposed is that it is quite specific to certain use cases. Thus I'd like your opinion on generalising it. But I'm quite averse to unnecessary abstraction.

There's a reason for this: back when I was looking at dev kits to purchase, the LPC11U3x series hadn't been released yet, though I was aware of their impending release. Fourtunately, the LPC11U3x series are all fully binary and pin-compatible with the LPC11U24. Future prototypes will definitely use a microcontroller with more program memory.

I do see the merit of this, in that it increases interoperability with the existing Bitcoin infrastructure. I've considered allowing a few (maybe 4?) imported private keys per wallet. However, I see this feature to be slightly beyond the scope I had in mind for this project, so it's quite low on my feature priority list.

You're free to use any of the code in https://github.com/someone42/hardware-bitcoin-wallet. It's (mostly) BSD licensed. My current prototype uses the NXP LPC11U24 microcontroller; I believe it is very similar to the chips in the LPC134x series. Thus there could be some useful stuff in the lpc11uxx/ directory.

It would be a good idea to agree on a common wire protocol, for the sake of Bitcoin client developers. My current wire protocol is documented here: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL. There are some example packets (.bin files you can send over a serial link) in https://github.com/someone42/hardware-bitcoin-wallet/tree/master/avr/tester. What do you think?

I have just completed an improved prototype.

Here is a picture of that prototype. An Australian 20 cent coin (comparable in size to the US half dollar) is shown for scale. It is signing the same transaction as in the OP.


The firmware has received substantial improvements. Here is a summary of current features:

• Wallet encryption. Wallets are encrypted using AES-128 in XTS mode. Encryption is optional.
• All potentially dangerous operations (eg. formatting storage) require user confirmation.
• When signing a transaction, all output addresses and amounts are displayed, as well as the transaction fee.
  
• The transaction parser supports P2SH addresses.
• Deterministic wallets. All addresses are generated from a random seed, so that once a backup is done, no further backups are necessary.
• Wallet backup/restore. A wallet's deterministic seed can be displayed on-screen, giving the user the opportunity to write it down. Wallet backups can be (but don't have to be) encrypted.
• Multiple wallets. A single device can hold many wallets. Each of these wallets are independent - they can have different addresses and different encryption keys.
• Hidden (plausibly deniable) wallets. Erased wallets consist of random data. Since encrypted data is statistically indistinguishable from random data, (theoretically) the existence of a hidden wallet cannot be confirmed without the correct encryption key.
• Secure formatting. Formatting a device does a multipass, low-level (i.e. bypasses any wear levelling) overwrite with random data.
• Dedicated hardware entropy source. A thermal noise source is sampled to collect entropy. The source is continually tested for signs of failure and interference. A persistent entropy pool mitigates the impact of more subtle failures

Here is the current prototype doing a wallet backup:

Note that the entire seed is displayed over three such screens; only the first one is shown.

These are some features that I would like to implement for the future:

• BIP0032-compatible deterministic wallets.
• Resilience to sudden power-off events. In other words, data corruption should be avoided if power is suddenly removed at any time. This is necessary because the wallet is USB powered.
• P2SH address generation. This will enable some secure multisig use cases, such as the secure reception of funds.
• Software ("bit banged") low-speed USB host for USB keyboard input. This will enable the input of wallet encryption keys in a way which bypasses software keyloggers.
• Firmware updating. I intend to allow this only simultaneous with the erasure of all wallets. That way, firmware updates cannot be used to extract the contents of a wallet, and the firmware update feature cannot be used to install a backdoor without the user noticing (provided the user creates their wallets on a clean device).

Some additional statistics:

• Firmware binary size: 22.9 kilobytes.
• Required RAM: 8 kilobytes.
• Required non-volatile memory per wallet: 160 bytes. The included 4 kilobyte EEPROM fits about 23 wallets.
• Microcontroller: NXP LPC11U24, a 32-bit ARM Cortex-M0 microcontroller running at 48 Mhz.
• Display: SSD1306-based OLED display, with a resolution of 128x64. That's enough to display 4 lines of 16 characters.

Firmware source is available from https://github.com/someone42/hardware-bitcoin-wallet. A schematic of the circuit in the top picture is available from https://github.com/someone42/hardware-bitcoin-wallet/blob/master/lpc11uxx/hardware/hwrng.jpg.

I have teamed up with someone else (allten on this forum) who is doing hardware development. This means that the next prototype will probably be much cleaner and more robust.

The requirements and use case you listed are basically what I had in mind for this project. However, I have no experience with production-grade hardware, only "once-off" hardware. I would also like to see this project become a real product, but I have no experience with marketing, distribution, compliance testing, supply chain management etc. By myself, I can probably get this project to a stage where I have a working, fully-assembled prototype in my hands, but to actually make a product, I would need to team up with someone/some people.

As for costs, the wallet is simple hardware-wise, so it's quite cheap. I originally estimated the parts + assembly cost at 6 to 7 USD per device (for quantity = 1000), but after some revisions, I think "somewhere in the vicinity of 10 USD" is more accurate. I haven't thought about fundraising, because so far I haven't had any need for funds specific to this project (all the stuff I've bought can be used for future projects).

Anyway, I'm glad to see that people are interested in this project. I do hope to get to a working, assembled prototype by the end of this year.

I do intend to add support for m-of-n signatures some time in the future. Currently, I'm working on porting the code to better hardware. I'm also writing code to do online testing of the hardware noise source, so that its failure can be detected. The project's github page (https://github.com/someone42/hardware-bitcoin-wallet) should have the latest development status.

As for integration with existing wallets, I like BIP 0032 (see https://en.bitcoin.it/wiki/BIP_0032) and will probably implement a BIP 0032-compatible deterministic wallet. IIRC, the authors of various Bitcoin clients have expressed interest in BIP 0032, so in the future you may be able to import and export wallets between this device and those clients.

Since the device doesn't do any blockchain management, it needs another client to act as a "host" and give it transactions to sign. I haven't contacted any developers of other clients about adding support for this wallet device yet, since its host communication interface is not mature - I haven't even decided which USB device class the wallet will implement.

You've given me an idea on how to analyse the fixed-function case. You're better than me at this stuff, so correct me if I'm wrong.

Represent every element as a vertex in a graph. Then, add directed edges between vertices according to how SHA-256 maps elements onto other elements. The final set of cycle elements is all the stuff that is part of a cycle. The question is, how big is this set? I attempted a rough estimate, and was surprised at what I got.

The graph can be constructed by building chains/cycles. To begin, pick an element, run it through the random oracle, then add a directed edge between input and output. Then pick the output element, run it through the same random oracle ... etc. This builds up the first chain, and eventually this chain will loop back on itself, creating a cycle. How big is this cycle? Let N be the number of elements. After adding 1 edge, the probability that the chain will loop back on itself is 1 / N. After adding k edges, the probability that the chain will loop back on itself is k / N. Thus the probability that the first chain has k edges with no cycles is: This can be approximated as (1 - k / (2N)) ^ k (as long as k is much smaller than N), and then approximated again as exp(-k ^ 2 / (2N)). Equating this to 0.5 reveals that the first chain, on average, has a length of roughly sqrt(N).

The rest of the graph can be constructed by picking an unconnected vertex and running it through the random oracle, building another chain. However, this time, the chain either loops back on itself (creating another cycle) or merges with a previous chain. Very roughly, the second chain has a 1/2 chance of creating another cycle and a 1/2 chance of merging with the first chain (because, its average length should be similar to the first chain's average length). Likewise, the ith chain has a 1/i chance of creating another cycle and a (i - 1)/i chance of merging with any one of the previous (i - 1) chains. The average number of cycles is then 1 + 1/2 + 1/3 + 1/4 + ...; the harmonic series. Even for 2 ^ 128 terms, this is only about 100.

My estimate for the size of the final set is: average cycle length * average number of cycles, and is very roughly, 100 * sqrt(N). For SHA-256, this is about 2 ^ 135. That's much lower than I expected! But to get to this, you probably have to go through an insane (like 2 ^ 128) number of rounds.

I thought it would be interesting to see what the entropy reduction is for multiple rounds. I assumed each round has its own independent random oracle which maps k * N elements to N potential output elements, where 0 <= k <= 1 and N is 2 ^ 256. For each round, I found that on average, exp(-k) * N output elements have no preimage. Therefore, each round maps k * N elements to (1 - exp(-k)) * N elements.

Iterating this, the entropy reduction (ignoring the non-uniform output distribution for now) is:

Round	Cumulative entropy reduction
1	0.6617
2	1.0938
4	1.6800
8	2.4032
16	3.2306
32	4.1285
64	5.0704
128	6.0381
256	7.0204

I don't observe any convergence, and indeed the equation k = 1 - exp(-k) has one solution: at k = 0. But this is probably because I assumed that each round had its own independent random oracle. The results may be different for a fixed function like SHA-256.

An update on features: I've added support for multiple wallets and hidden (plausibly deniable) wallets. 2 KB of EEPROM should be able to store 10 wallets; 4 KB of EEPROM should be able to store 23 wallets. The LPC11U24 comes in 2 KB and 4 KB variants.


I did intentionally choose a permissive licence because I wanted other people to be able to reuse portions of my code with few restrictions. I don't think someone else will release a closed-source wallet since the Bitcoin community isn't going to accept the whole "trust me, there isn't a backdoor in this binary" thing. Maybe the hardware should be licensed under a more permissive licence (than TAPR) to match the firmware?

Looking at TI's datasheet (http://www.ti.com/lit/ds/symlink/tl431a.pdf), I see a "+" instead of a "-" on page 19. Am I missing something? But if dynamic impedance is a problem, what if we used an extra PNP transistor (like on Figure 21 of the datasheet) as the shunt? If I understand the circuit correctly, the transistor amplifies current changes from the TL431, theoretically decreasing dynamic impedance by the current gain h_FE of the transistor. That would result in an insanely low dynamic impedance, though there are probably stability problems involved with putting an amplifier in the TL431's control loop. As an additional bonus, it would further decrease the thermal effects you mention.



How about "CoinKey" or "BitKey"? Both are google-able, and both have .org domain names available. "CoinKey" also suggests that the wallet can be used with an alternative cryptocurrency such as Namecoin, since it (presumably) also uses ECDSA for coin transfer.



Those ARM processors with NEON are in a much more powerful (and much more expensive) class than the Cortex-M0 microcontrollers I'm looking at using. I think what you're suggesting is to use SIMD to detect fault analysis, since any injected faults will affect the benchmark problem. But I'm not that worried about fault analysis, because the attack model I have in my head is that of a remotely compromised host computer. This means that timing attacks and power analysis attacks are an issue, because a typical computer has the ability to measure time and power consumption. But I can't think of any way a typical computer could inject faults into a USB device, especially if that device has its own clock and filters its power supply.



I should probably say this now: the idea for a hardware Bitcoin wallet isn't mine, nor are the core ideas (like the use of a deterministic wallet). This sort of thing has been suggested multiple times on this forum. I was expecting someone to beat me to an actual implementation, and was surprised when it didn't happen.

Unfourtunately, it's too similar to "myki" (http://www.myki.com.au/), a public transport smartcard used in Australia.



I chose the BSD "2-clause" licence because it was one of the most permissive licences accepted by the Open Source Initiative. I believe it exactly the same in spirit to the MIT/expat licence (maybe I should use that?). If software patents are a problem, why not use the Apache License v2.0? It's compatible with GPL-3 (http://www.gnu.org/licenses/license-list.html#apache2), so there would be less re-use problems.

I was looking at the LPC11U24, which seems quite widely available (there are also easy-to-use dev kits out there eg. http://www.sparkfun.com/products/11045). Though it only has 32KB of program memory, I've found that Cortex-M0 code is much smaller than AVR 8-bit. For example, the platform-independent portion of hardware Bitcoin wallet compiles to 22.8KB on AVR 8-bit, but compiles to only 11.5 KB on Cortex-M0 (using the yagarto toolchain).

As for RAM requirements, anything greater than 2 KB is probably enough. Currently, I've calculated maximum RAM usage to be ~1.5 KB.

Is there any reason why the dirt-cheap TL431 couldn't be used? Looking at datasheets, the TL431s from various manufacturers have a typical output impedance of between 100 and 300 mohm. And they're cheaper than a 3.3V LDO which I was going to have to use anyway.

I've finally implemented the persistent entropy pool. It was more work than I thought because the persistent entropy pool doesn't play nice when trying to format non-volatile storage - if the entropy pool is stored in non-volatile storage, it gets mangled in the process, so I've added a way to temporarily store it in RAM.

Nope. It's something which is dependent on which microcontroller we choose, so measurements should probably be done after a choice is made.

With hardware, I consider myself merely a hobbyist. I have designed and built many circuits in the past, but I've never designed anything which was "mass-produced". That's another reason why I wanted to keep things simple; I don't think I could design something with exotic features like self-destruct on tamper detection. It was always my intent to open-source everything, so TAPR looks good.

I have thought a lot about the requirements and it's quite clear that the ATmega328 isn't going to cut it. Even now, I'm close to running out of program flash. Having a look around, I reckon the LPC11Uxx series from NXP (see http://www.nxp.com/products/microcontrollers/cortex_m0/lpc11u00/) is appropriate: low power, low cost, integrated USB, integrated EEPROM and good development tools. What do you think?

I thought of another way to mask power signatures. With some transistors and a large-ish (> 100 uF) capacitor, a device can temporarily disconnect its own USB power line. It can then operate in two phases:

• A discharging phase, where the device does cryptographic operations while USB power is disconnected, using the capacitor as a temporary power supply
• and a charging phase, where the device sleeps while USB power charges the capacitor.

For example, if the microcontroller/regulator can tolerate a 1 volt drop and current consumption is 15 milliamp, then a 100 uF capacitor allows the discharging phase to be about ~7 ms. If the capacitor can tolerate a current of 100 milliamp, then the charging phase is only 1 ms. This results in a small (13%) reduction in overall performance, but I don't think anyone will care if a signing operation takes 1.1 second instead of 1.0 second.

This method can be applied to any cryptographic algorithm. An attacker can still measure power consumption, but they can only measure the average power consumption over each discharging phase. For a 7 ms discharging phase, this equates to 100,000s of clock cycles. There's probably not a lot of useful information in that. If more masking is required, the microcontroller can dissipate some power in a resistor, either to compensate for the power consumption of its ALU, or to inject some noise into an attacker's measurements.

I'm bad at naming things. I chose "hardware Bitcoin wallet" as a working title because it's direct. At one time I thought "Solidcoin" (solid: it's a solid device you can physically hold in your hand, coin: from Bitcoin) would be a good name, but that name's already taken. If you or anyone else can come up with a good name, I'll adopt it.

If I understand your patch correctly, you are adding a persistent (across power cycles) entropy pool so that in the event of an undetected HWRNG failure, getRandom256() will degrade gracefully instead of immediately giving crappy random numbers.

This is a good idea, but you're using the encrypted read/write functions to do save/restore the pool state. I understand this is to ensure that the pool state is secret. But it is a problem because the encryption key the encrypted read/write functions use depends on which wallet is loaded. In some cases (eg. formatting non-volatile storage), random numbers are required when a wallet isn't even loaded (i.e. no encryption key is set).

The most general and secure fix I could think of for this is to define a "global" wallet encryption key, which exists solely to encrypt the pool state and its checksum. Actually, now that I think about it, the global wallet encryption key can also be used to encrypt the wallet names/versions. But this will require some significant changes elsewhere in the codebase. I will fully incorporate your suggestions, but only after I add support for multiple wallets.

I won't really know until I choose a display and layout a PCB, but I estimate a final version will have a size of about 1.5x the length/width/height of a typical USB stick.


If you do choose to use the code, keep in mind that:

• bigMultiplyVariableSizeNoModulo() is horribly slow. If you are going to hand-optimise or reimplement one function, choose this.
• The "constant execution time" property of the algorithms may not carry over to a contemporary CPU because of caches and branch prediction. I don't have to worry about caching/branch prediction because none of the microcontrollers I'm looking at have these features.

The way my current implementation achieves constant time operation is to insert dummy operations instead of using branches. I believe this is like the "wait until maximum-time, while doing something cpu-intensive" approach, except that the waiting is interleaved instead of happening all at the end. However, it has the advantage that program flow is independent of secret data, so it also hides most (but not all) of the power consumption signature.

I had previously assumed that power analysis using a computer motherboard wouldn't be feasible for a hardware Bitcoin wallet. I assumed this because usually fast ADCs (at least the clock rate of the microcontroller) are required to do power analysis, and I doubt motherboards have 48 Msps ADCs in them. However, your comments have prompted me to question this. A point multiplication operation involves 256 point addition and point doubling operations which take place over some time (0.5 s to 4 s depending on the speed/power of the microcontroller). Sampling over each point addition/doubling would only require a < 1 ksps ADC and could possibly reveal information about secret data. Although I still think a power analysis virus is a bit exotic, it would be prudent to design some power analysis countermeasures into a hardware Bitcoin wallet.

About the hardware design: yes, I'd really appreciate help. Software mistakes can be fixed with a commit; hardware mistakes can require expensive redesign or rework.

Yeah, using simulation of a simple zener regulator circuit, I couldn't get better than a factor of ~3 reduction in power consumption signature.

I think a mostly software solution is possible. A relatively large (compared to what's possible on a smartcard) amount of passive filtering can be used to mask high-frequency power consumption signatures (with a cutoff in the 10s of kHz).

Say, for example, an addition: x + y requires i + d_i milliamp of current over one clock cycle, but the addition of ~x + ~y requires i - d_i milliamp of current over one clock cycle. As long as every necessary addition x + y is paired with a dummy addition ~x + ~y, total current consumption is always i milliamp of current over two clock cycles. Since the core clock of microcontrollers is in the Mhz range, the cycle-to-cycle variations in power consumption are not visible to an attacker; thanks to the filtering, only power consumption over hundreds of cycles is visible. The challenge is then to "pair" every necessary operation with a dummy operation that quickly compensates for the power comsumption of the necessary operation.



After seeing this: https://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html, I believe it is possible to bit-bang a USB host interface. So I will probably include a USB port on the wallet, for you to plug a USB keyboard into.

Writing to a USB key would require the wallet be capable of being a USB host, as opposed to merely being a USB device. Being a USB host requires far more processing resources than being a USB device. IMO, it just isn't worth the extra complexity and cost. An easier alternative to manually writing down the seed would be to take pictures of the display.
Hidden wallets are a feature I plan to add. I intentionally made the "format storage" command write random data everywhere (instead of all 00s) for this reason.



Good point. Currently, the wallet doesn't ever display or parse the wallet name (the wallet name is just there for the convenience of the host), so adding this feature requires no additional code.
Just like with transaction signing, all powerful commands require approval from the user. I haven't done this with the "change encryption key" command yet because I'm still figuring out how to deal with ransom attacks.

One major problem I've identified with the hardware Bitcoin wallet is that since its input user interface consists solely of two pushbuttons, there's no way to get a wallet password into it. Currently, the host is supposed to provide an encryption key derived from a password, and this is bad because:
1. The user must type the password using the host's keyboard and the host may have a keylogger.
2. The host may have an advanced trojan which covertly mixes a "ransom key" into the encryption key, lets you load BTC into a wallet, then holds those BTC for ransom.

How can these flaws be dealt with? Here are the ideas I've come up with:

• Keep things the way they are. Rely on the assumption that even if an attacker has your wallet password, they probably won't have physical access to your hardware Bitcoin wallet, so they still can't do anything nasty. Rely on wallet backups to mitigate ransom attacks.
• Change the protocol so that the wallet password is sent in cleartext over the serial port. Then, the wallet has the opportunity (when setting or changing the wallet password) to display the password, allowing the user to detect if a "ransom key" has been inserted.
• Add a USB port to the hardware Bitcoin wallet and allow the user to plug a USB keyboard into the wallet and directly enter the wallet password.

I like the last option the most, but it does involve additional cost (+0.20 to 0.40 USD for quantity = 1000) and complexity*. Also, since the key derivation function is evaluated on the hardware Bitcoin wallet, it can't be as strong, since the microcontroller on the device will be orders of magnitude less powerful than a modern CPU or GPU.

Can anyone think of a better way to deal with ransom attacks?



It would be nice to have tamper proof features and there are microcontrollers out there which have such features. But the semiconductor manufacturers all seem to require the signing of an NDA (that goes against my goal of openness) and probably won't bother talking to me unless I commit to an order of at least 10,000 units. I figure it's not such a big deal: Bitcoins are transferrable. If your wallet is compromised or stolen, you create a new one and use a wallet backup to transfer everything to the new wallet.



It may be possible to verify signed Bitcoin addresses on a hardware Bitcoin wallet, as long as the signatures are generated using ECDSA (and preferably using the curve secp256k1). Most of the code needed to verify a signature is already implemented, because signature verification is similar to signature generation. Also, ECDSA public keys are only 64 bytes each, so there will probably be enough spare space to fit a couple in a firmware binary. Nevertheless, I don't think I'll implement this feature in the near future.

*There's a bit of a cheat I can use here. As I mentioned above, being a USB host is difficult. But most (maybe all?) USB keyboards are also PS/2 keyboards: those USB-to-PS/2 dongles they come with simply re-route the USB pins to PS/2 pins. The keyboard uses some electrical checks to determine whether it is plugged into an actual USB port or a USB-to-PS/2 dongle. Thus it's possible to trick a USB keyboard into using the PS/2 interface, and the PS/2 interface is much easier to work with than the USB interface.

The problem is probably originating from one of the calls to bcmod(). I don't know how php's bignum library does it, but modulus functions in any language can produce unexpected results when one of the operands is negative. You could workaround this by adding $m to $a (if $a is negative) in modinv().

Yeah, well you can in principle...though in practice wallet backups/restores aren't implemented yet. I shall implement this soon.


Serial parameters are: baud rate 57600, 8 data bits, no parity, 1 stop bit. The host and wallet exchange "packets", which are type-length-value triplets. For all the packet types, see: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL. It's almost the simplest protocol I could think of that is still somewhat extensible.

Edit: Please see https://bitcointalk.org/index.php?topic=78614.msg1327630#msg1327630 for an updated prototype.

Hardware Bitcoin wallet is a project which aims to implement a minimal dedicated Bitcoin wallet. Its main difference with every other Bitcoin client/wallet out there is its low resource requirements: the binary is currently 25 kilobytes large, it uses less than 2 kilobytes of RAM and requires only 160 bytes of non-volatile storage per wallet. With such low requirements, I reckon a production device would be smaller, more robust and cheaper than any other Bitcoin wallet.

The wallet stores private keys (actually, it only stores a seed for the deterministic key generator), parses transactions and signs transactions. It essentially doesn't do anything else. This is by design - simpler means a smaller attack surface. Private keys are generated on the device and never leave the device, except when doing a wallet backup. Even then, the seed is only displayed - it is never sent over the serial port. My intention is that physical access to a device is required in order to obtain private keys or to spend anything. As an additional layer of security, wallets can be encrypted. An encrypted wallet offers pseudo-two-factor authentication: in order to spend BTC, you need to know the wallet passphrase and you need to have the hardware Bitcoin wallet.

Here's a somewhat messy prototype:

The thing on the left is an Arduino clone (though I'm not actually using the Arduino IDE or libraries). The bunch of discretes on the lower part of the breadboard comprise a noise source, which is used to generate random numbers. The input user interface consists of two pushbuttons (bottom-left and bottom-right corners), where the user can approve or disapprove of actions. This gives you an idea of the necessary hardware peripherals required. Of course, a production device would be much more compact than this .


Here's the prototype signing a transaction:

Here's an actual transaction that it signed: http://blockexplorer.com/t/AEhoN6bzjd.

The code is hosted at: https://github.com/someone42/hardware-bitcoin-wallet. Currently, there's only a port for the ATmega328 microcontroller. However, most of the code is platform-independent; porting to another microcontroller "only" involves writing drivers for the microcontroller's peripherals.

I shall commit to being open and transparent, releasing source code and hardware specifications as I produce them. If people are interested, I might even design a production hardware Bitcoin wallet. From simple BOM and assembly cost estimates, such a device would cost 6 to 7 USD per unit to manufacture (for a quantity of 1000). If anyone has questions/suggestions, feel free to ask in this thread.

Hi,

I have lurked here (while not logged in) for many months now. I'd like to announce and discuss an open-source embedded BitCoin wallet which I have developed (see https://github.com/someone42/hardware-bitcoin-wallet ). I don't think that the newbie area is the best place to post about this.