From: Walter Stanish <walter@stani•sh>
To: "Jorge Timón" <timon.elviejo@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Date: Fri, 16 Dec 2011 13:42:01 +0800 [thread overview]
Message-ID: <CACwuEiM7aDE50yVvKXWikpxXE=ZF1MwsoYo-i4N9KKyFroF2-A@mail.gmail.com> (raw)
In-Reply-To: <CAGQP0AEep1RtaPm6chQh-fLB63tx7Eb9tGq_Obpp003PREt6zw@mail.gmail.com>
>> 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.
next prev parent reply other threads:[~2011-12-16 5:42 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 [this message]
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
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='CACwuEiM7aDE50yVvKXWikpxXE=ZF1MwsoYo-i4N9KKyFroF2-A@mail.gmail.com' \
--to=walter@stani$(echo .)sh \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=timon.elviejo@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