Disable signature checking in ChannelTest to make it run faster, especially in the debugger, and bump timeouts so client/server don't timeout when debugging.
Now connects all inputs of an overriding transaction, meaning balance is correct if a bit-tweaked but semantically identical transaction double spends its shadow (e.g. during key rotation on a cloned device).
Still does not recursively kill transactions however.
Resolves issue 439.
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.
Extract out the "is time locked" risk analysis code to a pluggable implementation.
Ensure the default implementation has 100% test coverage.
Consider finality, not merely the presence of a lock time, when judging risk.
Don't consider a tx risky if it would become final in the next block.
Do not consider self-created transactions risky.
Now broadcast to half the connected peers immediately, and wait until half of the rest (i.e. a quarter) have announced the tx. This should give some robustness against a random subset of peers silently swallowing transactions.
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.
1) TX confidence listeners were being run for chain height changes, even if they were not confirmed yet.
2) req.fee was being miscalculated for empty wallet transactions.
Previously the PeerGroup itself would broadcast the pending transactions by simply sending an inv with them all to every peer. This is a good way to get a transaction blasted out if there are no problems with it, but it means we cannot track propagation and the numBroadcastPeers() value was correspondingly not increased. This seems to be causing issues with the Android wallet. So try out a different approach - have the wallet use broadcastTransaction as per normal on the PeerGroup when it's added. The TX will be propagated and watched as with a normal spend.
The client now has a new CLOSED state, which is entered once a CLOSE has been sent and the close transaction (final contract) has been broadcast onto the P2P network and entered the wallet. Once received, the hash of the close tx is stored in the wallet - the tx is itself already in the wallets spent pool because it connects to the output of the multisig tx. After seeing three confirmations of the close TX the state is deleted from the client wallet for good.
Together these changes resolve a bug/design issue in which if a channel was opened, then closed, then another channel was opened but not closed, then a third attempt to connect to the server was made, the client would try to resume the first closed channel. That would fail because the server already deleted its state object and result in new channels being created even though the second could have been resumed. By tracking the fact that the channel was closed, it can be skipped when considering what channel to resume.
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.
