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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RbTGf-0007qa-PR
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 08:35:49 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RbTGd-0005Z4-Du for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 08:35:49 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 138A2128029.A87CF
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 138A2128029
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 09:35:40 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id BE25531E703
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 09:35:39 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id D6BF610052
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 10:36:03 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id DB71B87C1AB; Fri, 16 Dec 2011 09:35:38 +0100 (CET)
Date: Fri, 16 Dec 2011 09:35:38 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111216083536.GA20470@ulyssis.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RbTGd-0005Z4-Du
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 08:35:49 -0000
On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:
> I wrote this pre-draft:
>
>
> https://en.bitcoin.it/wiki/BIP_0015
>
> It's merely a starter for discussions.
Interesting discussion so far, with many nice ideas.
I'll try to give my opinion and comment on some in batch here.
First of all, I'm a big proponent of moving away from using base58 strings
as addresses. They are not flexible and not human-friendly. I did an own
proposal to improve the situation some time ago, see
https://gist.github.com/1237788
There was little reaction, and maybe the reason is we shouldn't try to solve/fix
everything at once.
a) IP transactions-like system with DNS resolution
Not only does this give you nice identifiers, but it also moves the
responsibility of getting the transaction accepted by the network from the
sender to the receiver - the one who actually cares about getting his
money.
The authentication problem that was present in the original IP transactions
system can either be mitigated by trusting the existing SSL public-key
intrastructure (which not everyone may like) or (as Satoshi suggested) adding
bitcoin address-based authentication on top (separate from the address used in
the transaction itself). So you get an identifier like <url>$<btcaddress>, and
the communication to <url> would be authenticated using <btcaddress>. This
is obviously not useful as human-typable alias, but is no problem for
clickable URLs on websites that want to provide the additional security.
I'm not sure about using the bitcoin p2p protocol here - i think there are
easier (or at least more widely deployed) protocols like HTTP. So maybe ...
b) HTTPS Web Service
we can just use an HTTPS web service, that provides the bitcoin address to
be used in the transaction to a client that queries a URL. This immediately
makes the identifier double as a clickable URL, and a merchant could add
metadata to the URL to make the transaction easily trackable.
As for the possibility for spoofing: relying on DNSSEC is currently
difficult i believe (though i'm not entirely up-to-date about its
deployment). Again, alternatives are the SSL PKI, or bitcoin address-based
authentication (basically doing SSL but using bitcoin pubkeys to
authenticate)
c) user@hostname-like identifiers
These look very good, and conveniently match the e-mail system's identifiers.
However, I believe they are only useful for one purpose: user-to-user
payments. For anything somewhat more business-y you probably want to use
a clickable URL, and hide all address information entirely from the user.
Still, for user-to-user payments they are nice.
I'm not convinced about the hardcoding of the "https://" and
"/bitcoin-alias/?handle=" parts, though. These seem very arbitrarily
chosen to me, but if you consider an HTTPS-based variant of a bitcoin
ip-transactions-like system, the proposed "account" parameter to
checkorder would probably become a CGI parameter anyway...
d) DNS TXT lookups
I'm not entirely against this, but only allowing a fixed bitcoin address
to be returned would far too strongly encourage the use of fixed
addresses in transactions. If anything, it should be an identifier
for one of the other proposals (which do allow interaction, or at least
creation of a fresh bitcoin address) that is returned.
To conclude: my suggestion would be to use URLs as address identifiers,
optionally suffixed with a bitcoin address for authentication.
This means my "address" would be either "sipa.be/pw.btc" or
"sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
is an implicit default. Initiating a payment to either of these would
result in a GET of https://sipa.be/pw.btc. When a transaction is
constructed, it is POSTed back to that URL.
If we can agree on reasonable hardcoded mapping, pw@sipa.be could just
be a shorthand for either of these (though vulnerable to proofing...).
--
Pieter
|
