Add Trezor to wallets

[saivann]

This pull request adds TREZOR to the list of wallets, enables the "Hardware" entry in the menus and drops the "soon-to-be-released" list of hardware wallets on the "Secure your wallet" page.

Live previews: (Merged)

[harding]

LGTM. Thanks!

[christophebiocca]

providing high level of security

Feels like it's missing an "a"

providing a high level of security

[saivann]

@harding You're better than me at evaluating if @christophebiocca's suggestion is better English. Additionally, shouldn't we say "s/a hardware wallet/an hardware wallet/"?

[harding]

@saivann the suggestion by @christophebiocca is correct (thanks, @christophebiocca) so I rebase-amended the commit.

"A hardware" is also correct because (in English) the H is pronounced---making the first sound a consonant sound. With another H word where the H isn't pronounced, "an" would be correct. For example: it has been an honor to work with you all.

[saivann]

@harding Thanks! I rebased this (again) to fix the merge conflict with breadwallet.

[saivann]

In the absence of critical feedback, this pull request will be merged on September 17th.

[schildbach]

LGTM

[slush0]

Are there any specific rules for "New app" flag? Firmware is published for half a year already (which is quite significant time in Bitcoin world), trezor-crypto (heart of Trezor) is already used in other applications, everything is covered by unit tests and we already have some peer reviewers checking our code. I think most of applications (especially those with "Centralized" flags) are even more vulnerable to bugs coming from new/untested code because of complete lack of peer reviews, and they don't have "New app" flag...

[slush0]

Otherwise we're okay with this pull request.

[harding]

@slush0 the rules are in the "passing score" part of the Transparency section of the site README: https://github.com/bitcoin/bitcoin.org#score

The relevant quote is: "The codebase must be public since at least 6 months and previous commits must remain unchanged."

Although its not stated, I think @saivann has been applying that to mean, "...codebase must be public [and the wallet must be in general public use] since at least 6 months..." (If that's correct, we should make it explicit. The reason we measure from first general public use is that it would be unreasonable to expect volunteers to inspect prototype wallets that may not ever get a general release.)

Looking at the repository, the firmware's first commit is April 29th (4.5 months) and I think Trezors only became generally available about 1 month ago.

I agree that it would be preferable to distinguish between wallets that receive significant peer review and those that probably don't receive any significant reviews---unfortunately, I don't know of any easy and objective way to measure that.

As a footnote, Trezor firmware can be built deterministically, correct? If so, I think you'll be the first wallet besides Bitcoin Core to get a "Good" Transparency score, once the six-month review period expires.

[slush0]

@harding Thanks for explanation. You're right, 4.5 months, my bad. However we published sources when we started shipping preorders, which means hundreds devices in the wild.

You're right that builds are deterministic (since firmware 1.2.0). I'll open pull request abou removing "New app" flag in ~2 months.

[saivann]

@harding Making this more explicit makes sense, thanks! How about "codebase and final releases must be public since at least 6 months,"

Maybe this can be discussed when @slush0 opens a pull request in a few months, but hardware devices are different than only software in that (to my knowledge) the device can lie and you have no way to prove if it really uses the right firmware. If I'm not mistaken here, the current "good" score would not be accurate; ("... any developer in the world can ... make sure the final software isn't hiding any secrets"). So maybe a bit more discussions on the topic would make sense.

[slush0]

@saivann Its exact oposite, thanks to deterministic nature of Trezor firmware and deterministic build environment. If you're extra paranoid, you can reflash device with your custom firmware which just blinks the display, then you can reflash the device with proper, signed, deterministically build firmware and you are 100% sure that its using proper firmware.

[harding]

@saivann that phrasing sounds good to me.

More discussion on the topic of hardware/firmware determinism does seem warranted. I do think you're right about that being a discussion most appropriate to a future pull request.