From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3AB11504 for ; Sat, 6 May 2017 09:38:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0874FF for ; Sat, 6 May 2017 09:38:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at uni-ulm.de Received: from localhost.localdomain (ip-37-201-5-160.hsi13.unitymediagroup.de [37.201.5.160]) (authenticated bits=0) by mail.uni-ulm.de (8.15.2/8.15.2) with ESMTPSA id v469cBmL026240 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 May 2017 11:38:13 +0200 (CEST) To: Chris Pacia References: <20170504125138.GA2027@banane.informatik.uni-ulm.de> From: Henning Kopp Message-ID: <4f96caa7-5150-b7da-45a5-bf8502b60205@uni-ulm.de> Date: Sat, 6 May 2017 11:38:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: poseidon 1156; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Combining SPV and Stealth addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 09:38:22 -0000 Sorry, I cannot quite follow you. What do you mean with flag? Best, Henning Am 04.05.2017 um 18:23 schrieb Chris Pacia: > Yes I've had it working using two pushes in op_return. > > op_return op_pushdata op_pushdata > > Flag goes in your filter. You anonymity set is all other transactions using > that same flag. > > This is fairly decent privacy but the problem is you still need filter > matches on outgoing transactions to build a functioning wallet. So it might > not be an improvement over standard bloom filters but at least you can do > stealth if you want. > > On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi all, >> >> Recently I think a lot about combining Stealth addresses with SPV but >> I did not come to a satisfying conclusion, so I post this as a >> challenge to the wider community. Maybe you have an idea. >> >> ## Explanation of SPV >> In SPV a thin client puts his public keys in a bloom filter >> and asks a full node to give him Merkle proofs of all transactions >> whose pubkey are in the bloom filter. Since a bloom filter has a lot >> of false positives depending on the parameters, this gives privacy to >> the thin client, since the full node cannot detect if a specific >> transaction belongs to the thin client. This is cool if you want to >> use Bitcoin on your smartphone. >> >> ## Explanation of Stealth Addresses >> Stealth addresses on the other hand enable receiver privacy. The >> sender of a transaction derives a one-time pubkey to which he sends the >> money. The receiver can check if the money was sent to him and recover >> the one-time private key. This is cool, since an observer cannot >> decide if two payments belong to the same recipient. Further the >> recipient needs only to have one pubkey. >> For a more formal explanation see https://github.com/genjix/ >> bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey >> I will use their notation in the following. >> >> ## The Problem >> My line of thought was to combine stealth addresses with spv, so that >> I can use stealth addresses on my smart phone without losing privacy. >> >> Basically to check if a payment belongs to a pubkey (Q,R), the full >> node needs to check if R' = R + H(dP)*G for each transaction. For this >> it needs the private scanning key d. >> This sucks, since when I give my d to a full node, he can link all my >> transactions. For an online-wallet this may be okay, but not for thin >> client synchronisation. >> >> ## Ideas >> In 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 is >> contained since there is no way to recompute d from the equation. If >> there were a way to recompute d, the scheme would offer no privacy, >> since anyone could compute the private scanning key d and scan for >> payments. >> 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 and >> the thin client could collaboratively check R' = R + H(dP)*G, where d >> is the private input of the thin client and R, R',P is provided by the >> full node. But this is costly and they need to do it for each >> transaction. It may be more costly than simply setting up a full node. >> >> I do not think that some kind of search functionality without leaking >> the search pattern (PIR?) would work, since the full node needs to compute >> on the >> data it has found. And further it needs to retrieve the whole Merkle >> proofs. >> >> Any better ideas? >> >> Best, >> Henning >> >> -- >> Henning Kopp >> Institute of Distributed Systems >> Ulm University, Germany >> >> Office: O27 - 3402 >> Phone: +49 731 50-24138 >> Web: http://www.uni-ulm.de/in/vs/~kopp >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >