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.
- Delete the PeerGroupThread and replace it with a connectToAnyPeer() method. Getting connected to the network is now significantly faster as there is no sleep-wait loop between connections.
- Delete the connectionTimeMillis param to the PeerGroup constructors.
- Expose the PeerGroup c'tor that lets you specify the ClientBootstrap and expose a utility method to make one. This means users can now customize TCP options directly.
- PeerGroup.setMaxConnections() now actually creates or tears down connections to meet the new required number, if the peer group is running.
- Update the PeerMonitor so there's a spinner that lets you add or remove peers. Connecting and version handshaking is very fast now.
- Misc changes and fixes.
It means a send won't be considered completed until it's accepted by the net.
Also is for the case where you receive a transaction (eg, via Bluetooth) and
you want to broadcast it such that you can know it's valid.
Make WalletTool use --peers instead of --peer, a comma separated list of
addresses to use. Remove the crappy sleep after send now we can wait.
Resolves issue 167.
