I see you have custom holograms on you Kanban board . . .
Are they decorative ?
Do they go on the back ?
Not much free space on the front.
Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 249. (Read 965789 times)
How did you get 12k bitcoins on picture of the first prototype if your address http://blockchain.info/fb/1brmla had never had such btc amount 
pure magic (or rather a secret wish) :-)
How did you get 12k bitcoins on picture of the first prototype if your address http://blockchain.info/fb/1brmla had never had such btc amount
Quote
PS: Your donation haven't arrived yet :-/
Yeah some problems with multibit, should be arriving soon now from 1J...u5
nice to see that your adress has a link in blockchain.info "hardware wallet
"Will check out the site!
Awesome!
No, this is not a Solitaire Game, but our planning Kanban board (powered by mighty Trello). As you can see, we are working hard on Trezor ...
Just sent a donation,
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
We have started a small microsite at http://trezor.bitcoin.cz/ - now it contains just few links. But probably later it'll be a full website with features you are mentioning.
PS: Your donation haven't arrived yet :-/
done
Just sent a donation,
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
We have started a small microsite at http://trezor.bitcoin.cz/ - now it contains just few links. But probably later it'll be a full website with features you are mentioning.
PS: Your donation haven't arrived yet :-/
Just sent a donation,
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
Greetz.
Is it an idea to maybe do sort of a status update/press release on the forum or mabye via some newssite to highlight the project and the status.
And that would also be a good opportunity to ask for donations ?
Greetz.
too much talking and not enough searching..
http://www.mcureverse.com/Product/Microcontrollercrack/List_of_Common_Microcontrollers_By_Brand_68/68.html
http://www.mcureverse.com/Product/Microcontrollercrack/List_of_Common_Microcontrollers_By_Brand_68/68.html
that's nice but I'd say that the target for all hardware bitcoin security devices is to make it time consuming enough for the attacker to get to your coins, so you get the opportunity to transfer them first.
if the attack involves shipping said device to China, the attacker fails without even trying.
too much talking and not enough searching..
http://www.mcureverse.com/Product/Microcontrollercrack/List_of_Common_Microcontrollers_By_Brand_68/68.html
http://www.mcureverse.com/Product/Microcontrollercrack/List_of_Common_Microcontrollers_By_Brand_68/68.html
And what if a security vulnerability is found in the software? Am I supposed to buy a new one? Shouldn't the sellers bear that cost?
What if there's a bug in the software that manages the breaks of your car? (many newer cars have electronic breaks, remember that Toyota scandal?)
Even if it was possible to update the firmware of such software, most people wouldn't be capable of. A recall would be necessary.
I'd expect the same for Trezor. If a critical bug is found, they should do a recall. So, yeah, they'd better test it a lot, and keep it simple.
A lot of people use analogies that don't apply to what they're arguing for, but I do like this one. Trezor-like devices could be an extremely important part of one's personal finances in the near future.
Well, I at least wouldn't want to have on my shoulders the responsibility of having to protect such an import key - nor the price tag on my head that would eventually come with it.
At the end it's up to slush and stick to choose what they prefer: the risk of a recall or the risk of losing / being forced to give up the signing key.
Perhaps the beta version could be modifiable, and once they're sure it's stable enough, they stop selling it and switch to a non-modifiable one. And perhaps once they become a multi-million dollars corporation with branches all over the world, they can afford to use multiple keys kept by different people on different continents, making an attack practically unfeasible.
At the end it's up to slush and stick to choose what they prefer: the risk of a recall or the risk of losing / being forced to give up the signing key.
Perhaps the beta version could be modifiable, and once they're sure it's stable enough, they stop selling it and switch to a non-modifiable one. And perhaps once they become a multi-million dollars corporation with branches all over the world, they can afford to use multiple keys kept by different people on different continents, making an attack practically unfeasible.
Toyota could survive the huge cost of the mass recall. It would have sunk a smaller company, especially if that was the only product. I agree simplicity is valuable, but given the complexity of cryptography I am doubtful the code will be flawless first time.
+ a lot for this.
I'd advise everyone working on an embedded product (secure or not) to design a foolproof update/patch mechanism that's guaranteed not to create too many bricks first (the iPhone is actually great for that !) then design the application.
While it's possible (but hard, and stressful) to get something bug free on the first run, what happens if someone gets code execution through a protocol bug, or the (unstable) deterministic algorithm used to generate keys change and you can't patch your code ?
You want the device to be unmodifiable for security reasons
+
A perfect initial product is very difficult
=
Perhaps we should have limited production runs for the first iteration or two.
If I bought a Trezor v1 that had some limitations but my experience directly led to the next version being spot on I cannot say I would mind. Crowdtesting, so to speak.
+
A perfect initial product is very difficult
=
Perhaps we should have limited production runs for the first iteration or two.
If I bought a Trezor v1 that had some limitations but my experience directly led to the next version being spot on I cannot say I would mind. Crowdtesting, so to speak.
Toyota could survive the huge cost of the mass recall. It would have sunk a smaller company, especially if that was the only product. I agree simplicity is valuable, but given the complexity of cryptography I am doubtful the code will be flawless first time.
So, yeah, they'd better test it a lot, and keep it simple.
+1
And what if a security vulnerability is found in the software? Am I supposed to buy a new one? Shouldn't the sellers bear that cost?
What if there's a bug in the software that manages the breaks of your car? (many newer cars have electronic breaks, remember that Toyota scandal?)
Even if it was possible to update the firmware of such software, most people wouldn't be capable of. A recall would be necessary.
I'd expect the same for Trezor. If a critical bug is found, they should do a recall. So, yeah, they'd better test it a lot, and keep it simple.
Jump to: