|
I've only skimmed the linked thread, but I thought BM had a sharding mechanism of some sort (streams? channels?) to prevent this problem. Why isn't that enough to solve this problem?
|
|
|
|
Has anyone managed to use the hardware seed with success in Green Address?
I did manage to write my existing seed to a freshly blocked and upgraded dongle, but I haven't tried starting with a dongle that already had a seed on it. |
|
|
|
|
Yay, I've managed to use an HW-1 to log in to my GreenAddress wallet! Is there an overview of the algorithms / protocols used in this mode so we can judge how secure it is? I'm too lazy right now to look it up in the code...
|
|
|
|
It works!!! I had to try it a couple of times, and reset my PC a couple of times, but it did work eventually. I also had to install the modified KryptoKit first in order to be able to block the device by entering an incorrect PIN three times in a row. |
|
|
|
the driver part should be fixed, thanks
Thanks! I've installed the new driver, but I'm not sure how to upgrade the firmware with it. |
|
|
|
|
The firmware update for the 64 bit Windows drivers doesn't work, the zip file appears to be an HTML page saved under the wrong name. I also noticed that the FAQ is out of date, it says that the firmware cannot be updated.
|
|
|
|
|
Is it still possible to mix in some entropy of your own?
|
|
|
|
|
The Bitstamp problem appears to have been fixed.
|
|
|
|
We need to find a reasonable balance but 1MB is definitely not a good one.
Blocks of 1MB combined with tree-chains could turn out to be a perfectly adequate solution. The trade space is larger than just changing the block size. |
|
|
|
We want to maximize miner profit because that will translate to security.
That step in the argument needs more work. Security isn't the only consideration, nor does it obviously trump all others. At some point the incremental value of additional security might not be worth it. |
|
|
|
I think he didn't mean "on every trezor out there", but "do you use trezors to store the signing keys?".
Yeah, that's what I meant. I'm guessing they wont reveal any details about how they protect the signing keys.
It would be nice we could get some reassurance they won't get compromised. |
|
|
|
Yes. Actually there are 5 and we use 3-of-5 scheme.
Do you store those signing keys themselves on a Trezor? |
|
|
|
wish I could upvote this
Yeah, that would be nice. In the meantime, you can put gweedo on ignore. |
|
|
|
No there is not.
I didn't say there was, I said 'check out'. |
|
|
|
|
Check out HashCash and Bitmessage.
|
|
|
|
|
Well said, put this guy on ignore.
|
|
|
|
|
Because they get sabotaged immediately?
|
|
|
|
|
I'm not sure it would be more difficult to hack, but since it is a widely used standard product it should be easier to verify.
|
|
|
|
I think that it would be a bit safer if the firmware was all in ROM, so it could not be changed except by physically tampering with the device. That may limit the useful life of the hardware, but this may be a good thing.
Having the firmware and the keys on a smart card, or two separate smart cards, would also be nice. |
|
|
|
Even if your Trezor works as it is supposed to, you will still be vulnerable to attacks like address phishing (the hacker tricks you into sending payment to the wrong address) and man-in-the-middle (a compromised PC software displays the correct destination address on the screen, but puts the thief's address in the transaction that it gives Trezor to sign. While an alert user can notice the substitution by checking the Trezor's display, there will inevitably be users who check only the PC screen, out of laziness or because they are not aware of the risk.)
I'm not sure if Trezor supports it already, but shouldn't the payment protocol solve that particular problem? |
|
|
|
|
Show Posts
