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 3EF94514 for ; Thu, 4 May 2017 13:00:01 +0000 (UTC) X-Greylist: delayed 00:08:10 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 188AF113 for ; Thu, 4 May 2017 12:59:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at uni-ulm.de Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de [134.60.77.114]) (authenticated bits=0) by mail.uni-ulm.de (8.15.2/8.15.2) with ESMTPSA id v44CpdhV012827 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 4 May 2017 14:51:44 +0200 (CEST) Date: Thu, 4 May 2017 14:51:39 +0200 From: Henning Kopp To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170504125138.GA2027@banane.informatik.uni-ulm.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-DCC--Metrics: poseidon 1481; Body=1 Fuz1=1 Fuz2=1 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 Subject: [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: Thu, 04 May 2017 13:00:01 -0000 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