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

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.

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.

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

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).

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

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).


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.

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.

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.

This increases internal storage required but reduces the need to send lots and lots of transactions to the device each time.

Ok ill get on it

Edit- what do you think now

no colors, sorry. just monochromatic black/white bitmaps. :-/

Because I made it too small at first, does the screen support colors? I can work on it some more and maybe make the pig on a beach or something nice

wow, nice. but why do you use 2x2 square pixels to draw the pig? :-)

quick splashscreen for the little device if you want

Sounds awesome, keep it up!

We're actively working on the project and we're making progress on many details. You know, there's no linear progress. Every piece must be finished independently, then integrated to the final solution somehow. At this stage many pieces already work. It requires some patience to put them all together and then *bang* - we're done :-).

I'm working on RPi software prototype, Stick is preparing circuit and PCBs for custom device, Lionluck is preparing casing prototypes and optimizes them for mass production (next prototypes will be finally made from eloxed duralumin/aluminium, not from plastics ).

Our original deadline was to have working prototype on RPi in December, which was somehow fulfilled - I already signed transaction with deterministic wallet over protobuf/serial connection and broadcasted it to bitcoin network. Then I disassembled it again because I found better solution for transaction streaming. I also heavily refactored original code, to be more similar to MCU environment (single threaded, non blocking code in master loop). It also interfaces HW buttons and OLED display with fancy UI (if we can call "fancy" anything on 128x64 px viewport ).

So there's progress, but it is all under the hood. At this stage there's nothing breath-taking to show publicly, but nevermind - that time will come :-).

Any updates slush? Sorry for being impatient but I'm really eager to see this being finished and sold to end users

ripper234, World, thanks for links, lot of useful information inside.

I like that "innovation adds value." This isn't just some gimmick. Bitcoin provides safety and security to carry your money anywhere without threat of theft. Personally, I would like to see some device like this for children to safely carry money they need.

maybe on the Hardware wallet 2.0 
interesting video have look time 16:30 Digital Money - Panel Discussion

Interesting.

From the "a few non-obvious things you want to keep in mind when launching a crowdtesting project" section on that page:

Slush/everyone,

I haven't been following the thread, but I suggest you take a look at this 5 minute video about "Crowdtesting" (a cross between Kickstarter and A/B testing) - it might fit the bill.