summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHenning Kopp <henning.kopp@uni-ulm.de>2017-05-04 14:51:39 +0200
committerbitcoindev <bitcoindev@gnusha.org>2017-05-04 13:00:01 +0000
commit00e044ee17c954a0fbb5ed1888881128c08502ff (patch)
treeacdfe469621e005b23bf223e10c397450133e458
parentd9dc31bd14457b1537ceccf05ac68d2659b615eb (diff)
downloadpi-bitcoindev-00e044ee17c954a0fbb5ed1888881128c08502ff.tar.gz
pi-bitcoindev-00e044ee17c954a0fbb5ed1888881128c08502ff.zip
[bitcoin-dev] Combining SPV and Stealth addresses
-rw-r--r--72/f3e92029c9bfb753685f8295d4e6d3decb0160116
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
+