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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
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 <jeremy@taplink.co>) id 1W3aSk-0003zH-3V
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 00:05:34 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W3aSj-0001CD-9W for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 00:05:34 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Wed, 15 Jan 2014 16:14:42 -0800
Content-Type: multipart/alternative; boundary=----------mQZk93yAj62F69c4eXXgLP
To: "Gregory Maxwell" <gmaxwell@gmail.com>, "Jeff Garzik" <jgarzik@bitpay.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>
<CANEZrP0huBWqgvQik9Yc26Tu4CwR0VSXcfC+qfzsZqvoU4VJGA@mail.gmail.com>
<20140113133746.GI38964@giles.gnomon.org.uk>
<CANEZrP1KAVhi_-cxCYe0rR9LUSYJ8MyW8=6eSJZ65FeY5ZJNuQ@mail.gmail.com>
<20140114225321.GT38964@giles.gnomon.org.uk>
<CANAnSg0tH_bK_19rsRRHOeZgrGYeWMhW89fXPyS4DQGmS4r_7A@mail.gmail.com>
<CALimQCXgc0eXeOcqFGUaCpSF7gKEe87KzvLqHZwUysV3WyjjGw@mail.gmail.com>
<CAAS2fgShChAQryfUOBp60jB-zxn2tH986fu1HfT+LsNdBYnoYg@mail.gmail.com>
<CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com>
Date: Wed, 15 Jan 2014 16:05:27 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9q6jdsayldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -0.9 (/)
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 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1W3aSj-0001CD-9W
Cc: "bitcoin-development@lists.sourceforge.net"
<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: Thu, 16 Jan 2014 00:05:34 -0000
------------mQZk93yAj62F69c4eXXgLP
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Might I propose "reusable address".
I think that describes it best to any non-programmer, and even more so
encourages wallets to present options as 'one time use' vs 'reusable'.
It definitely packs a marketing punch which could help drive adoption. The
feature is only useful if/when broadly adopted.
I think it meets all the criteria required:
- Communication between parties is a single message from the payee,
which may be public
- Multiple payments to the same address are not publicly linkable on the
blockchain
- The payee has explicitly designated they expect to receive more than
one payment at that address
- Payer can publicly prove they made a payment to the reusable address
by revealing a secret
I have high hopes for this feature. The war *against* address reuse may
soon be a distant memory.
On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com> wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>> <bendavenport@gmail.com> wrote:
>>> But may I suggest we consider changing the name "stealth address" to
>>> something more neutral?
>>
>> ACK. Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
------------mQZk93yAj62F69c4eXXgLP
Content-Type: multipart/related; boundary=----------mQZk93yAj62F69emOTdz9o
------------mQZk93yAj62F69emOTdz9o
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1389830727295.b30c9d665d6b33c0@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body><div>Might I propose "reusable address".<br><br>I think that descr=
ibes it best to any non-programmer, and even more so encourages wallets =
to present options as 'one time use' vs 'reusable'.</div><div><br></div>=
<div>It definitely packs a marketing punch which could help drive adopti=
on. The feature is only useful if/when broadly adopted.<br><br>I think i=
t meets all the criteria required:</div><div><br></div><div> - Com=
munication between parties is a single message from the payee, which may=
be public</div><div> - Multiple payments to the same address are =
not publicly linkable on the blockchain</div><div> - The payee has=
explicitly designated they expect to receive more than one payment at t=
hat address</div><div> - Payer can publicly prove they made a paym=
ent to the reusable address by revealing a secret</div><div><br></div><d=
iv>I have high hopes for this feature. The war *against* address reuse m=
ay soon be a distant memory.</div><div><br></div><div>On Wed, 15 Jan 201=
4 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com> wrote:<br></div=
><blockquote style=3D"margin: 0 0 0.80ex; border-left: #0000FF 2px solid=
; padding-left: 1ex"><div dir=3D"ltr">"static address" seems like a reas=
onable attempt at describing intended use/direction.<br><br><div class=3D=
"gmail_quote">On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <span dir=
=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gma=
xwell@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Jan 15, 2014=
at 12:22 PM, Ben Davenport <<a href=3D"mailto:bendavenport@gmail.com=
">bendavenport@gmail.com</a>> wrote:<br>
> But may I suggest we consider changing the name "stealth address" t=
o<br>
> something more neutral?<br>
<br>
</div>ACK. Regardless of the 'political' overtones, I think stealt=
h is a<br>
little cringe-worthy.<br>
<br>
"Private address" would be fine if not for confusion with private-keys.<=
br>
<br>
"Static address" is perhaps the best in my view. (also helps improve<br>=
awareness that normal addresses are intended to be more one-use-ne=
ss)</blockquote></div></div></blockquote></body></html>
------------mQZk93yAj62F69emOTdz9o--
------------mQZk93yAj62F69c4eXXgLP--
|
