ACK concept, and code looks good to me.

Needs at least a sketch of a test plan that exercises all of the signals.

Haven't tested yet, but code lookg good and I like the approach.

@laanwj The reasoning is that there are callbacks from the node/validation to the wallet; they're really just notifications in general, as the node code shouldn't care about what the wallet does with it (in fact, the signal names shouldn't contain "wallet" even, though I chose not to change them here). As EraseFromWallet was only called as a callback, I just simplified the method here. In the case of AddToWalletIfInvolvingMe (which is called internally inside the wallet as well, with a relevant return code), I added a wrapper to use as signal handler.

Ok, thanks, that makes it clear, I was just not sure if it was overlooked or on purpose.

I like the idea of renaming the signals to be more general (so that theoretically non-wallets could also use the API to keep track)

SyncWithWallets -> SyncTransactions
EraseFromWallets -> EraseTransaction
SetBestChain -> stays the same
UpdatedTransaction -> stays the same
Inventory -> stays the same
ResendWalletTransactions -> ResendTransactions

@laanwj Modified the signal names a bit, and added comments.

Rebased.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/722fa283d04dfe9c70418e69535a08eea06b4377 for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

@gavinandresen Test plan:

• Create a transaction in the GUI, and check whether the number of peers that have seen it goes up. This exercises the Inventory signal.
  • Leave the client open until it confirms. This exercises the SyncTransaction signal.
• Every at most 30 minutes, ResendWalletTransactions should be called (LogPrintf'ed). This exercises the Broadcast signal.
• Mine a block yourself, and wait until another on top is mined, while leaving the GUI open. The block's payout should appear only when the second block is mined. This exercises the UpdatedTransaction signal.
• After being fully synchronized, wait for a block whose height is a multiple of 144, and forcibly kill the client. At startup, the automatic rescan shouldn't go back beyond that 144-multiple block. This exercises the SetBestChain signal.
  • Alternatively, do a -reindex, and wait until a block whose height is a multiple of 20160 is crossed, and do the same kill/restart cycle.

ACK. Ran through test plan with a Bitcoin-Qt in regtest mode and two -regtest bitcoind's, all tests passed.