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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1QhHwe-00080R-6w
for bitcoin-development@lists.sourceforge.net;
Thu, 14 Jul 2011 09:10:56 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QhHwa-0002sG-91 for bitcoin-development@lists.sourceforge.net;
Thu, 14 Jul 2011 09:10:56 +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: EB2881380B7.A75CD
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id EB2881380B7;
Thu, 14 Jul 2011 11:10:42 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id B8F6B31E702;
Thu, 14 Jul 2011 11:10:42 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id BAB6610067;
Thu, 14 Jul 2011 11:12:19 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id BA98D87C1B0; Thu, 14 Jul 2011 11:10:42 +0200 (CEST)
Date: Thu, 14 Jul 2011 11:10:42 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: John Smith <witchspace81@gmail.com>
Message-ID: <20110714091041.GA3814@ulyssis.org>
References: <CAJNQ0st6Fo+VgVWj-AA5x8EvetZt4H=PR=n5q6NhZ6RyR0HYOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJNQ0st6Fo+VgVWj-AA5x8EvetZt4H=PR=n5q6NhZ6RyR0HYOA@mail.gmail.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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QhHwa-0002sG-91
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Notifications from client/wallet
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, 14 Jul 2011 09:10:56 -0000
On Thu, Jul 14, 2011 at 05:19:11AM +0000, John Smith wrote:
> Hello all,
>
> I'd like to add notifications to the client and wallet, to decouple UI and
> core communication, and especially so that UIs no longer have to poll for
> changes.
>
> I propose to use the boost::signal mechanism for that. It is basically a
> glorified callback system, but allows decoupled delivery of 'signals' from
> an object. Multiple other objects can listen in on an event without the
> emitting object having to care.
I like this idea. Matt and I were considering a similar system for the internal
communication between net/wallet/blockdb/mempool, but weren't really aware of
boost::signal. I looked at it, and really seems to provide everything necessary.
> Specific notifications that would be useful:
>
> Wallet:
>
> - balanceChanged(int64): spendable balance changed
Maybe even per-account?
> - transactionAdded(int256): new transaction added to wallet
> - transactionUpdated(int256): transaction info changed
Does that include more confirmations? I think we'd first need to define what
exactly is relevant information for transactions. It could be defined in
terms of a/some high-level information request functions for transactions, so
GUI/RPC don't inspect the wallet datastructures themselves anymore:
* GetTransactionState(): return state (immature, generated, unconfirmed,
rejected, confirmed), and number of confirmations.
(possibly using the negative number of confirmations
semantics as described here:
http://forum.bitcoin.org/index.php?topic=5920.msg328468#msg328468.
* GetBroadcasts(): return either -1 (unknown) or some integer denoting how often
this tx was broadcast. The "0/offline" state is equal to
unconfirmed + 0 broadcasts
* GetInputs(): return a list of pairs (uint256 txId, int nOffset, int64 nAmount)
* GetOutputsToMe(): return a list of pairs (address addr, string label, fBool isChange,
int64 nAmount, bool fGenerated, bool fAvailable) describing all
To-Me outputs
* GetOutputsToOthers(): return a list of pairs (address addr, string label,
int64 nAmount)
* GetFee(): get the fee paid
The only things that can change while the transaction is already in the wallet seems
to be GetTransactionState() and GetBroadcasts(), so those would cause a
transactionUpdated event?
Adding/removing private keys from the wallet may change the other outputs, so i suppose
those are also candidates for causing this event.
- transactionRemoved(int256): transaction removed from wallet (can this
> happen? for completeness)
for now, that can't happen, but if something like unspending/rejecting/detection
of conflicting transactions is added, it may.
> - addressAdded(int160): address was added to address book
> - addressUpdated(int160): address label/other metadata was modified
> - addressRemoved(int160): address was removed from address book
> - notification(std::string message, int severity): warning/error occured
> in wallet processing, notify user
Ok.
> - int askFee(std::string message, ...): ask user for fee
You simply mean the "Transaction requires fee of ..., agree?" message?
Regarding wallet encryption, we could use a
- string askPassphrase()
maybe?
> Network client:
>
> - numConnectionsChanged(int): new connections / connections broken
> - numBlocksChanged(int): new blocks came in or other changes to block
> chain
> - notification(std::string message, int severity): warning/error occured
> in network processing, notify user
Ok; those would need to be implemented as globals until a more modular structure
is implemented.
--
Pieter
|
