Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 251. (Read 965789 times)
Not content with:
+ redefining the nature of money, see bitcoinj
+ reimagining the meaning of property rights, see video presentation of Bitcoin London 2012
. . . Mike now goes on to reinvent representative democracy.
Please, for the love of God, can someone stop this guy before he redefines the very essence of reality and/ or space-time and we all become - well - the mind boggles.
:-)
+ redefining the nature of money, see bitcoinj
+ reimagining the meaning of property rights, see video presentation of Bitcoin London 2012
. . . Mike now goes on to reinvent representative democracy.
Please, for the love of God, can someone stop this guy before he redefines the very essence of reality and/ or space-time and we all become - well - the mind boggles.
:-)
yo jim, don't give him ideas!!
. . . Mike now goes on to reinvent representative democracy.
Haha, thanks
Actually that's an old interest. Here's a paper I wrote about 6 years ago:https://docs.google.com/document/d/1jidmNJHWAtsPLCUD7EPPm8jOEV93kSXbZOMycqCWOyA/edit?authkey=CN7BnLUG&authkey=CN7BnLUG
It covers how to use secure hardware to build a new kind of democracy where votes can be delegated by topic up a tree of representatives. I think these days people call it "liquid democracy". I never did anything with the idea. The paper talks about smart cards but Trezor style devices are a better fit.
Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?
Do you have any proposal how this should work? Actually device is able to sign bitcoin transactions (pay to address, pay to script hash) and sign bitcoin messages.
Yes. Consider the case of online voting. The voting server wants to ensure the following
a) The vote is cast by a human, not a virus.
b) The vote is cast by each human only once.
We can satisfy this use case by using Trezor like this:
- Each Trezor has a unique public key (can be RSA) and a certificate signed by the manufacturers, ie, you and stick.
- When you start the voting process, the Trezor sends its certificate to the computer, which then sends it on to the voting server.
- The server checks that this certificate has not been seen before, and then encrypts/signs a protocol buffer that includes a message to display onscreen (any arbitrary text) and the two options available. That signed message gets sent to the Trezor, which shows it on screen.
- The users answer is then signed with the devices private key and uploaded to the voting server which checks it against the public key in the certificate.
In this way, the server can know that no virus interfered with the communication and there is no fake device at work. Of course, it assumes that the devices are somewhat secure against physical tampering.
If you can already sign/verify text messages in the standard way, then I guess you could add it on top of that, though the need to communicate certificates and things makes it not really necessary to re-use something designed only for text.
You don't have to do this now. As the software is open source, somebody could contribute such a protocol and then you incorporate it into your signed builds.
Slush, if you are going to start a political party, remember that I was always your friend. Hopefully my trezors will have low serial numbers.
Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?
Do you have any proposal how this should work? Actually device is able to sign bitcoin transactions (pay to address, pay to script hash) and sign bitcoin messages.
Yes. Consider the case of online voting. The voting server wants to ensure the following
a) The vote is cast by a human, not a virus.
b) The vote is cast by each human only once.
We can satisfy this use case by using Trezor like this:
- Each Trezor has a unique public key (can be RSA) and a certificate signed by the manufacturers, ie, you and stick.
- When you start the voting process, the Trezor sends its certificate to the computer, which then sends it on to the voting server.
- The server checks that this certificate has not been seen before, and then encrypts/signs a protocol buffer that includes a message to display onscreen (any arbitrary text) and the two options available. That signed message gets sent to the Trezor, which shows it on screen.
- The users answer is then signed with the devices private key and uploaded to the voting server which checks it against the public key in the certificate.
In this way, the server can know that no virus interfered with the communication and there is no fake device at work. Of course, it assumes that the devices are somewhat secure against physical tampering.
If you can already sign/verify text messages in the standard way, then I guess you could add it on top of that, though the need to communicate certificates and things makes it not really necessary to re-use something designed only for text.
You don't have to do this now. As the software is open source, somebody could contribute such a protocol and then you incorporate it into your signed builds.
Any idea on what the price for one is looking like at this point?
Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?
Do you have any proposal how this should work? Actually device is able to sign bitcoin transactions (pay to address, pay to script hash) and sign bitcoin messages.
Super excited for this. Any estimates for when you will accept orders?
Maybe 4-6 weeks?
Maybe 4-6 weeks?
It's just colored finish; natural aluminium color will appear on deep scratches. AFAIK there's no technology for producing colored aluminium/duralumin.
Oh, just like those clip things.Neat, this is turning out to be pretty neat
When do we get to see one fully assembled?
Do you have any details on how you'll be selling/producing them? Any idea of cost price?
Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?
Do you have any details on how you'll be selling/producing them? Any idea of cost price?
Have you considered adding support for a generic trusted path protocol so any server can send a message and get back an A/B answer in a secure manner?
missing gold color
elox can be yellow... gold plating (known as TitanNitrid) we can try in future :-) 
It's just colored finish; natural aluminium color will appear on deep scratches. AFAIK there's no technology for producing colored aluminium/duralumin.
elox is pretty hard though - it is used (though thicker admittedly) on industrial fittings to reduce surface wear.
http://en.wikipedia.org/wiki/Anodizing
It's just colored finish; natural aluminium color will appear on deep scratches. AFAIK there's no technology for producing colored aluminium/duralumin.
elox is pretty hard though - it is used (though thicker admittedly) on industrial fittings to reduce surface wear.
It's just colored finish; natural aluminium color will appear on deep scratches. AFAIK there's no technology for producing colored aluminium/duralumin.
Gold color isn't so easy. We're thinking about gold-plated casings, but it's definitely out of current scope :-).
if they are scratched will the color change, or are they the same color the whole way through? (not the gold plated ones I mean) 
So....EPIC!!!!
Gold elox isn't so easy. We're thinking about gold-plated casings, but it's definitely out of current scope :-).
missing gold color
First eloxed (colored) prototypes of casings. Color isn't stable enough so it isn't perfect yet, but we're making a progress!
Jump to: