Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish <walter@stani.sh>]

> Nifty!  Thanks for the pointers, I think we should avoid reinventing
> wheels whenever possible.

Hear hear!

> When composing my last response in this thread I wrote, and then erased:
>
> "There doesn't have to be one solution: I'd like to see some
> experimentation, with clients supporting different schemes for bitcoin
> address aliases, and maybe supporting plugins to extend the schemes
> supported (a plugin would take a string, do some
> behind-the-scenes-magic, and return a bitcoin address or public key)."

Sure. Alias systems are a usability focused requirement and as such
should probably not be mandated by the network itself, anyway.

> Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts",
> seems like a forward-thinking idea, although I'm not clear on exactly
> how those 2.2billion "accounts" would get allocated and mapped into
> bitcoin addresses.

It seems a clarification is in order, apologies for not being clearer.

Under the IIBAN scheme, whilst Bitcoin *could* define some default
mechanism for automatically creating IIBANs that map to Bitcoin
addresses (for example, Bitcoin client authors could provide hosted
lookup), this was not the style of integration in mind while writing
the IIBAN draft.

Rather than simply defining Bitcoin as a single 'institution'
(namespace segment) within the IIBAN standard, Payward Inc. envisages
large numbers of parties (including individuals or small groups of
individuals) operating individual Bitcoin-related (or LETS, or other
alternate currency) services to register as institutions (really just
'namespace holders') within the IIBAN registry. Each such party may
then define its own mapping system between Bitcoin, LETS, or other
alternate currency financial endpoints that it 'manages' (proxies for)
and IIBAN, within its namespace.  As detailed within the IIBAN
proposal, this process could be peer to peer or centralized,
supporting one time or short-term use addresses as well as permanent
addresses.  A permanent address within IIBAN could map via the
institution managing that portion of the IIBAN address space to a
single use address on the Bitcoin network.

Institutions are important for the following reasons (from
http://tools.ietf.org/html/draft-iiban-00#section-4.3.2):

   With the advent of decentralized virtual currencies such as [BITCOIN]
   the conventional idea of a financial institution (such as a bank) may
   be seen by some as somewhat superfluous.  However, the notion remains
   useful:

    * Conventional currencies will not disappear in the conceivable
      future, so the notion of financial institutions is expected
      to endure at least as providers of currency exchange and holding
      services.

    * Systems such as [BITCOIN] have quirks that require slightly
      delayed settlement due to the nature of their decentralized,
      consensus-based approach to fiscal transfer.  Users requiring
      instant settlement MAY thus see benefit in the use of a
      centralized proxy system or organization as an instantaneous
      financial settlement provider (the 'institution').

    * IANA MAY delegate management of portions of the IIBAN name space
      through such institutions.

Furthermore from http://tools.ietf.org/html/draft-iiban-00#section-4.3.1:

   [Under IIBAN's combined issue paradigm] proxied issue is
   facilitated through IANA managed institution registration, provision
   for two types of privately issued addresses is reserved within this
   document, and registered institutions COULD provide DHT or similar
   mechanisms for the management of their delegated name space.  The
   combined issue paradigm offers adequate provision for both
   manageability and decentralization, whilst maintaining heterogeneity.

So the idea is that many institutions each provide mappings between
IIBAN and Bitcoin, in a range of ways, and we do not see the emergence
of a single mandated standard.  There is no suggestion that Bitcoin
developers should implement a hard-coded mechanism.

> I imagine some central organization that maps IIBAN account numbers to
> domain names... and then clients (or plugins in the clients) query
> that trusted central organization and then the account holder's domain
> to get a (possibly unique) public key or bitcoin address.

This style of solution - in which a central organization becomes aware
of every single IIBAN-based transaction in the network - is not
necessary or desirable.  Instead, under the IIBAN recommendation IANA
would publish the registry of IIBAN institutions for everyone to use
without the need to query any party.

In the case of a financial transfer, a client or peer instutition
seeking to send funds to an IIBAN-denominated address would use some
hitherto-underfined mechanism* for translating the appropriate entry
within that registry (corresponding to the transfer's destination
address) to some kind of internet node representing the institution's
systems.

* This mechanism may necessitate the storage of public keys within the
IIBAN institution registry and will be addressed within the next
version of the IIBAN draft.  Community input is encouraged.

In a second yet-to-be-define protocol**, various settlement-system
neutral (ie: not specific to Bitcoin, LETS, or any other system)
transaction-related metadata would then be exchanged, prior to any
actual transaction.  Such metadata could include aspects of the
transaction such as description, financial system endpoint ('account')
holder name, account exists verification, settlement path negotiation
(based upon feasibility, transaction overheads, latency, etc.), which
party is to pay overheads, information mandated by local jurisdiction
such as business tax numbers (required in some countries of Europe, I
believe, for domestic B2B settlements), etc.

** This mechanism does need to be defined, and Payward Inc. has
completed a not insubstantial amount of research in to existing
protocols and concerns within this area, which touches upon high
frequency automated banking, financial market support, and interbank
settlement policy.  An additional Internet Draft proposing one such
potential mechanism will probably be published 'soon'.

At the conclusion of this metadata exchange, the two nodes would have
either aborted the transaction, suspended it to seek human input (such
as settlement path selection based upon fee and latency metadata
garnered), or agreed upon financial settlement system specific
information to use in executing the transaction itself, likely out of
band. In the case of Bitcoin, this *might* include information such as
the blockcount after which the transaction will be considered settled
by the receiving institution, an effective 'gentleman's agreement' on
the terms of any opt-in notion of reversibility, a one time Bitcoin
address provided by the recipient institution for the sender to make a
Bitcoin transaction to, etc.

From the perspective of a settlement system such as Bitcoin, IIBAN's
provision of settlement system neutral financial endpoint
identification provides the benefits outlined in the previous email,
as well as the possibility to publish a permanent, fixed address
without disclosing one's corresponding Bitcoin-derived income.  From
the broader perspective of effective financial system innovation, it
hopes to provide a common basis upon which many such systems can
conceivably interoperate, regardless of their underlying systemic
differences.

> As long as IIBANs are not the ONLY way of aliasing bitcoin addresses
> to more-human-friendly strings I think that would be a fine way to do
> it.

Thank you for your vote of confidence.

Regards,
Walter Stanish
Payward Inc.