1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <walter.stanish@gmail.com>) id 1RbQYa-0007eA-Qm
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 05:42:08 +0000
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;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RbQYa-0006ZV-1X
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 05:42:08 +0000
Received: by wibhq7 with SMTP id hq7so227977wib.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Dec 2011 21:42:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.102.233 with SMTP id fr9mr10129138wib.40.1324014121917;
Thu, 15 Dec 2011 21:42:01 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.223.69.139 with HTTP; Thu, 15 Dec 2011 21:42:01 -0800 (PST)
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
X-Google-Sender-Auth: ocnAalTYJVEtwvmXuE0xK43E9l8
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
X-Spam-Score: -1.3 (-)
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
0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RbQYa-0006ZV-1X
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2011 05:42:08 -0000
>> 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.
|
