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.
This implements micropayment payment channels in several parts:
* Adds PaymentChannel[Server|Client]State state machines which
handle initialization of the payment channel, keep track of
basic in-memory state, and check data received from the other
side, based on Mike Hearn's initial implementation.
* StoredPaymentChannel[Client|Server]States manage channel
timeout+broadcasting of relevant transactions at that time,
keeping track of state objects which allow for channel
resume, and are saved/loaded as a WalletExtension.
* Adds PaymentChannel[Client|Server] which manage a connection
by getting new protobufs, generating protobufs for the other
side, properly stepping the associated State object and
ensuring the StoredStates object is properly used to save
state in the wallet.
* Adds PaymentChannel[ClientConnection|ServerListener] which
create TCP sockets to each other and use
PaymentChannel[Client|Server] objects to create/use payment
channels.
The algorithm implemented is the one described at
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
with a slight tweak to use looser SIGHASH flags so that the
Wallet.completeTx code can work its magic by adding more inputs if
it saves on fees.
Thanks to Mike Hearn for the initial state machine implementations
and all his contracts work and Jeremy Spilman for suggesting the
protocol modification that works with non-standard nLockTime
Transactions.
This forms the base for payment channel network connections, with
a simple single-threaded server which accepts new connections, a
simple single-threaded client which makes a single connection to a
server, and a ProtobufParser which handles data generated by a
connection, splits them into Protobufs and provides a reasonable
interface to users who wish to create/accept protobuf-based
connections.
1) Switch the outpoint index field to be uint32 and fix isCoinBase() to consider the unsigned versions only. Resolves issue 420.
2) Regenerate the protobuf and fix an out of date definition in WalletProtobufSerializer that it exposed.
Add a method for signing a given input and use it.
Convert some code that was working with raw bytes to use TransactionSignature.
Rename Transaction.hashTransactionForSignature to just hashForSignature.
General API tweaks and cleanups.
