[ESHOP launched] Trezor: Bitcoin hardware wallet

[slush]

There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.

Device stores variable of highest acceptable fee per kB, so transaction with higher fee will be rejected. This will have some reasonable amount pre-setted from factory, but there'll be an API to change it's value if bitcoin fees become bigger than this limit (of course the change will show warning message on the display and will ask for confirmation by hw buttons).

Does the device have any internal storage? What you could do is integrate the block chain sync process with talking to the device. As relevant transactions are discovered they are sent to the device which strips out the values of the outputs and stores them in its internal storage alongside the tx hash. Once all tx outputs have been spent the data can be deleted.

Unfortunately device won't have enough memory to store tx hashes and some other metadata. We're designing the device to have no arbitrary limits for transaction amounts and sizes.

However we're planning to do SPV validation of tx inputs (and storing fixed amounts of checkpoints in the device to speedup the process for next time), so maybe we can somehow use fees from these transactions to approximate this maximum acceptable fee for the future. Thanks for the idea, I'll think about it a bit more.

[caveden]

There was a quick discussion on IRC about how to handle the case where malicious software sends a super high fee transaction to the device for signing and then uses the fees to steal the money. The difficulty of verifying the fee without having the host send all depended-upon transactions was mentioned.

Device stores variable of highest acceptable fee per kB, so transaction with higher fee will be rejected. This will have some reasonable amount pre-setted from factory, but there'll be an API to change it's value if bitcoin fees become bigger than this limit (of course the change will show warning message on the display and will ask for confirmation by hw buttons).

I'm not sure I understand the issue here. Can't the device simply show both amounts (output + fee), and the user confirms that?

[stick]

I'm not sure I understand the issue here. Can't the device simply show both amounts (output + fee), and the user confirms that?

To calculate the fee you need to know all of the inputs and their balances, because a fee is not stored in transactions, it is just sum(inputs) - sum(outputs).

[chrisrico]

Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?

[etotheipi]

Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?

Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.  It's only the crypto part -- I haven't been able to integrate it into a new wallet format yet (and thus, not usable in Armory yet).  But it includes the ChildKeyDeriv() source code, and a unit test for both HMAC-SHA512 and the ChildKeyDeriv().

The unit tests may not be entirely accurate, because I made them before sipa decided that all derivations should use compressed public keys.  But the algorithm is otherwise 98% what is described in the BIP.

[chrisrico]

Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?

Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.  It's only the crypto part -- I haven't been able to integrate it into a new wallet format yet (and thus, not usable in Armory yet).  But it includes the ChildKeyDeriv() source code, and a unit test for both HMAC-SHA512 and the ChildKeyDeriv().

The unit tests may not be entirely accurate, because I made them before sipa decided that all derivations should use compressed public keys.  But the algorithm is otherwise 98% what is described in the BIP.

Awesome. I was thinking of implementing BIP32 in BitcoinJ mostly as an exercise for myself but also because I have some use for it in mind. I'll take a look at the newwallet branch.

[slush]

Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.

Perfect, I'll take a look!

[etotheipi]

Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.

Perfect, I'll take a look!

CAVEAT:  BIP 32 is not final yet!

Sipa created some test vectors for latest BIP 32 revision, and I was able to match them in my code.  He's waiting for a response from a real cryptographer before he finalizes it, but at least we've ironed out the intention for BIP 32 and matched our test implementations.  I'm posting here just so anyone else that wants to get a headstart on it can see my unit-tested code, and the test vectors that sipa supplied.  Just don't go implementing this into production software yet!

Here is the unit-test itself, with hard-coded public keys to compare against.
Here is the implementation of ConvertSeedToMasterKey() function, and the ChildKeyDeriv() function implemented in the Armory C++ utilities, matching the latest revision of BIP 32 (as of Dec 22, 2012).

And Here is the output of my test.  It is the same chain displayed twice, all the way up to M/0/1/3/7/15/31/63/127/255/511/1023/2047/4095/8191/16383/32767.  One chain is derived strictly from private keys, the other derived strictly from public keys.  Anyone using this for their own test only needs to look at the first half.

[mazi]

Sipa created some test vectors for latest BIP 32 revision, and I was able to match them in my code.  He's waiting for a response from a real cryptographer before he finalizes it, but at least we've ironed out the intention for BIP 32 and matched our test implementations.  I'm posting here just so anyone else that wants to get a headstart on it can see my unit-tested code, and the test vectors that sipa supplied.  Just don't go implementing this into production software yet!

Here is the unit-test itself, with hard-coded public keys to compare against.
Here is the implementation of ConvertSeedToMasterKey() function, and the ChildKeyDeriv() function implemented in the Armory C++ utilities, matching the latest revision of BIP 32 (as of Dec 22, 2012).

And Here is the output of my test.  It is the same chain displayed twice, all the way up to M/0/1/3/7/15/31/63/127/255/511/1023/2047/4095/8191/16383/32767.  One chain is derived strictly from private keys, the other derived strictly from public keys.  Anyone using this for their own test only needs to look at the first half.

I've re-implemented Seed-to-Master-Key and Child Key Derivation functions, and Armory's test for these, in Java. The code is here (in a bitcoinj fork):
http://code.google.com/r/matijamazi-bitcoinj/source/browse/?name=hdw#git%2Fcore%2Fsrc%2Fmain%2Fjava%2Fcom%2Fgoogle%2Fbitcoin%2Fhdw
And the unit tests:
http://code.google.com/r/matijamazi-bitcoinj/source/browse/?name=hdw#git%2Fcore%2Fsrc%2Ftest%2Fjava%2Fcom%2Fgoogle%2Fbitcoin%2Fhdw

This is all very crude and messy at the moment (just the first version where the tests passed), I'll get in shape soon.

Any comments welcome.

BTW, I couldn't find where sipa originally posted the test vectors; is this somewhere public? (I took the test vectors from the Armory code.)

[etotheipi]

BTW, I couldn't find where sipa originally posted the test vectors; is this somewhere public? (I took the test vectors from the Armory code.)

Sipa didn't want to release them yet until BIP 32 was final.  But after I setup and passed the test vectors, I asked if I could post the code, and he gave approval as long as there was a bold caveat (which I have at the top of that post).

I don't know how long it will be before it's final, so don't get too attached yet (or create production code with it).  It's being reviewed by a real cryptographer, and should be final afterwards, barring any issues with it.

P.S. -- The first CKD test was actually my own test that I came up with before Sipa even had his own implementation.  I meant to remove it, because sipa later came up with his own test vectors and made that previous test kind of pointless.  The outputs that *are* verified are the 17 public keys and the chain of pow(2,i)-1 children.

[mazi]

I don't know how long it will be before it's final, so don't get too attached yet (or create production code with it).  It's being reviewed by a real cryptographer, and should be final afterwards, barring any issues with it.

Sure, I wrote this code mainly to see if I understand the BIP 32 correctly, and if can use a little of bitcoinj and ECC in Java.

I won't be surprised if BIP 32 is changed/updated; I'm not a cryptographer but thanke's suggestions and comments in https://bitcointalk.org/index.php?topic=19137.80 make a lot of sense to me.

[slush]

First successfully CNC'ed and assembled casing! We're waiting for elox, but so far it looks very promising.

[jim618]

It's a beauty !

:-)

[hazek]

Can't wait for this. This is the missing bit in the Bitcoin puzzle for making it useful to the mainstream: ease of use coupled with impenetrable online security.

[jim618]

What design did you go for in the end for the keyring attachment ?

Cannot tell if there is one from the picture.

[slush]

Cannot tell if there is one from the picture.

Heh, now I see the eyelet is hidden behind the casing body. I'll upload next photos soon so eyelet will be visible as well...

[paybitcoin]

That is a sweet case. It is CNC'd aluminum, correct? Very nice finish.

[DPony13]

Damn, that's hot.

I'd like to preorder once it's available!!!

[stick]

That is a sweet case. It is CNC'd aluminum, correct? Very nice finish.

Yep. CNC'd aluminium with sandblast finish.

[BitSyncom]

Glad someone else has also taken up the hardware route for Bitcoin development and ultimately the road to adoption.

let me know if you guys need anything from China.