The previous overloading of the term "close" to mean both settlement of the channel (broadcast of the final payment tx) and terminating/cleaning up the underlying network connection was very confusing and made the code harder to work with. The notion of "closing" a protocol that is often embedded inside others isn't really well defined, so there's perhaps more work to do here, but this change makes the code easier to follow and is basically a big pile of no-ops.
Add a new PAYMENT_ACK message to the protocol. Make incrementPayment return a future that completes when the server has acknowledge the balance increase.
Also, prevent users from overlapping multiple increase payment requests.
This resolves race conditions that can occur when the billed-for activity is asynchronous to the protocol in which the micropayment protocol is embedded. In this case, it was previously impossible to know when the async activity could be resumed as it would otherwise race with the process of the server checking the payment signature and updating the balance. Most applications of micropayments will use a single protocol that has been extended with an embedding, and thus this is not an issue. However in some rare applications the payment process may run alongside the existing protocol rather than inside it. In this case, payment acks should be used for synchronization.
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.
