Long story short, I'm a shitty programmer it seems. The Wallet will at some point be modified to track just bags of outputs derived from Transaction objects, and Transactions/Blocks will become immutable. At that point there won't be any confusion between mutable data associated with the deserialised objects.
Resolves issue 453.
Key rotation allows you to specify a timestamp, and any money controlled by any keys created before that time will be automatically respent to keys created after it.
Don't create a new channel automatically when the client wants to resume but there's already an open connection using that contract. Instead, disconnect the other client. This fixes unintuitive behaviour that could occur if a TCP connection silently died and the server didn't notice.
Code from Matija Mazi. HD wallets allow you to derive keys from a single
root key, giving various useful features:
- Make a backup once and it's good forever (for your keys only of course)
- You can break off parts of the tree and give it to other people,
they can then generate new keys to send you money without any
involvement by you (better privacy+security for watching wallets)
- You can delegate sub-trees to other people as a form of access control.
* API change: TransactionConfidence.Listener now takes a reason enum describing the general class of change.
* Confidence listeners are now invoked in the user code thread as well, thus eliminating any chance of unexpected re-entrancy.
* The wallet batches up confidence changes and executes them all at the end of major operations, avoiding confusing intermediate transitions that could occur in the previous design.
* Much code has been simplified as a result and it's now harder to screw up.
This ensures that when user provided event listeners are invoked, we're not holding any locks at that time and thus event listeners can do whatever they want with no risk of accidental inversions or deadlocks. A utility method is available to wait for all preceding events that were triggered to complete, which is useful for unit tests. Reimplement how balance futures work in order to avoid the wallet registering an event handler on itself, this means you cannot accidentally deadlock yourself by running getBalanceFuture().get() inside an event listener.
Future changes will modify how transaction confidence listeners are run to work the same way, and make other kinds of event listener run in the user code thread as well.
The user code mechanism is usable with any executor, opening up the possibility of automatically relaying event listeners into GUI threads for some kinds of apps.
