diff options
author | Henning Kopp <henning.kopp@uni-ulm.de> | 2017-05-04 14:51:39 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-04 13:00:01 +0000 |
commit | 00e044ee17c954a0fbb5ed1888881128c08502ff (patch) | |
tree | acdfe469621e005b23bf223e10c397450133e458 | |
parent | d9dc31bd14457b1537ceccf05ac68d2659b615eb (diff) | |
download | pi-bitcoindev-00e044ee17c954a0fbb5ed1888881128c08502ff.tar.gz pi-bitcoindev-00e044ee17c954a0fbb5ed1888881128c08502ff.zip |
[bitcoin-dev] Combining SPV and Stealth addresses
-rw-r--r-- | 72/f3e92029c9bfb753685f8295d4e6d3decb0160 | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/72/f3e92029c9bfb753685f8295d4e6d3decb0160 b/72/f3e92029c9bfb753685f8295d4e6d3decb0160 new file mode 100644 index 000000000..06811bd4c --- /dev/null +++ b/72/f3e92029c9bfb753685f8295d4e6d3decb0160 @@ -0,0 +1,116 @@ +Return-Path: <henning.kopp@uni-ulm.de> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3EF94514 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 May 2017 14:51:44 +0200 (CEST) +Date: Thu, 4 May 2017 14:51:39 +0200 +From: Henning Kopp <henning.kopp@uni-ulm.de> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |