HD seed is just a general term for any wallet where a single seed can be used to recover any number of addresses. Armory before has advertised itself as being the first "Hierarchical Deterministic Wallet", that is all I was referring too. Understand Armory uses a different type than BIP0032 today.

OK thanks. So you are using the Trezor as a full replacement for the offline secure storage. And with the planned Armory support will continue to use online Armory watching only wallets as your wallet, but use the Trezor for signing.

I use the trezor for both secure long-term storage and also for day-to-day spending. I actually think it's at least as secure a any armory (or other solution running on multipurpose hardware)-based solution. It's the nice thing about trezor: it combines ease of use with extreme security. In conjunction with electrum (as an example) I can also use address-based coin control for increasing privacy.

Of course, for ordering pizza or making the odd donation I use mycelium. It's just way faster (I make a habit of unplugging the trezor after use) and scanning qr-codes from the screen and seeing the payment arrive a second later has something very special to it.

I have no experience with the armory linear scheme in particular, but I would assume all type 2 deterministic schemes suffer from this problem. I can say it for sure for the classic electrum 'linear' scheme.

My solution: don't ever export private (sub)keys (my trezor nicely keeps me from doing that even when I'm drunk or whatever).

if SINGLE privkey is compromised from linear chain then ALL privkeys can be computed in same chain.

i foresee the Trezor replacing the offline wallet and its pc and being more secure since the offline wallets can be susceptible to a USB malware attack.  as far as i know, there is no way to get privkeys off a Trezor so in that sense it is safer.  i would hope you could just plug it into your online pc to sign tx's from the online Armory watching only wallets.  we'll have to see what Armory comes up with.

i don't understand how or why you are using HD seeds since Armory currently only generates linear deterministic keypairs, not hierarchical.  i also wouldn't bother exporting privkeys from the offline Armory wallet since you can just make a HD seed backup of your Mycelium wallet that can be restored in case of theft or loss while avoiding excessive and unnecessary exposure to USB attacks from accessing the offline wallet.

Out of curiosity, how do you guys plan on using your Trezor? I looked into them, like the idea and would like to get one, but couldn't see how a Trezor would fit into how I currently manage my BTC.

In my case I use Armory offline wallets for primary BTC storage, with secure HD seed backups so I'm confident I can always restore the wallets. For day to day usage I keep a small amount in Mycelium, and use this for buying pizza, etc. To fund Mycelium, in Armory I create spending addresses with a small amount of BTC and export the private key to Mycelium. The advantage to this is if I lose my phone, the BTC are recoverable in Armory or HD seed backups. The worse case is if someone steals and breaks my phone, I can only lose the amount on the phone (similar to cash in a real wallet). I like this method because: 1)  I can store and use BTC on my phone without worrying about losing the coins because they are simultaneously in Armory (which is an awesome property of Bitcoin) and 2) Only a small amount are ever "at risk", with the majority secure in Armory.

Because of this I can't see how a Trezor would fit. So how do you guys use it?

Point being, you said gold was scarce and this is incorrect. More correctly it is technically inaccessible, for now.

Viable means economic to retrieve in this context, if that was not obvious. There is now an identifiable technology development path towards retrieving gold from asteroids, do your own research on this if you do not believe me, I don't have time to lay it all out for you. Time and costs to becoming viable will only decrease from here onwards.

This is good news and should satisfy cyphers privacy needs.

To be clear, it's not "incrementing".  It's a hash that changes if the private key or message changes.  In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979.  It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus.

Oh ok that makes sense. What's protecting an identical transaction?

I wish people would stop referring to "you are at risk if you don't use RFC6979".  We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses.  However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard.  RFC6979 is exactly what it says "Request for Comments".  It's not a standard, never been approved by any organization.  I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.

For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack.  If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device.   This would mean our HSMs would immediately be unsuitable for any government use.  This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.  

This doesn't mean that I don't think RFC6979 is useful.  It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability.  While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).

My attitude on all this is:  I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing.  But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms.  For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.  

I guess so. I don't know the details, but both etotheipi and goatpig have confirmed that they will implement Trezor in Armory.

Gary Shilling says oil is going to $10

http://uk.businessinsider.com/gary-shilling-oil-is-going-to-10-2015-2?r=US

My favourite client, Armory, will also support Trezor in the future.