Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=walter.stanish@gmail.com;
	helo=mail-ww0-f53.google.com; 
MIME-Version: 1.0
Sender: walter.stanish@gmail.com
In-Reply-To: <CA+QPp0qGohZO2o-a0D1kxOE==w8keX=uvO_PDcDRHbP=sTTN5w@mail.gmail.com>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<1323979147.27319.140661012141129@webmail.messagingengine.com>
	<CA+QPp0qGohZO2o-a0D1kxOE==w8keX=uvO_PDcDRHbP=sTTN5w@mail.gmail.com>
Date: Fri, 16 Dec 2011 12:32:17 +0800
Message-ID: <CACwuEiN1aWHW+srCPEf4dnyN=+W-QyRF6GgSd9PUjuNxZ1zLxA@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Kyle Henderson <k@old.school.nz>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

> Bitcoin itself is decentralised by design, in my opinion it seems obvious
> that it needs to continue to maintain this feature.

What's the real issue?

 - People want to use alternate representations ('aliases') of bitcoin
addresses, for various reasons.
 - The blockchain is the only way to create distributed consensus
within the bitcoin network.
 - Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
 - Some people want throw-away (single use) aliases, others want
permanent ones.  This means many addresses.
 - Blockchain bloat is already acknowledged as an issue.
 - The blockchain is not really a good option.

Leaving out the blockchain, there are still ways to implement aliasing.

What is the core problem for an extra-blockchain aliasing system?

At the core is usability - people basically want aliases to make it
easier to type in or remember addresses.  So a solution that
sacrifices usability too far is a broken one.

Another requirement is absolute security.  A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default)  of getting it back if it's sent somewhere wrong by
accident'.  Such an accident might be mistyping an alias.  It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.).  As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.

So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.

First, arbitrary aliases are not in use.  This means that memory-based
mnemonics are not subject to predictable squatting-style attacks.  For
our purposes, this means that if you are payments@business1.com, I
can't go and register payments@busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address.  Likewise, if you're 'someuser@hostedwalletservice.com' I
can't go and register as 'someuse@hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.

Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks.  IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!)  With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.

Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction.  This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties.  Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason.  However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)

Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users.  Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
the case of IIBAN which is not specific to any given currency, the
need to register, recall and manage yet another account identifier),
which was one of the original goals. None of the other proposals
mentioned have this property.

I won't go in to other benefits previously mentioned of the IIBAN
proposal, but I still cannot see any reason to either:
 - Include aliasing within bitcoind itself
 - Re-invent the wheel
 - Scare off non-technical users
 - Dodge the fact that there are unique properties of bitcoin that
will always remain and should perhaps simply be acknowledged and
worked around OUTSIDE of the codebase, rather than within.
Unix/internet philosophy is that it's usually best to keep code as
simple as possible, to 'do one thing' and 'do it well'. For bitcoind
(despite sharing a codebase with the GUI), that something is achieving
a distributed internet-based financial system that is free from legacy
centralized currencies. It is *not* worrying about making it look
pretty or easy to use, which can be achieved by layering totally
external systems through simply translating various alternate
representations ('aliases') to the well defined bitcoin addressing
scheme.

Just to avoid any notion of table-banging (Hah! A lost cause?), this
will be the last IIBAN-related post I will make on this thread, but
there will be some further announcements in the near future.

Keep up the good work everyone.

Regards,
Walter Stanish
Payward Inc.