From: Walter Stanish <walter@stani•sh>
To: Christian Decker <decker.christian@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Date: Tue, 13 Dec 2011 23:55:47 +0800 [thread overview]
Message-ID: <CACwuEiNO=pSfgD415-5=HnaXdXbZ++Ps0n4cyjckLRRP-tJemA@mail.gmail.com> (raw)
In-Reply-To: <CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com>
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.
next prev parent reply other threads:[~2011-12-13 15:55 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 23:16 [Bitcoin-development] " Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
[not found] ` <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
2011-12-13 0:00 ` [Bitcoin-development] Fwd: " Jorge Timón
2011-12-13 0:42 ` Amir Taaki
2011-12-13 2:32 ` Daniel F
2011-12-13 2:37 ` Amir Taaki
2011-12-13 2:43 ` Luke-Jr
2011-12-13 2:52 ` Daniel F
2011-12-13 10:55 ` Mike Hearn
2011-12-13 11:42 ` Christian Decker
2011-12-13 12:32 ` Jorge Timón
2011-12-13 13:06 ` Gavin Andresen
2011-12-13 15:46 ` Amir Taaki
2011-12-13 16:22 ` Andy Parkins
2011-12-14 19:22 ` D.H.
2011-12-14 20:07 ` Luke-Jr
2011-12-14 20:17 ` D.H.
2011-12-14 20:21 ` Joel Joonatan Kaartinen
2011-12-14 22:51 ` Jorge Timón
2011-12-14 23:02 ` Rick Wesson
2011-12-14 23:27 ` Luke-Jr
2011-12-15 1:22 ` Rick Wesson
2011-12-15 3:57 ` Zell Faze
2011-12-15 4:56 ` Kyle Henderson
2011-12-15 6:04 ` Zell Faze
2011-12-15 6:41 ` Walter Stanish
2011-12-15 7:45 ` Jordan Mack
2011-12-15 7:52 ` Jorge Timón
2011-12-15 7:48 ` Jorge Timón
2011-12-15 8:26 ` Walter Stanish
2011-12-15 10:01 ` Andy Parkins
2011-12-15 11:08 ` Jorge Timón
2011-12-15 11:22 ` Christian Decker
2011-12-16 5:42 ` Walter Stanish
2011-12-16 8:46 ` Pieter Wuille
2011-12-15 15:44 ` Rick Wesson
2011-12-15 15:42 ` Rick Wesson
2011-12-16 0:07 ` slush
2011-12-16 15:52 ` Rick Wesson
2011-12-16 16:36 ` slush
2011-12-16 17:10 ` Andy Parkins
2011-12-16 17:41 ` Rick Wesson
2011-12-16 18:29 ` Amir Taaki
2011-12-16 19:06 ` Gavin Andresen
2011-12-16 19:22 ` Rick Wesson
2011-12-16 20:58 ` Andy Parkins
2011-12-16 20:54 ` Andy Parkins
2011-12-16 21:50 ` Rick Wesson
2011-12-13 15:47 ` Luke-Jr
2011-12-16 17:36 ` Khalahan
2011-12-16 17:48 ` Gregory Maxwell
2011-12-13 15:55 ` Walter Stanish [this message]
2011-12-13 16:15 ` Jorge Timón
2011-12-13 16:48 ` Gavin Andresen
2011-12-14 2:30 ` Walter Stanish
2011-12-13 2:39 ` [Bitcoin-development] " Stefan Thomas
2011-12-12 23:52 ` Matt Corallo
2011-12-12 23:37 ` Will
[not found] <9109000381434268897@unknownmsgid>
2011-12-13 8:55 ` [Bitcoin-development] Fwd: " Cameron Garnham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACwuEiNO=pSfgD415-5=HnaXdXbZ++Ps0n4cyjckLRRP-tJemA@mail.gmail.com' \
--to=walter@stani$(echo .)sh \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=decker.christian@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox