Remove Netty entirely, using the new Nio wrapper classes instead
* BitcoinSerializer now uses ByteBuffers directly instead of
InputStreams.
* TCPNetworkConnection and NetworkConnection interface deleted,
Peer now extends the abstract class PeerSocketHandler which
handles deserialization and interfaces with the Nio wrapper
classes.
* As a part of this, all version message handling has been moved
to Peer, instead of doing it in TCPNetworkConnection.
* Peer.setMinProtocolVersion() now returns a boolean instead of a
null/non-null future which holds the now-closing channel.
* Peer.sendMessage (now PeerSocketHandler.sendMessage()) now
returns void.
* PeerGroup has some significant API changes:
* removed constructors which take pipeline factories,
makePipelineFactory, createClientBootstrap
* Replaced with a setSocketTimeoutMillis method that sets a
timeout between openConnection() and version/verack exchange.
(Note that because Peer extends AbstractTimeoutHandler, it has
useful timeout setters public already).
* connectTo returns a Peer future, not a ChannelFuture
* removed peerFromChannelFuture and peerFromChannel
* Peer and PeerGroup Tests have semi-significant rewrites:
* They use actual TCP connections to localhost
* The "remote" side is a InboundMessageQueuer, which queues
inbound messages and allows for writing arbitrary messages.
* It ignores certain special pings which come from pingAndWait,
which is used to wait for message processing in the Peer.
* Removed a broken test in PeerGroupTest that should be reenabled
if we ever prefer a different version than our minimum version
again.
* Removed two duplicate tests in PeerTest (testRun_*Exception)
which are tested for in badMessage as well.
* Added a test for peer timeout and large message deserialization
Author: Matt Corallo <git@bluematt.me>
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.
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.
This is useful for code that wants to make micropayments in a generic fashion, whilst being independent of whether the implementation is in-process using a local wallet, or perhaps running elsewhere (like inside an Android wallet app with communication happening using Binder RPC).
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.
Backport misc improvements from PayFile.
Refactor the clickable address out into a custom widget.
Use FontAwesome and the wrapper class for icons instead of a custom image.
QRcode support.
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.
This resolves some complicated state management issues in some kinds of client (like on Android). It's also just generally a part of the work to divorce the notion of settling a channel from closing underlying protocol connections.
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.
Apparently this simple utility class might start to need unit tests now!
To resolve the hack, we need to resolve some circularity in construction: to add the payment channels wallet extensions requires the peerGroup and wallet object to be constructed, but to construct the peerGroup requires the chain+store and to checkpoint a fresh store requires the wallet. Catch 22! We resolve by loading a temp wallet and then throwing it away, which is inefficient for a large wallet that's being replayed but normally shouldn't matter.
Once the payment channels stuff is more mature and tested, we might want to just fold it into the core wallet format.
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.
Implements deserialization for getblocks/getheaders and supports
FilteredBlock entries in ListMessage (for getdata).
Implements serialization for FilteredBlock, HeadersMessage, and
PartialMerkleTree.
Key rotation allows you to specify a timestamp, and any money controlled by any keys created before that time will be automatically respent to keys created after it.
Don't create a new channel automatically when the client wants to resume but there's already an open connection using that contract. Instead, disconnect the other client. This fixes unintuitive behaviour that could occur if a TCP connection silently died and the server didn't notice.
Code from Matija Mazi. HD wallets allow you to derive keys from a single
root key, giving various useful features:
- Make a backup once and it's good forever (for your keys only of course)
- You can break off parts of the tree and give it to other people,
they can then generate new keys to send you money without any
involvement by you (better privacy+security for watching wallets)
- You can delegate sub-trees to other people as a form of access control.
* 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 ensures that when user provided event listeners are invoked, we're not holding any locks at that time and thus event listeners can do whatever they want with no risk of accidental inversions or deadlocks. A utility method is available to wait for all preceding events that were triggered to complete, which is useful for unit tests. Reimplement how balance futures work in order to avoid the wallet registering an event handler on itself, this means you cannot accidentally deadlock yourself by running getBalanceFuture().get() inside an event listener.
Future changes will modify how transaction confidence listeners are run to work the same way, and make other kinds of event listener run in the user code thread as well.
The user code mechanism is usable with any executor, opening up the possibility of automatically relaying event listeners into GUI threads for some kinds of apps.
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.
This forms the base for payment channel network connections, with
a simple single-threaded server which accepts new connections, a
simple single-threaded client which makes a single connection to a
server, and a ProtobufParser which handles data generated by a
connection, splits them into Protobufs and provides a reasonable
interface to users who wish to create/accept protobuf-based
connections.
1) Switch the outpoint index field to be uint32 and fix isCoinBase() to consider the unsigned versions only. Resolves issue 420.
2) Regenerate the protobuf and fix an out of date definition in WalletProtobufSerializer that it exposed.
and looks like a broken attempt to implement file locking. Neither
store that tried to use it is supporte anymore so don't bother replacing
with real file locks.
Add a method for signing a given input and use it.
Convert some code that was working with raw bytes to use TransactionSignature.
Rename Transaction.hashTransactionForSignature to just hashForSignature.
General API tweaks and cleanups.
