📅 Original date posted:2011-12-13
🗒️ Summary of this message: IIBAN, an Internet Standards Draft, proposes a solution for translating human-readable addresses into Bitcoin addresses, with mature error detection and a fixed length.
📝 Original message: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.
Walter Stanish [ARCHIVE] /
npub1w7…wj55c
2023-06-07 02:48:29
in reply to nevent1q…kkuw
Author Public Key
npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55cPublished at
2023-06-07 02:48:29Event JSON
{
"id": "5d03107c5636d13907de10fdee41561f9608c4fafeb96c98911e715675bfea6b",
"pubkey": "77979142f3407f28a5a71956e33342e486ee981e614e0d2ea36ddaf27b8a5a67",
"created_at": 1686106109,
"kind": 1,
"tags": [
[
"e",
"f45e7ca88e6eb3dd1e645e8e3cbb476c5b24e8003cb71eebe205594bb2a4d152",
"",
"root"
],
[
"e",
"9a9da9f5c38421c3ca904d098029bb5f44451906d8046abd5c4f9b8c0de6dfbd",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2011-12-13\n🗒️ Summary of this message: IIBAN, an Internet Standards Draft, proposes a solution for translating human-readable addresses into Bitcoin addresses, with mature error detection and a fixed length.\n📝 Original message:Interesting thread.\n\nGiven the following paragraph and the limited feedback garnered upon\nits announcement to this list last month, I couldn't help but chime in\nagain to mention IIBAN, an Internet Standards Draft available at\nhttp://tools.ietf.org/html/draft-iiban-00 (A related proposal for\ninternet connected financial market identification, IMIC, is also\navailable: http://tools.ietf.org/html/draft-imic-00) which - fair\ndeclaration of bias - I authored on behalf of my employer, Payward\nInc., while working on Bitcoin-related development.\n\n\u003e I think the scope of this BIP is not so well defined right now. We need a\n\u003e way for merchants to translate a human readable, and more importantly\n\u003e human-writeable, address into a bitcoin address.\n\nI believe that IIBAN solves this problem fairly elegantly:\n\n(1) Mature transposition error detection (think \"Oops, that's a zero\nnot an 'oh'! I wrote it wrong!\"). This functions via checksum digits\nusing a known algorithm, leveraging decades of experience in\nconventional financial institutions. The same functionality provides\nfor simple suggested error correction on common transposition errors\n(0-\u003eO, 1-\u003eI, etc.).\n\n(2) Fixed length.\n\n(3) Far shorter than both bitcoin addresses and many national bank\naccount numbers at 13 characters (less than half of the size of a\nbitcoin address).\n\n(4) Fewer characters (no lowercase), resulting in less transposition\nissues and greater legibility.\n\n(5) Superset-compatible with existing financial networks utilizing the\nIBAN standard (mandated in Europe, increasingly popular elsewhere),\nresulting in greater ease of uptake.\n\n(5) Centralized, delegatable namespace allocation but with clear rules\ngoverning allocation that aim to minimize potential room for any\npotential abuse of power.\n\n(6) Settlement system neutral - ie: not bitcoin-centric. By leaving\nBitcoin to be Bitcoin, Bitcoin developers can focus on core concerns\nrather than becoming embroiled in formatting and user experience\nconcerns. Also, a single address could be paid via multiple channels\n(conventional financial systems, bitcoin, LETS systems, etc.)\nresulting in greater ease of uptake and higher user confidence over\ntime since published banking information is no longer held hostage to\nthe assumed longevity, liquidity, legality or other liabilities of an\nindividual settlement system (such as Bitcoin).\n\n(7) Provides defined private address spaces for internal transfers\n(eg: within an organization's own systems, for financial simulations,\nMMORPGs, etc.) and a documentation/public works of fiction address\nspace to address common usage concerns in similar network addressing\nschemes.\n\n(8) Heterogeneous management of different parts of the address space.\n\nWhilst the proposed IANA (Internet Assigned Numbers Authority)\nmanagement of IIBAN's initial institution namespace is indeed\ncentralized and will no doubt raise eyebrows from within parts of the\ncommunity for that reason alone, the IIBAN draft is liberal in its\nassignment policy, which can be viewed within the draft document\nlinked to above, and whose terms are binding for IANA. It's also\nworth noting that four of the most similar global systems deployed\ntoday, SWIFT's BIC and IBAN, the ITU's E.164 international telephone\nnumbering scheme and IANA's IP address space management are\nimplemented as similar centralized-but-delegated style schemes.\n\nFurthermore, due to the flat nature of the registry, a\nhttp://convergence.io/ style 'trust agility' model (ie: multiple\n'centralized' parties share their network view, and user-prioritized\nsource consensus/acceptance/approval determine end-user perspective)\nis wholly compatible.\n\nIn closing, a quick mention that a new version of the IIBAN draft will\nbe released very shortly including a draft IIBAN institutions registry\nthat will be established in order to facilitate implementation and\ntesting. Drop me an email if you'd like a portion of the address space\nand your early assignment will appear within that draft.\n\nRegards,\nWalter Stanish\nPayward, Inc.",
"sig": "8e61b8f6e448791a59284298c861ece9b8f2dea7192db19125f7ca3819ac8180911c67a67b934586d376847690261288c9c4ca19cc29d2faa17228fda6db0b97"
}