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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timon.elviejo@gmail.com>) id 1Rb9An-0008Fo-5M
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Dec 2011 11:08:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=timon.elviejo@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Rb9Ah-0003QW-I0
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Dec 2011 11:08:25 +0000
Received: by wgbds1 with SMTP id ds1so3409925wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Dec 2011 03:08:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.131.90 with SMTP id l68mr521574wei.36.1323947293421; Thu,
15 Dec 2011 03:08:13 -0800 (PST)
Received: by 10.223.81.79 with HTTP; Thu, 15 Dec 2011 03:08:13 -0800 (PST)
In-Reply-To: <CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@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>
Date: Thu, 15 Dec 2011 12:08:13 +0100
Message-ID: <CAGQP0AEep1RtaPm6chQh-fLB63tx7Eb9tGq_Obpp003PREt6zw@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
To: Walter Stanish <walter@stani.sh>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.2 (-)
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
(timon.elviejo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rb9Ah-0003QW-I0
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: Thu, 15 Dec 2011 11:08:25 -0000
2011/12/15, Walter Stanish <walter@stani.sh>:
> 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.
-The servers stores the recipient private keys and generates a new one
for each payment.
-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).
> It *is* true that under the current IIBAN proposal there would be one
> entity (IANA) in charge of issuing namespace portions ('institution
> codes' - probably best to rename these...), however:
> ...
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.
" * 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.
I can't find the answer of Gavin's question "How is the mapping done?"
in your post. I'll re-read it though.
|
