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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rick.wesson@iidf.org>) id 1Qn9oS-000848-Ah
for bitcoin-development@lists.sourceforge.net;
Sat, 30 Jul 2011 13:42:44 +0000
X-ACL-Warn:
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Qn9oQ-0007rk-VT
for bitcoin-development@lists.sourceforge.net;
Sat, 30 Jul 2011 13:42:44 +0000
Received: by yxi19 with SMTP id 19so3520988yxi.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 30 Jul 2011 06:42:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.156.20 with SMTP id i20mr60237ybo.53.1312033355168; Sat,
30 Jul 2011 06:42:35 -0700 (PDT)
Received: by 10.150.138.1 with HTTP; Sat, 30 Jul 2011 06:42:35 -0700 (PDT)
In-Reply-To: <CANEZrP2RdNv3Ao01jUQuyg0AapuC-e_skMF_2Ot0fkx6jH+nkw@mail.gmail.com>
References: <CAJ1JLts5_r6hHoJR-gS-CuuvS00p=RQ6iYbCyOkBDcvgs1xtew@mail.gmail.com>
<CANEZrP2RdNv3Ao01jUQuyg0AapuC-e_skMF_2Ot0fkx6jH+nkw@mail.gmail.com>
Date: Sat, 30 Jul 2011 06:42:35 -0700
Message-ID: <CAJ1JLtvuts2T=gN9Fm0W8yvqMLUorSV+tvcjO+TKwsq=rKnnsQ@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qn9oQ-0007rk-VT
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] bitcoin DNS addresses
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: Sat, 30 Jul 2011 13:42:44 -0000
I'm offering patches for DNS lookup, which seems good enough to locate
the irc server but not good enough for the folks that use copy/paste.
from a usability standpoint, the clipboard isn't a UI element in flow
design. Its also subject to MITM attacks for the most popular OSes.
Finally, think beyond you and your friends to how you can buy coffee
at starbucks easier and faster than with a starbucks card. Thats how
you make successful apps and protocols.
Has anyone offered to write the mythical
https-address-resolver-easy-button for bitcoind?
-rick
On Sat, Jul 30, 2011 at 4:34 AM, Mike Hearn <mike@plan99.net> wrote:
> This was already discussed on the forums, but clear use cases would be helpful.
>
> I originally thought this feature seemed like a no-brainer, but
> randomly emailing money to people out of the blue is not a very common
> operation. You almost always have contact with them first, if only to
> say "hey, I'm going to send you some money", but more commonly to
> figure out how much you're going to pay and what for.
>
> Once you have communication, providing an address in-band isn't very
> hard, and it has the advantage of always working. Doing anything with
> DNS or magic HTTPS endpoints means that 90% of the time, your feature
> *will not work* (eg it won't work for any gmail/yahoo/hotmail account)
> and users will rapidly learn not to bother trying as they have no way
> of knowing if any given address will work or not.
>
> It's not smart UI design to provide users with a feature that will
> normally never work, and for which they can't even guess at whether it
> will.
>
> What would be better to see is a standardized (probably HTTPS based)
> protocol in which a Bitcoin URI could contain a domain name, and then
> your client would challenge the domain to sign a nonce with the key
> corresponding to the address (or raw pubkey). This means in your
> client the payment can be rendered and recorded as a payment to
> "foobar.com", which is much more helpful. That protocol could then be
> extended to support "user@foobar.com" type challenges so when a
> bitcoin: link is provided, the server is challenged to prove ownership
> by that user of that public key. It means the details are hidden and
> when the feature is present, the UI gets silently better, but there's
> never any demand on any users to do anything different. The "copy
> Bitcoin address" button in the UI can provide the clipboard with both
> text/plain and text/html content so the right one is picked depending
> on context.
>
|
