From: Pieter Wuille <pieter.wuille@gmail•com>
To: John Smith <witchspace81@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Notifications from client/wallet
Date: Thu, 14 Jul 2011 11:10:42 +0200 [thread overview]
Message-ID: <20110714091041.GA3814@ulyssis.org> (raw)
In-Reply-To: <CAJNQ0st6Fo+VgVWj-AA5x8EvetZt4H=PR=n5q6NhZ6RyR0HYOA@mail.gmail.com>
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
next prev parent reply other threads:[~2011-07-14 9:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-14 5:19 John Smith
2011-07-14 9:10 ` Pieter Wuille [this message]
2011-07-14 14:13 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110714091041.GA3814@ulyssis.org \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=witchspace81@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox