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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SPnfg-0007lM-2g
for bitcoin-development@lists.sourceforge.net;
Thu, 03 May 2012 04:29:40 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SPnff-0004eh-2X
for bitcoin-development@lists.sourceforge.net;
Thu, 03 May 2012 04:29:40 +0000
Received: by qcso7 with SMTP id o7so1090989qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 02 May 2012 21:29:33 -0700 (PDT)
Received: by 10.229.115.8 with SMTP id g8mr265841qcq.77.1336019373586;
Wed, 02 May 2012 21:29:33 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id i7sm7022201qae.20.2012.05.02.21.29.32
(version=SSLv3 cipher=OTHER); Wed, 02 May 2012 21:29:32 -0700 (PDT)
Message-ID: <4FA2095D.9060307@gmail.com>
Date: Thu, 03 May 2012 00:28:13 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative;
boundary="------------040805010701050101050002"
X-Spam-Score: -0.6 (/)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1SPnff-0004eh-2X
Subject: [Bitcoin-development] URI Handling in Bitcoin-Qt
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, 03 May 2012 04:29:40 -0000
This is a multi-part message in MIME format.
--------------040805010701050101050002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I want to follow up on BIP 21 (URI scheme), which I have recently
implemented in Armory and I have become a huge fan of it. But I've got
a couple gripes:
*(1) *What is the status & plans for supporting "bitcoin:" URIs in the
Satoshi client? My understanding is that it currently creates URIs, but
does *not* register itself with the OS to handle such links. Is this
accurate? This seems like a very high-value feature, and I'd recommend
that we consider it a priority -- I can't think of any other upgrade
that can improve usability so dramatically on the desktop.
After implementing it all in Armory, I wrote up a walk-thru
<https://bitcointalk.org/index.php?topic=79010.msg879804#msg879804>
recounting how I did the OS-registration in Windows and gnome-based *nix
systems. Perhaps it can give the Bitcoin-Qt devs a jumpstart on getting
it implemented. (and then I can get feedback about doing for generic
Linux and Mac/OSX)
*(2) *I need to understand better what the intentions were behind
"label=" and "message=". The way I understand it is that Bitcoin-Qt
uses and stores only address-labels, and no other transactional info is
stored in the wallet. As such, the "message=" field would be displayed
to the user when a "bitcoin:" link is clicked, but that message wouldn't
be saved anywhere.
However, I think, especially if a new wallet format is in the works,
that both should be supported: "Address Labels" *and *"Transaction
Labels". The real difference is that merchants can include things
Order#, purchase information, etc, in the "message" field, and then put
only their business name in the "label" field. This means that when the
user is looking at their address book, they see just the owners of the
addresses. When they look at the transaction ledger/history, they see a
full list of everything they purchased, prices, contact info, etc. The
distinction is much more important for persistent addresses, but still
important.
This is exactly how I did it in Armory, but if Bitcoin-Qt won't do it
that way, I should be promoting all important information be jammed into
the "label" field.
*(3) *How are the other clients implementing this? Do you make any
distinction between "label" and "message"?
-Alan
--------------040805010701050101050002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
I want to follow up on BIP 21 (URI scheme), which I have recently
implemented in Armory and I have become a huge fan of it. But I've
got a couple gripes:<br>
<br>
<b>(1) </b>What is the status & plans for supporting "bitcoin:"
URIs in the Satoshi client? My understanding is that it currently
creates URIs, but does <b>not</b> register itself with the OS to
handle such links. Is this accurate? This seems like a very
high-value feature, and I'd recommend that we consider it a priority
-- I can't think of any other upgrade that can improve usability so
dramatically on the desktop.<br>
<br>
After implementing it all in Armory, <a
href="https://bitcointalk.org/index.php?topic=79010.msg879804#msg879804">I
wrote up a walk-thru</a> recounting how I did the OS-registration
in Windows and gnome-based *nix systems. Perhaps it can give the
Bitcoin-Qt devs a jumpstart on getting it implemented. (and then I
can get feedback about doing for generic Linux and Mac/OSX)<br>
<br>
<br>
<b>(2) </b>I need to understand better what the intentions were
behind "label=" and "message=". The way I understand it is that
Bitcoin-Qt uses and stores only address-labels, and no other
transactional info is stored in the wallet. As such, the "message="
field would be displayed to the user when a "bitcoin:" link is
clicked, but that message wouldn't be saved anywhere.<br>
<br>
However, I think, especially if a new wallet format is in the works,
that both should be supported: "Address Labels" <b>and </b>"Transaction
Labels". The real difference is that merchants can include things
Order#, purchase information, etc, in the "message" field, and then
put only their business name in the "label" field. This means that
when the user is looking at their address book, they see just the
owners of the addresses. When they look at the transaction
ledger/history, they see a full list of everything they purchased,
prices, contact info, etc. The distinction is much more important
for persistent addresses, but still important.<br>
<br>
This is exactly how I did it in Armory, but if Bitcoin-Qt won't do
it that way, I should be promoting all important information be
jammed into the "label" field.<br>
<br>
<b>(3) </b>How are the other clients implementing this? Do you
make any distinction between "label" and "message"? <br>
<br>
-Alan<br>
</body>
</html>
--------------040805010701050101050002--
|
