If there's insufficient balance (typical error) then InsufficientMoneyException is thrown (checked).
If the SendRequest is bad in some way, like asking to create a spend that would violate the protocol rules, IllegalArgumentException is thrown (unchecked).
Also make VerificationException (and thus ProtocolException+ScriptException) unchecked.
Resolves issue 425.
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.
It's now just ForwardingService, doesn't use the "from address" concept anymore, and uses WalletAppKit + balance futures. The new code is much simpler and easier to read.
* 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 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.
The old "prodnet" name could be confusing to non-native speakers or people who just haven't been exposed to Google lingo. Main net is more idiomatic.
Conflicts:
tools/src/main/java/com/google/bitcoin/tools/BlockImporter.java
Put DNS seeds into NetworkParams.
Deprecate IrcDiscovery and remove the unit tests for it.
Update examples and tools to use DNS for everything.
Resolves issue 299.
Unfortunately this introduces some new FindBugs warnings because it doesn't understand the inside-out locking pattern used here, despite that it's correct.
Update issue 233.
