Bitcoin Forum

The topic is discussed here (https://bitcointalk.org/index.php?topic=418071.0)

Unfortunately, being newbie, I can't post my question there, so here it is.

Step 3 of the protocol (Generate your private key for recovering your stealth funds [recipient]) requires recipient to know nonce used by sender. Therefore, (1) the step of securely communicating nonce from sender to recipient is missing and (2) the whole thing is equivalent to:

Step 1. Sender generates completely random address and sends money to it
Step 2. Sender sends information required to access funds to recipient, encrypted by recipient's public key.

Please let me know what I am missing. Thank you in advance.

ping

Yeah I don't get it either. And what's the point if the address part is simply transformed into an address? Unless it's random but I don't think so.

Check my signature for a much better tool

It is random - that's the whole point. The only people who can figure out what stealth address was being paid by the transaction are the sender and the receiver, no-one else.

O

Yup; most explanations of this are really confusing so far, so I'll try to explain it again

Sender gets stealth address, generates a Bitcoin address based on this

Sender uploads a pubkey and nonce (secret which appears as a bunch of random characters) to the network via OP_RETURN function, and sends some money to the generated address

Receiver scans the blockchain for pubkey and nonce that allows him to generate a private key to the address the sender created and sent funds to, and then he claims ownership of the address

Important stuff:
1.) No one aside from the sender and the receiver can possibly know where the money is going, because a new, random address for the receiver is generated every time.
2.) Receiver has to scan every OP_RETURN tx on the blockchain in search for his funds.
3.) The receiver and only the receiver can spend funds at these addresses the sender generates.

tacotime: That's encrypted nonce. I think using the word encrypted is what makes it "click" for people. Also, point out that a nonce is just "a random number used once" (edit: oh, no you did, good!)

Isn't there a similar bip coming?

All I can tell you about stealth addresses is: good luck using them with a cold wallet!

The only way to figure out which outputs belong to your wallet goes through decrypting every possible nonce with each private key that you have ever used for a "stealth address".
It is a huge overhead in the client and IMHO implementing this idea is just not worth all the effort - considering that it does not really improve privacy more than sending a regular unique address to each of your payers, using an actually encrypted channel. So personally I would rather suggest to focus on providing a proper encryption for sending a bitcoin addresses to other parties.

Incorrect.

The spec we're working on for them supports the use of a separate private key for decrypting the nonces so that you can keep that key, and only that key, online and the private keys required to spend the funds totally offline. Usually you'd use two or three keys in total in a 2-of-2 or 2-of-3 scheme with the "decrypt" key being necessary, but not sufficient, to spend the funds.

Regarding a unique address for each payer, the idea behind stealth addresses is to make the process of getting funds more convenient so that using bitcoin in the most private way is always simple and easy rather than annoying. Stealth addresses are a form of "proper encryption" for sending a bitcoin address to other parties.

Oh, thanks for explaining.
In such case it is much better design that I had though.
Sorry for doubting in you :)

Still you need to try decrypting each nonce with each private key you have ever issued, in order to find out if a certain tx actually belongs to your wallet - did I get that part correct?
What I mean is: if you have issued like 1000 stealth addresses and 50% of the transactions use stealth-type outputs, then I don't really envy your node. That is more like a designing of a disaster ;)

That is correct but I don't think it's that much of an overhead.

I don't really see how one would benefit from more than one stealth address though.

My thinking is that a wallet would only use a single stealth address, so you only need to test tx's matching your adjustable prefix (a bandwidth/anonymity tradeoff) against the single key. Disambiguating payments could be done with a encrypted "payment ID", or just by value and time. (quite sufficient I think for individuals)

After all, the whole point of stealth addresses is that you only need a single one! The idea came about when we were trying to figure out how to put a bitcoin address in a OpenPGP key yet still keep payments to that address private.

What if I have multiple identities? Is it possible to have many different stealth addresses which are all controlled by a single private key, while no one could tell these addresses are related?

That's not possible unfortunately. Just a limitation of how the underlying cryptography primitive works; I'd be very interested if anyone can come up with a way to do it without that limitation.

FWIW most people don't realize this, but multiple non-clustered addresses reduces your privacy when you use SPV nodes to query peers for blockchain data relevant to your wallet: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html

Lots of engineering trade-offs here.

But how do you then see using stealth addresses in SPV nodes?

Nice! I'm sure I didn't notice this when I read the run-through you posted on Sourceforge!
Edit: archive of the mailing list on SF

Your homework problem: read the paper where that's explained and tell everyone else here how that works.  ;D

yeah... I wouldn't wait for it, though.
I don't remember doing homework even back at school - no way to start it now :)

Just to make sure I got it right: by the pubkey you mean stealth-address, and by nonce you mean private-key-to-actual-address encrypted by pubkey/stealth-address. Is it correct?

Nonce could literally mean nonce which you use against a curve

Sorry, to bump up this thread but I have a question regarding stealth addresses. If you only have the stealth address and the nonce can you derive the "normal" bitcoin address to which the payment was made?

I think so because that's how the payer pays

Well I'm not an expert but it doesn't look like its possible without the private key behind the stealth address or the key pair the payer generated.

initiate stealth: https://github.com/spesmilo/sx/blob/master/src/sx-stealth-send
uncover stealth: https://github.com/spesmilo/sx/blob/master/src/sx-stealth-recv

In my scenario only the stealth address and nonce are known. S1 and c are not known.

I'm under the assumpion they send to a normal address which is randomly generated. Then they give you the nonce so you know which one. Perhaps you're also thinking of getting the private key which isn't possible but part of receive.

Try forcing the nonce in the send function.

I am thinking of a random observer who has two public pieces of data i.e. the nonce, which was posted on some forum somewhere as outlined in the stealth address docs, and the stealth address which he suspects is the intended recipient of the coins. He wants to connect the two and the only way to do that is to derive the regular bitcoin address (using just the nonce and stealth address) and then check if that regular address has coins in it. The diffie-helman key exchange seems to make that impossible.