1. Client requests a time window, in seconds relative to now.
2. Server suggests an expire time, absolute time in seconds
3. Client accepts or rejects the servers proposal.
Note that the IPaymentChannelClient.ClinentConnection interface has a new method. This will break old implementations.
Let the client request the duration of a payment channel. Server can set allowed time window.
This is a (backwards incompatible) protocol change that prevents clients or servers getting into a situation where they have opened a channel that they then cannot close because insufficient value has been transferred.
The server is allowed to specify the minimum payment it requires in order to open any channel at all, and the client then sanity checks that. Currently the rule is very simple - the min payment must be equal to the hard-coded dust limit. In future it will get more complicated as the dust limit starts to float and a more nuanced risk analysis may become required.
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.
