Yeah, Slush and I have been in contact since before Xmas discussing Trezor and MultiBit integration.
There is a fair bit to do to get everything to work, in rough order:
+ finish off the existing MultiBit work and get it out the door to 'clear the decks'.
+ work on the low level 'byte transport layer'. Probably using javahidapi.
+ produce BIP32/ HD wallet code, for eventual inclusion in bitcoinj. I am liaising with Chris Rico on this.
+ The Trezor wallet will be (in MultiBit) watch only so there will be some work there.
+ Probably write a new 'Create Wallet' wizard to improve the user experience.
+ There will also be some UI work (extra tabs etc) I expect too.
I expect the debugging and testing to be a PITA (it's system integration work across Win/ Linux/ Mac on a magically low budget) but that is in the nature of the work.
Any Java devs that fancy pitching in to help out would be most appreciated.
Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 253. (Read 965789 times)
I'm in touch with Jim, we're preparing Raspberry Pi shield for him. RPi shield is wire-compatible with Trezor...
Really cool. Which client are you integrating with first? Electrum? Would you consider MultiBit/bitcoinj as well?
We finally decided to choose name for our hardware wallet. After considering all options from bitcointalk contest and after talking with some marketing specialists, we chose name Trezor.
Landing page trezor.bitcoin.cz points to this thread, but there'll be product presentation soon.
You can also follow Facebook page for more product updates: https://www.facebook.com/BitcoinTrezor
Landing page trezor.bitcoin.cz points to this thread, but there'll be product presentation soon.
You can also follow Facebook page for more product updates: https://www.facebook.com/BitcoinTrezor
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.
let me know if you guys need anything from China.
That is a sweet case. It is CNC'd aluminum, correct? Very nice finish.
Yep. CNC'd aluminium with sandblast finish.
Damn, that's hot.
I'd like to preorder once it's available!!!
I'd like to preorder once it's available!!!
That is a sweet case. It is CNC'd aluminum, correct? Very nice finish.
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...
What design did you go for in the end for the keyring attachment ?
Cannot tell if there is one from the picture.
Cannot tell if there is one from the picture.
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.
It's a beauty !
:-)
:-)
First successfully CNC'ed and assembled casing! We're waiting for elox, but so far it looks very promising.
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.
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.
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.
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.)
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.
Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory.
Perfect, I'll take a look!
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, 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.
Jump to: