Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.175 as permitted sender)
	client-ip=209.85.210.175; envelope-from=walter.stanish@gmail.com;
	helo=mail-iy0-f175.google.com; 
MIME-Version: 1.0
Sender: walter.stanish@gmail.com
In-Reply-To: <CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
	<CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
	<201112121841.39864.luke@dashjr.org>
	<CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
	<CAGQP0AGY32QP=rXyGftb5NbHA7fhcCne7W=pt5+onXp1Jbm98Q@mail.gmail.com>
	<1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com>
	<CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com>
Date: Tue, 13 Dec 2011 23:55:47 +0800
Message-ID: <CACwuEiNO=pSfgD415-5=HnaXdXbZ++Ps0n4cyjckLRRP-tJemA@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Precedence: list

Interesting thread.

Given the following paragraph and the limited feedback garnered upon
its announcement to this list last month, I couldn't help but chime in
again to mention IIBAN, an Internet Standards Draft available at
http://tools.ietf.org/html/draft-iiban-00 (A related proposal for
internet connected financial market identification, IMIC, is also
available: http://tools.ietf.org/html/draft-imic-00) which - fair
declaration of bias - I authored on behalf of my employer, Payward
Inc., while working on Bitcoin-related development.

> I think the scope of this BIP is not so well defined right now. We need a
> way for merchants to translate a human readable, and more importantly
> human-writeable, address into a bitcoin address.

I believe that IIBAN solves this problem fairly elegantly:

(1) Mature transposition error detection (think "Oops, that's a zero
not an 'oh'! I wrote it wrong!"). This functions via checksum digits
using a known algorithm, leveraging decades of experience in
conventional financial institutions. The same functionality provides
for simple suggested error correction on common transposition errors
(0->O, 1->I, etc.).

(2) Fixed length.

(3) Far shorter than both bitcoin addresses and many national bank
account numbers at 13 characters (less than half of the size of a
bitcoin address).

(4) Fewer characters (no lowercase), resulting in less transposition
issues and greater legibility.

(5) Superset-compatible with existing financial networks utilizing the
IBAN standard (mandated in Europe, increasingly popular elsewhere),
resulting in greater ease of uptake.

(5) Centralized, delegatable namespace allocation but with clear rules
governing allocation that aim to minimize potential room for any
potential abuse of power.

(6) Settlement system neutral - ie: not bitcoin-centric. By leaving
Bitcoin to be Bitcoin, Bitcoin developers can focus on core concerns
rather than becoming embroiled in formatting and user experience
concerns. Also, a single address could be paid via multiple channels
(conventional financial systems, bitcoin, LETS systems, etc.)
resulting in greater ease of uptake and higher user confidence over
time since published banking information is no longer held hostage to
the assumed longevity, liquidity, legality or other liabilities of an
individual settlement system (such as Bitcoin).

(7) Provides defined private address spaces for internal transfers
(eg: within an organization's own systems, for financial simulations,
MMORPGs, etc.) and a documentation/public works of fiction address
space to address common usage concerns in similar network addressing
schemes.

(8) Heterogeneous management of different parts of the address space.

Whilst the proposed IANA (Internet Assigned Numbers Authority)
management of IIBAN's initial institution namespace is indeed
centralized and will no doubt raise eyebrows from within parts of the
community for that reason alone, the IIBAN draft is liberal in its
assignment policy, which can be viewed within the draft document
linked to above, and whose terms are binding for IANA.  It's also
worth noting that four of the most similar global systems deployed
today, SWIFT's BIC and IBAN, the ITU's E.164 international telephone
numbering scheme and IANA's IP address space management are
implemented as similar centralized-but-delegated style schemes.

Furthermore, due to the flat nature of the registry, a
http://convergence.io/ style 'trust agility' model (ie: multiple
'centralized' parties share their network view, and user-prioritized
source consensus/acceptance/approval determine end-user perspective)
is wholly compatible.

In closing, a quick mention that a new version of the IIBAN draft will
be released very shortly including a draft IIBAN institutions registry
that will be established in order to facilitate implementation and
testing. Drop me an email if you'd like a portion of the address space
and your early assignment will appear within that draft.

Regards,
Walter Stanish
Payward, Inc.