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; 
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
Precedence: list

------------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>&nbsp; - Com=
munication between parties is a single message from the payee, which may=
 be public</div><div>&nbsp; - Multiple payments to the same address are =
not publicly linkable on the blockchain</div><div>&nbsp; - The payee has=
 explicitly designated they expect to receive more than one payment at t=
hat address</div><div>&nbsp; - 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 &lt;jgarzik@bitpay.com&gt; 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">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gma=
xwell@gmail.com</a>&gt;</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 &lt;<a href=3D"mailto:bendavenport@gmail.com=
">bendavenport@gmail.com</a>&gt; wrote:<br>

&gt; But may I suggest we consider changing the name "stealth address" t=
o<br>
&gt; something more neutral?<br>
<br>
</div>ACK. &nbsp;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>=
&nbsp;awareness that normal addresses are intended to be more one-use-ne=
ss)</blockquote></div></div></blockquote></body></html>
------------mQZk93yAj62F69emOTdz9o--

------------mQZk93yAj62F69c4eXXgLP--