Stealth address (anonymous payments)

[Kosta#]

The topic is discussed here

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.

[Kosta#]

ping

[bitpop]

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

[Peter Todd]

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.

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.

[bitpop]

O

[tacotime]

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.

[Peter Todd]

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!)

[bitpop]

Isn't there a similar bip coming?

[piotr_n]

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.

[Peter Todd]

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.

[piotr_n]

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.

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

[prezbo]

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?

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

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

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

[Peter Todd]

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

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.

[jl2012]

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

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?

[Peter Todd]

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.

[piotr_n]

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

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

[e4xit]

---snip---
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.
---snip---

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

[Peter Todd]

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

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

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

[piotr_n]

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

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

[Kosta#]

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

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?