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-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 <etotheipi@gmail.com>) id 1SQ6oe-0005DV-Nw
for bitcoin-development@lists.sourceforge.net;
Fri, 04 May 2012 00:56:14 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SQ6od-00031S-VQ
for bitcoin-development@lists.sourceforge.net;
Fri, 04 May 2012 00:56:12 +0000
Received: by qcso7 with SMTP id o7so1922424qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 03 May 2012 17:56:06 -0700 (PDT)
Received: by 10.224.175.69 with SMTP id w5mr7203590qaz.49.1336092966516;
Thu, 03 May 2012 17:56:06 -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 hs1sm12007127qab.21.2012.05.03.17.56.05
(version=SSLv3 cipher=OTHER); Thu, 03 May 2012 17:56:05 -0700 (PDT)
Message-ID: <4FA328CF.4020902@gmail.com>
Date: Thu, 03 May 2012 20:54:39 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wladimir <laanwj@gmail.com>
References: <4FA2095D.9060307@gmail.com>
<CA+s+GJA2qZxq=V_=Ma0LESOjae49aZHdrpMeJzQS3GtwP5T6=w@mail.gmail.com>
In-Reply-To: <CA+s+GJA2qZxq=V_=Ma0LESOjae49aZHdrpMeJzQS3GtwP5T6=w@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------080306020708080602060002"
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: 1SQ6od-00031S-VQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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: Fri, 04 May 2012 00:56:14 -0000
This is a multi-part message in MIME format.
--------------080306020708080602060002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 05/03/2012 01:46 AM, Wladimir wrote:
>
> Label is a label for the destination address, message is a freeform
> message describing the transaction.
>
> I don't think the message is currently stored in the Satoshi client.
> That feature is somewhere on our way-too-long issue and todo list.
>
> But I understand that you want to add transaction meta-data fields
> such as contact information, bought items, item prices?
>
>
I don't want to add fields to the URI-spec, I just want to add them /to
the client/. To me, it is ideal to have separate strings for labeling
/addresses/ vs labeling /transactions/ -- i.e. different strings would
show up in the address book (owner info) than what shows up in the
transaction history (purchase info). I say it's ideal because that
concept seems to fit perfectly with availability of "label=" and
"message=" fields in BIP 21, but it won't actually work if Bitcoin-Qt
won't/can't do it that way.
For now, it seems that I should count on all important information being
in the /label/ field, since users creating URLs would have to assume
anything in the /message/ field will not be saved. Though I imagine the
message data will be /displayed/ after the URI is clicked, just not saved.
To expand the concept slightly further, it might make sense in the
future for users to populate the /message/ and /label /fields with lots
of data, using newlines. The first line would be used as a summary and
displayed in the address book and ledger. The extra lines would all be
displayed when the user opens up a details window. All of it would be
automatically generated by the merchant, and the purchaser would end up
with detailed documentation on every purchase they've made for zero effort.
-Alan
--------------080306020708080602060002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 05/03/2012 01:46 AM, Wladimir wrote:
<blockquote
cite="mid:CA+s+GJA2qZxq=V_=Ma0LESOjae49aZHdrpMeJzQS3GtwP5T6=w@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>Label is a label for the destination address, message is a
freeform message describing the transaction.</div>
<div><br>
</div>
<div>I don't think the message is currently stored in the
Satoshi client. That feature is somewhere on our way-too-long
issue and todo list.</div>
<div><br>
</div>
<div>But I understand that you want to add transaction meta-data
fields such as contact information, bought items, item prices?</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
I don't want to add fields to the URI-spec, I just want to add them
<i>to the client</i>. To me, it is ideal to have separate strings
for labeling <i>addresses</i> vs labeling <i>transactions</i> --
i.e. different strings would show up in the address book (owner
info) than what shows up in the transaction history (purchase
info). I say it's ideal because that concept seems to fit
perfectly with availability of "label=" and "message=" fields in BIP
21, but it won't actually work if Bitcoin-Qt won't/can't do it that
way.<br>
<br>
For now, it seems that I should count on all important information
being in the <i>label</i> field, since users creating URLs would
have to assume anything in the <i>message</i> field will not be
saved. Though I imagine the message data will be <i>displayed</i>
after the URI is clicked, just not saved.<br>
<br>
To expand the concept slightly further, it might make sense in the
future for users to populate the <i>message</i> and <i>label </i>fields
with lots of data, using newlines. The first line would be used as
a summary and displayed in the address book and ledger. The extra
lines would all be displayed when the user opens up a details
window. All of it would be automatically generated by the merchant,
and the purchaser would end up with detailed documentation on every
purchase they've made for zero effort. <br>
<br>
-Alan<br>
<br>
</body>
</html>
--------------080306020708080602060002--
|
