Could a mobile phone wallet (SPV) receive a stealth transaction, or would it need to be checking all blocks to scan all transactions (not really feasable on a phone, especially as the network scales up). I don't suppose bloom filters would work for catching stealth address transactions?
A wallet doesn't need access to all transactions to use stealth but to remain private there would need to be some filtering. Bloom could maybe work, but prefix filters are probably a better fit.
It could be done right now by any server based wallet that implements it. But bitcoin core would need to be upgraded to support prefix filtering on OP_RETURN for p2p wallet to use stealth transactions.
I've asked Mike if he would be interested in adding support for stealth addresses in Bitcoin XT (no response yet).
Alternatively we could send the nonce over another communication channel.
If not, then how can we offer mobile users the ability to protect their privacy when transacting over instant messangers?
Here is my goal for my wallet which I hope to have implemented sometime next year assuming all the pieces come together.
User profiles (including name, stealth address, bitmessage addresses and social media proofs) are stored in a DHT with the hash embedded in the blockchain.
When you want to send me a payment, you enter my name ― chrispacia ― and a server/peer returns the profile data, relevant transactions, merkle proofs, and social media proofs (which contain tx hashes). Possibly a third party signature could be added for extra security. The wallet will automatically verify everything. The security of the scheme will be similar to Keybase.io if you've ever used that, but without a centralized server.
A transaction sending a payment to the stealth address will be encoded in protobuf using the BIP70 payment message and sent to the recipient using the bitmessage address found in the profile. This assumes some form of prefix filtering is implemented in bitmessage next year to enable lite clients. It's probably too heavyweight to use otherwise.
The recipient's wallet receives the bitmessage message, decrypts it, and broadcasts the network.
Doing it like this means we don't have to use OP_RETURN and pollute the blockchain.
It also means the payment is sent directly to the recipient so the recipient doesn't have to mess with prefix filters or bloom filters for downloading from the chain which will inevitably always have some privacy leaks. (We would still need to use them to find inclusion in a block, but that can be done without leaking privacy).
It also means we would also have a channel for sending BIP70 payment requests. You could simply send a payment request for 1 bitcoin to chrispacia and it will show up in my wallet.
I would likely make the proof of work requirement for payment requests really large to prevent spam payments.
And if you're going to have a bitmessage client in the wallet might as well allow people to send messages to each other using the same username.
If all the pieces come together we'll be able to implement this next... well now this year.