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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <walter.stanish@gmail.com>) id 1RbPT7-0005P5-KN
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 04:32:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=walter.stanish@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1RbPT6-0004OJ-Bb
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 04:32:25 +0000
Received: by wgbds1 with SMTP id ds1so4867247wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Dec 2011 20:32:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.102.233 with SMTP id fr9mr9910722wib.40.1324009938192;
Thu, 15 Dec 2011 20:32:18 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.223.69.139 with HTTP; Thu, 15 Dec 2011 20:32:17 -0800 (PST)
In-Reply-To: <CA+QPp0qGohZO2o-a0D1kxOE==w8keX=uvO_PDcDRHbP=sTTN5w@mail.gmail.com>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<1323979147.27319.140661012141129@webmail.messagingengine.com>
<CA+QPp0qGohZO2o-a0D1kxOE==w8keX=uvO_PDcDRHbP=sTTN5w@mail.gmail.com>
Date: Fri, 16 Dec 2011 12:32:17 +0800
X-Google-Sender-Auth: BRLNeoOPt-pCJXL-23M1W170jJo
Message-ID: <CACwuEiN1aWHW+srCPEf4dnyN=+W-QyRF6GgSd9PUjuNxZ1zLxA@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Kyle Henderson <k@old.school.nz>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.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
1.8 LONGWORDS Long string of long words
X-Headers-End: 1RbPT6-0004OJ-Bb
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [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 04:32:25 -0000
> Bitcoin itself is decentralised by design, in my opinion it seems obvious
> that it needs to continue to maintain this feature.
What's the real issue?
- People want to use alternate representations ('aliases') of bitcoin
addresses, for various reasons.
- The blockchain is the only way to create distributed consensus
within the bitcoin network.
- Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
- Some people want throw-away (single use) aliases, others want
permanent ones. This means many addresses.
- Blockchain bloat is already acknowledged as an issue.
- The blockchain is not really a good option.
Leaving out the blockchain, there are still ways to implement aliasing.
What is the core problem for an extra-blockchain aliasing system?
At the core is usability - people basically want aliases to make it
easier to type in or remember addresses. So a solution that
sacrifices usability too far is a broken one.
Another requirement is absolute security. A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default) of getting it back if it's sent somewhere wrong by
accident'. Such an accident might be mistyping an alias. It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.). As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.
So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.
First, arbitrary aliases are not in use. This means that memory-based
mnemonics are not subject to predictable squatting-style attacks. For
our purposes, this means that if you are payments@business1.com, I
can't go and register payments@busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address. Likewise, if you're 'someuser@hostedwalletservice.com' I
can't go and register as 'someuse@hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.
Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks. IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!) With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.
Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction. This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties. Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason. However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)
Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users. Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
the case of IIBAN which is not specific to any given currency, the
need to register, recall and manage yet another account identifier),
which was one of the original goals. None of the other proposals
mentioned have this property.
I won't go in to other benefits previously mentioned of the IIBAN
proposal, but I still cannot see any reason to either:
- Include aliasing within bitcoind itself
- Re-invent the wheel
- Scare off non-technical users
- Dodge the fact that there are unique properties of bitcoin that
will always remain and should perhaps simply be acknowledged and
worked around OUTSIDE of the codebase, rather than within.
Unix/internet philosophy is that it's usually best to keep code as
simple as possible, to 'do one thing' and 'do it well'. For bitcoind
(despite sharing a codebase with the GUI), that something is achieving
a distributed internet-based financial system that is free from legacy
centralized currencies. It is *not* worrying about making it look
pretty or easy to use, which can be achieved by layering totally
external systems through simply translating various alternate
representations ('aliases') to the well defined bitcoin addressing
scheme.
Just to avoid any notion of table-banging (Hah! A lost cause?), this
will be the last IIBAN-related post I will make on this thread, but
there will be some further announcements in the near future.
Keep up the good work everyone.
Regards,
Walter Stanish
Payward Inc.
|
