Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175; envelope-from=walter.stanish@gmail.com;
	helo=mail-wi0-f175.google.com; 
MIME-Version: 1.0
Sender: walter.stanish@gmail.com
In-Reply-To: <CAGQP0AEep1RtaPm6chQh-fLB63tx7Eb9tGq_Obpp003PREt6zw@mail.gmail.com>
References: <CA+QPp0rAJz9wPcrf926q=_c45mCL_67JCyacvM79CWcic9AL2w@mail.gmail.com>
	<1323929094.37881.YahooMailClassic@web120902.mail.ne1.yahoo.com>
	<CACwuEiPbLdpgYCcTHH_GCHcwGcGj5HnOMFKkQf860D4Xn0mLsQ@mail.gmail.com>
	<CAGQP0AFD9q+=vZPod_n_LJjCjzVnVy5w3hq4N07JZRM6=Ly-FQ@mail.gmail.com>
	<CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@mail.gmail.com>
	<CAGQP0AEep1RtaPm6chQh-fLB63tx7Eb9tGq_Obpp003PREt6zw@mail.gmail.com>
Date: Fri, 16 Dec 2011 13:42:01 +0800
Message-ID: <CACwuEiM7aDE50yVvKXWikpxXE=ZF1MwsoYo-i4N9KKyFroF2-A@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Precedence: list

>> Interaction is a requirement, since there seems to be a widely felt
>> need to preserve anonymity through the use of temporary addresses.
>> Generating a temporary address requires some actual processing to
>> achieve, since the issuing of the new address cannot be done without
>> interacting with the entity hosting the wallet (unless I'm missing
>> something?).
>
> I thought the interaction was just the server answering with an
> address (maybe also amount and other details). But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.

Sure, but this falls short of requirements for most users.

> -The servers stores the recipient private keys and generates a new one
> for each payment.

Equivalent to hosted wallet, which is decentralization in a BIG way,
but apparently a very popular choice (for pragmatic reasons).
Probably not going away.

> -The server stores a set of addresses provided by the recipient and it
> manages what address it gives in each request (like in the web service
> I told you I can't find).

True.  However, probably a poor user experience for most users re:
provision of temporary addresses to the alias host.  Also the
knowledge of which entity for which inbound payment has been allocated
which temporary address would be a significant complexity in the alias
host / end user relationship that you gloss over.  This is important
for businesses, since inbound payments are only really possible to
track - AFAIK (correct me if I'm wrong, the two exceptions being the
edge case of people requesting inbound transactions where every single
transaction is of a unique amount and no 'partial payment' (2x
transactions for one inbound payment) and the case where every single
inbound payer's sending address is previously known) - by issuing
unique recipient addresses to each client.  In short, it's kind of
similar to hosted wallet as well, since you need to absolutely trust
your host (they could tell people wishing to make payments to you to
pay someone else instead!).

> IANA reserves some namespace for bitcoin. All right.
> The problem comes later.
> "
> * 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').
> "
> As I understand it (probably I'm wrong, because I haven't read the
> whole IIBAN draft) there would be a "bitcoin institution" that would
> map bitcoin addresses to the bitcoin subspace of the IIBAN.

Many people can get namespace management rights as
'institutions' (in the current draft's terminology), then manage
the assignement of IIBANs within that space as they wish.
There would be many institutions with many IIBANs.  The
association of a bitcoin address (or many addresses, or
the capacity to generate temporary addresses as required)
with an IIBAN would be the responsibility of either that
namespace manager ('institution') or the individual who
has acquired that IIBAN via that namespace manager
('insitution').

> "    * IANA MAY delegate management of portions of the IIBAN name space
>      through such institutions."
>
> If we can find a deterministic method to map the subspace the all
> possible bitcoin addresses, everything's fine again. But if that's not
> possible, we would need a central institution to manage the mapping
> and that would be a step back in decentralization.

Many institutions, many policies, no absolute centralization, though
admittedly increased centralization. However, this is a problem shared
with two of your proposals (the subset not disqualified as failing to
meet most user's requirements) when you consider that most users (if
you consider 'the whole world's mobile devices' a potential userbase,
as I prefer to do) do not have the technical skills to configure,
secure and manage their own 'always on' alias service hosts, nor the
capacity to host blockchain copies on those devices (either due to
space or bandwidth requirements. As an aside, this is a large part of
the unfortunate reality that is tending to push Bitcoin towards hosted
wallet solutions)

> I can't find the answer of Gavin's question "How is the mapping done?"
> in your post. I'll re-read it though.

Near the top, beginning "It seems a clarification is in order,
apologies for not being clearer."  (Re-reading, it's still not that
clear!)

Regards,
Walter Stanish
Payward, Inc.