Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W3Wyw-0002IY-FQ for bitcoin-development@lists.sourceforge.net; Wed, 15 Jan 2014 20:22:34 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.181 as permitted sender) client-ip=209.85.214.181; envelope-from=bendavenport@gmail.com; helo=mail-ob0-f181.google.com; Received: from mail-ob0-f181.google.com ([209.85.214.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W3Wys-0003mt-MN for bitcoin-development@lists.sourceforge.net; Wed, 15 Jan 2014 20:22:34 +0000 Received: by mail-ob0-f181.google.com with SMTP id uy5so1689394obc.26 for ; Wed, 15 Jan 2014 12:22:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.47.116 with SMTP id c20mr3486807oen.60.1389817345257; Wed, 15 Jan 2014 12:22:25 -0800 (PST) Received: by 10.76.122.80 with HTTP; Wed, 15 Jan 2014 12:22:25 -0800 (PST) In-Reply-To: References: <20140106120338.GA14918@savin> <20140110102037.GB25749@savin> <20140113133746.GI38964@giles.gnomon.org.uk> <20140114225321.GT38964@giles.gnomon.org.uk> Date: Wed, 15 Jan 2014 12:22:25 -0800 Message-ID: From: Ben Davenport To: Drak Content-Type: multipart/alternative; boundary=047d7b450dc02ac7dc04f0081155 X-Spam-Score: -0.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 (bendavenport[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1W3Wys-0003mt-MN Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:22:34 -0000 --047d7b450dc02ac7dc04f0081155 Content-Type: text/plain; charset=ISO-8859-1 Love what's happening here, and how quickly things are moving, from initial concept, to first implementation, to first transaction. But may I suggest we consider changing the name "stealth address" to something more neutral? Already, many people on Reddit and elsewhere are misinterpreting the purpose of such addresses, whether for tax evasion, criminal activity, or who knows what. Bitcoin already has plenty of political hurdles based sheerly on the technology. We don't need to make life harder for ourselves. Even forgetting about politics, the "stealth" association just seems to imply something secretive going on. Is a Fortune 500 company or worldwide charity going to want to use something called a "stealth address"? I'd propose the alternate term "routing address". - It's a descriptive, neutral term - It accurately describes what the address is: it's a way to route payment to a recipient, but not the actual final address - It can be analogized to a bank's routing number: It is uniquely, publicly and persistently tied to the receiving institution. The payor and payee knows when payment is made using it, but it's not publicly visible. That's the best I've got, but here are some alternate terms in case that doesn't work: - reusable public address - permanent public address - permanent address - static address I don't like these quite as much because they're not as clear. Normal addresses are all reusable, permanent and static -- they just _shouldn't_ be used that way. Ben On Tue, Jan 14, 2014 at 4:19 PM, Drak wrote: > Sorry this is possibly OT, but someone posted this thread to r/bitcoin and > it's gone straight to position 1. People are really enthusiastic about this > feature. > > Drak > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --047d7b450dc02ac7dc04f0081155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Love what's happening here, and how quickly things are= moving, from initial concept, to first implementation, to first transactio= n.

But may I suggest we consider changing the name "= ;stealth address" to something more neutral?

Already, many people on Reddit and elsewhere are misint= erpreting the purpose of such addresses, whether for tax evasion, criminal = activity, or who knows what. Bitcoin already has plenty of political hurdle= s based sheerly on the technology. We don't need to make life harder fo= r ourselves. Even forgetting about politics, the "stealth" associ= ation just seems to imply something secretive going on. Is a Fortune 500 co= mpany or worldwide charity going to want to use something called a "st= ealth address"?

I'd propose the alternate term "routing addres= s".

- It's a descriptive, neutral term
- It accurately describes what the address is: it's a way to ro= ute payment to a recipient, but not the actual final address
- It can be analogized to a bank's routing number: It is uniquely,= publicly and persistently tied to the receiving institution. The payor and= payee knows when payment is made using it, but it's not publicly visib= le.

That's the best I've got, but here are some alt= ernate terms in case that doesn't work:

- reus= able public address
- permanent public address
- perman= ent address
- static address

I don't like these quite= as much because they're not as clear. Normal addresses are all reusabl= e, permanent and static -- they just _shouldn't_ be used that way.

Ben


On Tue, Jan 14, 2014 at 4:19 PM, Drak <drak@zikula.org= > wrote:
= Sorry this is possibly OT, but someone posted this thread to r/bitcoin and = it's gone straight to position 1. People are really enthusiastic about = this feature.

Drak

-----------------------------------------------------------------------= -------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D119420431&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7b450dc02ac7dc04f0081155--