I can't speak for the Armory devs, but one nice thing about implementing stealth addresses in Armory is that it already has the machinery to scan the blockchain; you could easily use stealth at the highest privacy level where any stealth tx that's sent could be going to you. (zero-filtering)
It's something to consider about Armory in general: because it can work so easily with a local full-node you always have excellent privacy with regard to the contents of your wallet. All the queries are local, so info on what coins are in your wallet never leaves your machine. That's much better than SPV clients like Android Wallet where every peer you connect to learns statistical info narrowing down your addresses to within about one in 10,000 or so, or Electrum which currently just tells peers what addresses are in your wallet.
I'm very interested in this feature. It's just that it still sounds very theoretical at the moment. I'm also concerned about how much computation it will be to track the addresses ... ECDH calculations aren't cheap. I guess I'm still in a waiting mode, implementing other things while I wait for this to be ironed out (I don't have much to contribute to the discussion, though I have spent a lot of time thinking about how to get the same benefits without all the ECDH calcs).
By my standards, stealth addresses are pretty concrete.
But yeah, part of why I was interested in working with someone was to nail down some of the implementation issues in a real-world client, speed being one of them. My basic idea was to have a bandwidth/speed/privacy tradeoff, and there's some interesting ideas being discussed right now on what's the best way to do that.
One key implementation question is can the Armory codebase handle addresses where to pay them you have to make a transaction with not just one, but
two specific txouts?
Peter: Btw, I'm working on P2SH support right now. You will be able to test it on 0.91-dev in the next couple days. In fact, it seems to be working right now, on the p2shout branch -- you can try it right now, though I wouldn't do anything other than testnet.
As part of the update, I modified the PyTxDistProposal::createFromTxOutSelection() method to take any arbitrary list of script-value pairs, instead of just hash160 values. Right now, it will error out if you supply it something other than an P2PubKeyHash or P2SH, but that could be modified locally to create a tx with any arbitrary output scripts. As long as all the inputs are standard UTXOs, you can create such a tx and sign it no problem (have fun getting it mined, though).
Excellent! Sorry for the late reply, but I finally got a chance to try that branch out. Looks fine to me, although I see the odd IndexError on the console, not sure if it's related:
(ERROR) Traceback (most recent call last):
File "/home/pete/src/bitcoin/BitcoinArmory/qtdialogs.py", line 9301, in showContextMenuTx
idx = self.addrBookTxView.selectedIndexes()[0]
IndexError: list index out of range
