1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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
|
