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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1W2nqj-0003ce-J4
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 20:11:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f47.google.com;
Received: from mail-la0-f47.google.com ([209.85.215.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W2nqh-0003me-Og
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 20:11:05 +0000
Received: by mail-la0-f47.google.com with SMTP id eh20so3322485lab.6
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 Jan 2014 12:10:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.167.103 with SMTP id zn7mr559719lab.68.1389643856980;
Mon, 13 Jan 2014 12:10:56 -0800 (PST)
Received: by 10.112.198.65 with HTTP; Mon, 13 Jan 2014 12:10:56 -0800 (PST)
In-Reply-To: <52D4458C.6010909@gmail.com>
References: <20140106120338.GA14918@savin>
<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
<20140110102037.GB25749@savin>
<op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
<CABsx9T2G=yqSUGr0+Ju5-z9P++uS20AwLC+c3DnFMHtcQjQK6w@mail.gmail.com>
<CAAS2fgTz0TaGhym_35V3N2-vHVzU9BeuV8q+QJjwh5bg77FEZg@mail.gmail.com>
<20140113194049.GJ38964@giles.gnomon.org.uk>
<CANAnSg30V01B_3LCJ09sTwcsYa4_WOg3sKd-=p6COZS6w0b-uA@mail.gmail.com>
<52D4458C.6010909@gmail.com>
Date: Mon, 13 Jan 2014 12:10:56 -0800
Message-ID: <CAAS2fgTzVWUF_B_-1jkRs3WZ8Um_CcHeH7uFU0eLncgEqQ01HQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W2nqh-0003me-Og
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 20:11:05 -0000
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> Then when someone
> wants to pay you, you simply give them the multiplier and root key (they
> already have the root key, but should verify).
[...]
> What
> advantages does "stealth addresses" have over this scheme? You could extend
> it using some kind of deterministic sub-branching and/or ECDH to create
> multiple payment addresses without querying the payee.
The stealth address stuff is the ECDH to create multiple payment
addresses without querying the payee.
Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH. The reason to use two is that it makes delegating
detection possible and so you don't have to have you spending keys
online to even detect these payments. Why'd that get dropped?
I don't think this is a good idea if you have to constantly keep your
spending key(s) online even to detect payments, even with the limited
use-cases envisioned.
|
