From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RaUhy-0001R3-JE for bitcoin-development@lists.sourceforge.net; Tue, 13 Dec 2011 15:55:58 +0000 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; Received: from mail-iy0-f175.google.com ([209.85.210.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RaUhs-0004P3-QZ for bitcoin-development@lists.sourceforge.net; Tue, 13 Dec 2011 15:55:58 +0000 Received: by iadj38 with SMTP id j38so13187527iad.34 for ; Tue, 13 Dec 2011 07:55:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.17.165 with SMTP id p5mr19945713igd.84.1323791747596; Tue, 13 Dec 2011 07:55:47 -0800 (PST) Sender: walter.stanish@gmail.com Received: by 10.42.151.69 with HTTP; Tue, 13 Dec 2011 07:55:47 -0800 (PST) In-Reply-To: References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com> <201112121841.39864.luke@dashjr.org> <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Tue, 13 Dec 2011 23:55:47 +0800 X-Google-Sender-Auth: v1kODiLPbnijglAxMP2RMSX92qg Message-ID: From: Walter Stanish To: Christian Decker Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.5 (-) 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 (walter.stanish[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1RaUhs-0004P3-QZ Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 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: Tue, 13 Dec 2011 15:55:58 -0000 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.