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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
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 <walter.stanish@gmail.com>) id 1Raebl-00041x-DA
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Dec 2011 02:30:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=walter.stanish@gmail.com;
helo=mail-iy0-f175.google.com;
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Raebh-0006lC-W9
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Dec 2011 02:30:13 +0000
Received: by iadj38 with SMTP id j38so648399iad.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 13 Dec 2011 18:30:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.217.199 with SMTP id pa7mr16402220igc.48.1323829804642;
Tue, 13 Dec 2011 18:30:04 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.42.151.69 with HTTP; Tue, 13 Dec 2011 18:30:04 -0800 (PST)
In-Reply-To: <CABsx9T3g=27QwQaoBKKJ2ckZhOUVMokRYNDq9yRXfGzVQOuFJg@mail.gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
<CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
<201112121841.39864.luke@dashjr.org>
<CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
<CAGQP0AGY32QP=rXyGftb5NbHA7fhcCne7W=pt5+onXp1Jbm98Q@mail.gmail.com>
<1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com>
<CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com>
<CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com>
<CACwuEiNO=pSfgD415-5=HnaXdXbZ++Ps0n4cyjckLRRP-tJemA@mail.gmail.com>
<CABsx9T3g=27QwQaoBKKJ2ckZhOUVMokRYNDq9yRXfGzVQOuFJg@mail.gmail.com>
Date: Wed, 14 Dec 2011 10:30:04 +0800
X-Google-Sender-Auth: CsHOo2N1W_00f-QSAeWEIDZLlM0
Message-ID: <CACwuEiMTexatUaccpgfiqq48gr2swCfWDZCc772XCmN=G-VD-Q@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.5 TVD_PH_BODY_ACCOUNTS_PRE BODY: TVD_PH_BODY_ACCOUNTS_PRE
-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.8 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Raebh-0006lC-W9
Cc: "bitcoin-development@lists.sourceforge.net"
<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: Wed, 14 Dec 2011 02:30:13 -0000
> Nifty! =A0Thanks 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.
|
