No such thing as perfect security anyway. All there is are tradeoffs, you gain a bit of security but you lose convenience, you lose a bit of security but you gain a bit of convenience, finding the right balance for the right kind of circumstance is what is important.

I think this project is badly needed and I wish you success!

How does the owner send funds outside of seed if the device has been stolen?

Maybe instead kickstarter use http://www.bitcoinstarter.com/ ?

I want one immediately.

How about hardening the device against side-channel attacks by organizing a hackaton following the beta release? Could be part of some Bitcoin conference if timing is right.

If it's going to be open-source, I'd like to help with UIX for the device.

Any estimated price?. And, would it be payable in Bitcoins?

Not yet, we're still evaluating final platform and the design of the casing, which can move final price in tens of percents in both direction. And I don't want to give you false promises...


Definitely yes!

Can I preorder please?

First of all, my sincere congratulations for the initiative!


I'm really not a big fan of paper backups. There are so many ways paper could be destroyed/lost, and there's no way to encrypt paper and send it safely to remote backup servers distributed all over the globe. Plus, if you consider an attacker gaining physical access to the device, you should consider him getting physical access to the paper backup too.

I'd strongly suggest an alternative: allow the user to type a passphrase during initialization. Use this passphrase to encrypt the seed and save only the encrypted copy outside the device via USB. Obviously, instruct the user to use a strong passphrase and to back up the file as much as he can.

I realize that I can scan the paper backup, encrypt it and do it myself. But then again, I would need a safe device just for this task...


Cool. These are important features. But honestly, a thief willing to physically steal the device will likely not even bother hacking it, he'll just perform a $5 wrench attack (or variant) and get the money.
The only potential protection I can think of against $5 wrench attacks is plausible deniability (hidden volumes) - and even that will not protect you if the attacker knows how much money you've got.

By the way, "plausible deniability" may also translate to "multiuser". Each wallet user may have a different password (plus a few "fake users" just for the thieves ), which would represent a different hidden volume in the device. This way, a family for example could share the same device, with each family member having its own wallet. I think you should consider implementing this, not only for security reasons, but also for this nice safe multiuser feature.


Me too!


That could be quite cool too! Particularly if you could easily run an OT-server in it. If I understand OT correctly, you may have multiple servers and exchange tokens from different servers, can't you? This way each asset issuer could easily have their own safe servers, even those issuers which are not tech savvy people. But something tells me that you cannot have a server in the device while preserving its strong security constraints... a server would likely need to be upgraded frequently, I suppose. Even still, it'd be safer than using a generic computer.