Recently I think a lot about combining Stealth addresses with SPV butI did not come to a satisfying conclusion, so I post this as achallenge to the wider community. Maybe you have an idea.

## Explanation of SPVIn SPV a thin client puts his public keys in a bloom filterand asks a full node to give him Merkle proofs of all transactionswhose pubkey are in the bloom filter. Since a bloom filter has a lotof false positives depending on the parameters, this gives privacy tothe thin client, since the full node cannot detect if a specifictransaction belongs to the thin client. This is cool if you want touse Bitcoin on your smartphone.

## Explanation of Stealth AddressesStealth addresses on the other hand enable receiver privacy. Thesender of a transaction derives a one-time pubkey to which he sends themoney. The receiver can check if the money was sent to him and recoverthe one-time private key. This is cool, since an observer cannotdecide if two payments belong to the same recipient. Further therecipient needs only to have one pubkey.For a more formal explanation see https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkeyI will use their notation in the following.

## The ProblemMy line of thought was to combine stealth addresses with spv, so thatI can use stealth addresses on my smart phone without losing privacy.

Basically to check if a payment belongs to a pubkey (Q,R), the fullnode needs to check if R' = R + H(dP)*G for each transaction. For thisit needs the private scanning key d.This sucks, since when I give my d to a full node, he can link all mytransactions. For an online-wallet this may be okay, but not for thinclient synchronisation.

## IdeasIn the following I detail some ideas of me which did not work.

It does not suffice to have a Bloom filter and check if d iscontained since there is no way to recompute d from the equation. Ifthere were a way to recompute d, the scheme would offer no privacy,since anyone could compute the private scanning key d and scan forpayments.So, if we modify the scheme we need to be sure that d is kept private.

Multiparty computation may be possible in theory. The full node andthe thin client could collaboratively check R' = R + H(dP)*G, where dis the private input of the thin client and R, R',P is provided by thefull node. But this is costly and they need to do it for eachtransaction. It may be more costly than simply setting up a full node.

I do not think that some kind of search functionality without leakingthe search pattern (PIR?) would work, since the full node needs to compute on thedata it has found. And further it needs to retrieve the whole Merkleproofs.

Flag goes in your filter. You anonymity set is all other transactions usingthat same flag.

This is fairly decent privacy but the problem is you still need filtermatches on outgoing transactions to build a functioning wallet. So it mightnot be an improvement over standard bloom filters but at least you can dostealth if you want.

On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <

Post by Henning Kopp via bitcoin-devHi all,Recently I think a lot about combining Stealth addresses with SPV butI did not come to a satisfying conclusion, so I post this as achallenge to the wider community. Maybe you have an idea.## Explanation of SPVIn SPV a thin client puts his public keys in a bloom filterand asks a full node to give him Merkle proofs of all transactionswhose pubkey are in the bloom filter. Since a bloom filter has a lotof false positives depending on the parameters, this gives privacy tothe thin client, since the full node cannot detect if a specifictransaction belongs to the thin client. This is cool if you want touse Bitcoin on your smartphone.## Explanation of Stealth AddressesStealth addresses on the other hand enable receiver privacy. Thesender of a transaction derives a one-time pubkey to which he sends themoney. The receiver can check if the money was sent to him and recoverthe one-time private key. This is cool, since an observer cannotdecide if two payments belong to the same recipient. Further therecipient needs only to have one pubkey.For a more formal explanation see https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkeyI will use their notation in the following.## The ProblemMy line of thought was to combine stealth addresses with spv, so thatI can use stealth addresses on my smart phone without losing privacy.Basically to check if a payment belongs to a pubkey (Q,R), the fullnode needs to check if R' = R + H(dP)*G for each transaction. For thisit needs the private scanning key d.This sucks, since when I give my d to a full node, he can link all mytransactions. For an online-wallet this may be okay, but not for thinclient synchronisation.## IdeasIn the following I detail some ideas of me which did not work.It does not suffice to have a Bloom filter and check if d iscontained since there is no way to recompute d from the equation. Ifthere were a way to recompute d, the scheme would offer no privacy,since anyone could compute the private scanning key d and scan forpayments.So, if we modify the scheme we need to be sure that d is kept private.Multiparty computation may be possible in theory. The full node andthe thin client could collaboratively check R' = R + H(dP)*G, where dis the private input of the thin client and R, R',P is provided by thefull node. But this is costly and they need to do it for eachtransaction. It may be more costly than simply setting up a full node.I do not think that some kind of search functionality without leakingthe search pattern (PIR?) would work, since the full node needs to compute on thedata it has found. And further it needs to retrieve the whole Merkleproofs.Any better ideas?Best,Henning--Henning KoppInstitute of Distributed SystemsUlm University, GermanyOffice: O27 - 3402Phone: +49 731 50-24138Web: http://www.uni-ulm.de/in/vs/~kopp_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Chris Pacia via bitcoin-devYes I've had it working using two pushes in op_return.op_return op_pushdata <flag> op_pushdata <ephem_pubkey>Flag goes in your filter. You anonymity set is all other transactions usingthat same flag.This is fairly decent privacy but the problem is you still need filtermatches on outgoing transactions to build a functioning wallet. So it mightnot be an improvement over standard bloom filters but at least you can dostealth if you want.On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <

Post by Henning Kopp via bitcoin-devHi all,Recently I think a lot about combining Stealth addresses with SPV butI did not come to a satisfying conclusion, so I post this as achallenge to the wider community. Maybe you have an idea.## Explanation of SPVIn SPV a thin client puts his public keys in a bloom filterand asks a full node to give him Merkle proofs of all transactionswhose pubkey are in the bloom filter. Since a bloom filter has a lotof false positives depending on the parameters, this gives privacy tothe thin client, since the full node cannot detect if a specifictransaction belongs to the thin client. This is cool if you want touse Bitcoin on your smartphone.## Explanation of Stealth AddressesStealth addresses on the other hand enable receiver privacy. Thesender of a transaction derives a one-time pubkey to which he sends themoney. The receiver can check if the money was sent to him and recoverthe one-time private key. This is cool, since an observer cannotdecide if two payments belong to the same recipient. Further therecipient needs only to have one pubkey.For a more formal explanation see https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkeyI will use their notation in the following.## The ProblemMy line of thought was to combine stealth addresses with spv, so thatI can use stealth addresses on my smart phone without losing privacy.Basically to check if a payment belongs to a pubkey (Q,R), the fullnode needs to check if R' = R + H(dP)*G for each transaction. For thisit needs the private scanning key d.This sucks, since when I give my d to a full node, he can link all mytransactions. For an online-wallet this may be okay, but not for thinclient synchronisation.## IdeasIn the following I detail some ideas of me which did not work.It does not suffice to have a Bloom filter and check if d iscontained since there is no way to recompute d from the equation. Ifthere were a way to recompute d, the scheme would offer no privacy,since anyone could compute the private scanning key d and scan forpayments.So, if we modify the scheme we need to be sure that d is kept private.Multiparty computation may be possible in theory. The full node andthe thin client could collaboratively check R' = R + H(dP)*G, where dis the private input of the thin client and R, R',P is provided by thefull node. But this is costly and they need to do it for eachtransaction. It may be more costly than simply setting up a full node.I do not think that some kind of search functionality without leakingthe search pattern (PIR?) would work, since the full node needs to compute on thedata it has found. And further it needs to retrieve the whole Merkleproofs.Any better ideas?Best,Henning--Henning KoppInstitute of Distributed SystemsUlm University, GermanyOffice: O27 - 3402Phone: +49 731 50-24138Web: http://www.uni-ulm.de/in/vs/~kopp_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev