Surely embracing the open source nature of your product would be another way to handle altcoin implementation? Then Satoshi Labs just need to review the code, which still takes time, but still less time than writing/testing the code too (not that I'm interested in using altcoins with the Trezor myself)

Kind of agree on balance, although remember what cor said: any alt that's close enough in design to Bitcoin itself (i.e. forked codebases of the Satoshi original) requires very simple changes to the code (no logic changes, just extra declarations)

It depends on what the changes in the firmware are.

If anything in the changelog is related to security issues, especially something described as "urgent" or "severe", update update update. Anything about adding a new altcoin, or fixing a bug you've never experienced, you will be OK.

I guess you're living proof that missing security updates isn't guaranteed to compromise your device. But to me, hardware wallets are about ultimate protection of BTC accounts, knowing that attackers are now aware of flaws in the firmware I'm running would cause me concern.

My recommendation for securely updating the firmware: use an offline PC for the update.

• Download firmware from as secure machine as possible
• Burn the firmware to CD-ROM (yes, CD-ROM)
• Take a hash of the files burnt onto the CD-ROM (or take an image file of the whole CD and do the same)
• Ensure that CD/USB autoplay etc is disabled on OFF-line machine
• Take a hash of the files/CD image on the OFF-line machine
• Compare to the hash you took using the ON-line machine (the file/s you supply to the hash command must be the same comparison)
• If the hashes match, proceed with the firmware flashing on the offline machine using your newly hash-checked update file/s.
• If the hashes do not match, find a new online machine and try again

I would take similar levels of precaution when installing the OS to the offline machine in the first place, otherwise you might end up with a trojaned/backdoored OS on the offline machine, and the the whole rigmarole may be a total waste of time (particularly if you did compromise your funds somehow due to the oversight)

Carlton, out of curiosity.  which platform do you view as more secure today; Armory or Trezor?

I used Armory for years, liked it but tired of using two computers for cold storage and changed to Trezor and have not looked back. Armory has been promising Trezor support but it never comes. I doubt it is a priority now. I am aware of the privacy advantages of running your own full node and Trezor owners will have that option soon according to this post on reddit. Mytrezor release with Bitpay Bitcore support is coming soon. If you do not want to run a Bitcore node on your own Linux box you will have the option in myTrezor.com to connect to other public Bitcore servers. Woohoo!

No experience yet but will be setting up on linux soon. See https://bitcore.io/ both 64 bit Mac OS X and GNU/Linux are currently supported. I assume you will have to run the daemon and the wallet service then point myTrezor.com to the wallet service as the backend instead of Bits of Proof. Uncharted waters here for me sounds like fun.

sorry but isnt be a bit "off topic" ? whe are in Trezor Bitcoin hardware wallet  thread (  no offense here , just to put a reminder.. Thanx.

Pardon? The ability to use Trezor and myTrezor.com with a backend other than Bits of Proof is on topic and a welcome advance. Just not here yet, slush mentioned 25 days ago would be implemented into myTrezor.com soon. 

I only setup ONE wallet with the Trezor after initializing it.  Why are there two Master Public Keys?

In Electrum, it says I have "Account 1"  and "Main Account."

I want to perform offline signing with the Trezor on an airgapped computer, with a watch-only Electrum for broadcasting, and would like to know which master public key to import for the watch-only side and why.

Thanks in advance.