Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 260. (Read 965789 times)

Currently there'll be two ways how to initialize the device: Load custom seed into it (over trusted computer) or generate the seed directly into the device (with the seed appearing on the display for backup purposes). I think these choices are the most flexible and easy for initial setup. You don't need to have trusted machine for initialization, but you'll be still able to use custom seed if you really want...


The device will probably have the choice to combine entropy source from it's hardware and from the computer. The worst case (when you'll have hacked machine): The entropy will be as strong as the hardware RNG (which should be still enough for common use) and there won't be a way how to malicious machine can guess the seed . In standard case: You'll have perfect entropy created by combination of hardware generator and your entropy source provided by the computer.

Just keep it simple and support the Electrum format and BIP32.

I expect by the time your hardware wallet is production ready everybody will have implemented BIP32 wallets.

Sweet Project

I plan the support for BIP32, because I think it will be the standard soon. I'm also implementing Electrum's way for deterministic wallet, just because I quite understand Electrum's code and I want to test device with it. I don't fully understand that Armory's wallet algorithm differences, so I'm not yet decided if I'm right now going to support current Armory's wallet.

I'm interested in being compatible with any existing and future bitcoin wallet, including Armory. I'm working on library written in python for interfacing with the device, so implementing it into the Armory should be super trivial. I'm aware of Armory's offline wallets and I think there's almost everything prepared for such type of device.

The reason why I contacted Jim instead of you is because Multibit is written in Java and I need some clarification that he's interested in such kind of device and that there's a way how to talk with this device from Java.


Although "downloading" the seed from the device into the computer won't be possible, there'll be a way how to upload custom seed from attached computer. There won't be any need for special hardware switch on the device, it just displays request if you want to rewrite current seed by that provided by the computer.


Yes, this would be possible (except that hardware switch, as I mentioned above.


Device will handle just the master private key and it will derive every address from it. It won't allow you to handle private keys for custom address. This is limitation which will make the interface much easier.


I don't plan this. Device will just provide master public key to the computer and then it will be just able to sign for addresses derived from this master key.


I wasn't aware of BIP10. I'll read it and maybe I'll have some more questions. I'm also going to support P2SH, but maybe I'll need some help with it...

Allright, got it. I'm not into that stuff much so I don't even know what "thumb" is.

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.

Well, gl.. LM4F120H5QR is very buggy, just read the errata, it has some retarded memory alignment issues.. Almost to trow it away first day when I tried to compile something which was not their example..

PS: In case you are looking for alternatives to ARM, there is PIC32, a cheap MCU based on MIPS. Has some bugs too, not as much as TI lm4f120, and runs at 80Mhz.

PSS: I was looking over microchip product page, and they have this new board based on new low cost family (I think running at 40Mhz):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en555947
Board will be available in November and will cost $109.

Slush showed this to me and I looked at the code. Protocol seems to be very low-level for what we need. But I'll keep your project in mind ...


Please don't get too hooked on LPC13xx thingie. I was experimenting with this platform, because that's what I have pretty good knowledge of. Now we are trying with TI Stellaris Launchpad (LM4F) and this might or might not be the final platform. MCUs evolve too quickly and if there is a better alternative for our usecase and it's not too late to switch we'll use it.

Ah. Ok. Sorry for the noise.

We had this discussion already. Search the past posts of etotheipi, Jan and  ThomasV for the analysis of various problems with these choices.

That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...

I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol-level suggestions related to the hardened crypto devices, not the hardware suggestions.

I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display, 8 touch sensors instead of buttons and various other expansion options for €69 and still within the 128kB limit of the free LPCXpresso IDE:

http://www.embeddedartists.com/products/app/lowpower_oryx

It has everything required to build a secure Bitcoin wallet without a need to solder a single wire. Only programming talent is required.

I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.

sorry for offtopic. http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a/posts/343893

My brother recently got one of these, I've been playing around with it. Don't know if this counts as a "development board", but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:

It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.

Too complex. The real problem here is that most of the Bitcoin software developers are not familiar with the restrictions and challenges of bare metal embedded programming.

The choices of someone42/slush/stick are so great and so beautiful because anyone who tries them will have their first trivial embedded project working on the same evening that the package was delivered.

The real challenge now is not to be super-secure. It to to agree to a common hardware wallet protocol that could be sensibly implemented bare-metal on a simple hardware, not a discared Intel laptop or obsolete Android phone/tablet with their attendant problem of the security of the underlying OS.

At least use a smart card to store secure key while the device is powered off, not the MCU flash. When device is powered on, require some password (add device unique key) and read the secure part from smartcard (or some other secure device).

I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.

The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".

On the other hand the choice displayed here (looks like LPCXpresso LPC1343) and in the similar thread https://bitcointalksearch.org/topic/hardware-bitcoin-wallet-a-minimal-bitcoin-wallet-for-embedded-devices-78614 (mbed LPC11U24) is an excellent starting point for learning and development. It is important to stress that anyone involved in Bitcoin development will be about €30-€60 away from being able to actively test and develop the future Bitcoin wallet device protocol.


I know this forum is full of people capable of programming (or willing to learn programming) therefore I'm going to post some links for the people who may find this project interesting from the purely programmatic side, disregarding for now the actual design of the hardware.

The good starting devices are the two following: mbed LPC11U24 and LPCXpresso LPC1347 (LPCXpresso LPC1343 is now obsolete). The first one comes with an online IDE suite at http://mbed.org/handbook/mbed-Compiler , the second one is supported by a free (as in beer) LPCXpresso IDE http://www.code-red-tech.com/RedSuite5/lpcxpresso-5.php .

Both boards seem to be the designs from http://www.embeddedartists.com/ , they just differ in how they are marketed.

You probably will not be well served by buying the higher end mbed LPC1768 or LPCXpresso LPC1769 boards because they lack the on-chip EEPROM (a.k.a. parallel, byte-erasable NOR flash). You don't want to go into the tribulations of programming NAND flash in your first embedded project.

For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.

Perhaps:
You give them them the hardware wallet and envelope at the same time, telling them to put the envelope in their safe. In the envelope is a sheet of paper with a step by step guide of what to do to recover their bitcoins with their specific mnemonic phrase specified.

They need to trust you though as you might have a copy of the mnemonic phrase somewhere (perhaps intentionally as a backup to them losing their envelope).

Eh, it'd be better to let them keep their own envelope, perhaps in a safe or something. I can just imagine a situation where that "informal IT support" guy's house burns down, along with all of his family/friends' seeds to their funds.

"Gee, that's too bad about your house burning down. By the way, I lost my WhateverItIsCalled, can you help me out?"