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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QfU6q-0001O4-VL
for bitcoin-development@lists.sourceforge.net;
Sat, 09 Jul 2011 09:46:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
helo=mail-yx0-f175.google.com;
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 1QfU6q-0001wK-9U
for bitcoin-development@lists.sourceforge.net;
Sat, 09 Jul 2011 09:46:00 +0000
Received: by yxi19 with SMTP id 19so1374521yxi.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 Jul 2011 02:45:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.67.21 with SMTP id p21mr2550074yba.357.1310204754825; Sat,
09 Jul 2011 02:45:54 -0700 (PDT)
Received: by 10.151.150.15 with HTTP; Sat, 9 Jul 2011 02:45:54 -0700 (PDT)
Date: Sat, 9 Jul 2011 09:45:54 +0000
Message-ID: <CAJNQ0sv1DxT6SmvqXNdaF09Fj=+mcM-RGXUEaFfns5oAeRFkkg@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=000e0cd51db2fe91a804a79fd0e7
X-Spam-Score: -0.5 (/)
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
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
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: 1QfU6q-0001wK-9U
Subject: [Bitcoin-development] Metadata for transactions / address book
records
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, 09 Jul 2011 09:46:01 -0000
--000e0cd51db2fe91a804a79fd0e7
Content-Type: text/plain; charset=ISO-8859-1
Hello devs,
For UI purposes I'd like to be able to associate metadata to transactions
and address book records.
To be clear, this is completely client-side and will never see the block
chain.
For transactions:
- std::string description; // A description that the user can give to a
transaction, after he sent/received it, for example "ordered eggs"
For addresses:
- bool visibleInInterface; // Visible in interface; useful to hide old
addresses/labels from the lists, without removing them for lookup purposes
These are my current ideas; probably, more metadata can be useful later on
(accounting category, links to 3rd party services, etc), so an extensible
system would be nice.
Any ideas as to what would be the best place to put this, while minimizing
the core changes?
I'm aware that this could also be implemented completely inside the UI code,
but I'm not sure this is nice, as it would put database handling etc there
and would mean even more data files for the user to backup/track.
JS
--000e0cd51db2fe91a804a79fd0e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello devs,<br><br>For UI purposes I'd like to be able to associate met=
adata to transactions and address book records. <br><br>To be clear, this i=
s completely client-side and will never see the block chain.<br><br>For tra=
nsactions:<br>
<br>-=A0=A0 std::string description; // A description that the user can giv=
e to a transaction, after he sent/received it, for example "ordered eg=
gs"<br><br>For addresses:<br><br>-=A0=A0 bool visibleInInterface; // V=
isible in interface; useful to hide old addresses/labels from the lists, wi=
thout removing them for lookup purposes<br>
<br>These are my current ideas; probably, more metadata can be useful later=
on (accounting category, links to 3rd party services, etc), so an extensib=
le system would be nice.<br><br>Any ideas as to what would be the best plac=
e to put this, while minimizing the core changes? <br>
<br>I'm aware that this could also be implemented completely inside the=
UI code, but I'm not sure this is nice, as it would put database handl=
ing etc there and would mean even more data files for the user to backup/tr=
ack.<br>
<br>JS<br>
--000e0cd51db2fe91a804a79fd0e7--
|
