thousands asked already, but nobody knows yet. we will have to wait one more month to see...

it's open source and open hardware. You don't have to look what is inside. Plans are publicly available online.

This is not too complex, so I don't think somebody would claim that. But the more important thing is that, unlike other brilliant ideas on this forum, this does not create a security risk and does not enable users to shoot in their leg. (which would be a bad thing for a secure idiotproof device). To sum it up, I expect devs to implement it eventually based on their priorities and the amount of work involved.

edit: So it might be a good idea to e-mail support that it is not working for you and ask for this feature.

I know. That is the reason why I estimated the price in USD and I based it on the USD price of the device at the preorder launch. But still, I hope you will accept bitcoin purchases!


This formula has too many unknowns for the people asking for the price. That is why we are speculating and guessing what the result might be.

Satoshilabs plan to launch classics retail in July. The preorder price for these started at 1BTC when 1BTC was 120USD. They refuse to announce the retail price at this moment (maybe because of BTC price fluctuations) and I'm not familiar with it. Nevertheless, let me speculate a bit. If 120USD was "enthusiast price" I expect that the retail price will be in the 50-80USD range (or July BTC equivalent).

All we need now is a security expert who will look at the code and confirm there is no cheating from the devs side. Any volunteers?

No worries dude. You don't need to update, because when your device is shipped in July it will probably have new firmware preinstalled. Win situation for you. ;-)

Let me be clear here. I'm talking about ALL wallets, not just Trezor. Using above techniques, you can have deterministic signatures, that comply with RFC6979 most of the time and when they don't they leak your seed. You will not detect is, because the only test you actually do is to check whether it is deterministic, not whether it is RFC6979 compliant (i.e. equality across multiple runs). You can sell or spread your hardware/software wallet for a while while collecting the keys and when competition crushes you eventually, then you can use all those seeds you collected to clear their wallets and fly to Carribean.

I'm not saying that this is Trezor guys intention. I'm just saying that if this was any wallet maker intention it would be EXTREMELLY difficult to find. It is easy to prove it from code, but I disagree that it is simple to prove in blackbox testing. It depends on your luck. From this perspective I really like this initiative of signing the build by third parties. If only everybody did this. But still there are problems like the bootloader that is not signed by anyone etc.

You see, proving that you are not evil is difficult. In a sense, it is similar to using random K in signatures. In the code it is easy to see whether the number comes from the HW rng that is on the chip (much simpler than checking your RFC6979 implementation). But it is impossible to prove this from the generated signature.

There are million of ways how wallet devs (including trezor devs) can leak your seed. Some quick ideas:

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).
2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.
3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.
6. Combine some of above or invent your own.

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

The seed is "compromised" in a sense that some information about it is revealed. But the seed is not revealed itself. That is the whole reason to use HMAC in keys derivation. There is no known method to derive other siblink private keys in the deterministic wallets, i.e. no way to steal BTC. You can derive children nodes in the hierarchy, but those are not used for anything.

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it.

Please correct me if I'm wrong.

 The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used. There is virtually no way to actually check/prove that this happens in all cases. You can prove that the code that is in trezor git repository uses this RFC, but you have to trust devs that the device is running unmodified code.
  Any wallet, hardware or software, can be malitious and can have backdoors. In the end you have to trust someone and Trezor devs can be trusted in my opinion more than some random guys that appear out of nowhere with their ultra cool android wallets.

The way you can test this RFC is used:
1. Reconstruct private keys from the trezor seed (using wallet32 or some other software).
2. Sign any transaction using Trezor.
3. Do a lot of math or coding to check that the signature was made using deterministic k.

Or just trust what the readme says...

You have to trust someone. You trust guys who made Armory and you trust yourself that you can secure your cold wallet. If you don't build bitcoin sw you always have to trust someone...

I'm sorry, you are right. BTC was in range 85-210 USD during the preorder period. It started at approx 120 and when it rised to 200 in November, preorders were closed. So you might have paid 400AUD equivalent or more depending on the date of purchase.

You use piece of paper with Trezor as well. It is even included in the package. But unlike paper, this device can sign transactions, generate multiple addresses using bip32 and bip44 deterministic wallets. Your address is pin protected or even secured with the passphrase (with plausible deniability of you holding any bitcoin).

If you have your private key paper backup, you will eventually enter it into a computer that is connected to internet. You may be an computer expert and you can keep it secure. If that is the case, then I awe you. Many people can't be sure but they would still like to use Bitcoin. This device is really easy to use so even non-expert can do that.

400AUD is a bit more than the preorder price, but I expect that the retail price will be much lower (I may be wrong. we will see in a month). Don't buy if you don't care about the "First edition" engraving on the back of the device.

There are 4,000,000,000,000,000,000,000,000,000,000,000,000,000 combinations of common words in BIP39 with 12 words (least secure choice) You can take your guess.

This is probably not very convinient, but you can use 3rd tool like https://github.com/weilu/bip39 to generate priv key. However, if I understand it correctly, BIP39 is not enough and you will need BIP44 in addition to that to get your wallet priv key through derivation from what you get using the tool.

Based on the name of the tool I would guess that the main reason to use this one is speed. How fast is it compared to openssl?

I understand that this software may be simpler to verify than some existing signers. But if it used  openssl which is used everywhere I would say that it would get even better verification. Openssl already had a lot of experts look at it. If this tool does not get such security review, what is the actual benefit of it?

If you are sure that the device is really trezor then you should be OK. I don't think there are fake devices out yet so you should be fine but this will change over time. If the device is not genuine than anything can happen.
I would flush the software on the device to make sure latest original sw is used.

Exactly! You can have 10 locks on a device that has the ability to connect and it eventually will connect. Bither lock can't protect you. Only the device that can't leak keys by design can keep private keys inside.
You are right that people trust their phones with some personal data. The security of a phone is good enough to store your FB password, but I won't trust it with my live savings.
How does your app get in the phone if the phone never connects to anything? How do you update your app? If the phone was infected before your app was installed, how can you be sure that it is not communicating?
Security expert can verify simple single purpose communication protocol of Trezor and its code base. No single person can verify Anroid.