Fixes a 60 second hang that could occur in wallet-tool once the send request was processed. Fixing this revealed another bug - WalletTool was depending on this VM shutdown delay caused by the worker pool timeout, so clean up the code and replace with a blocking get of the future.
Also support the --offline and --password flags when using the payment protocol.
Run the wallet txConfidenceListener on the calling thread. Move tx broadcast that occurs inside setTransactionBroadcaster outside the wallet lock to avoid inverting on the mempool class (via PeerGroup, but that doesn't lock on the broadcast path).
This makes memory usage smoother by avoiding the creation of tons of closures and spamming the event thread with them.
- Remove needless recalculations of the Bloom filter on any wallet change, instead of just when keys/scripts are added. This may fix one of the privacy leak issues too.
- Run fast catchup/filter recalculations on the dedicated PeerGroup thread instead of abusing the user thread. Resolves a TODO.
- Replace the user thread SingleThreadedExecutor with a custom class that blocks the submitting thread and logs a warning if the queue is saturated, to avoid building up a backlog of closures.
Add lots more nullity annotations.
Clear lots of nullity static analysis warnings.
Delete some dead code.
Simplify a few expressions.
Resolves issue 317.
There was a nasty bug where a connection-failed interrupt was
run afer any interruptible calls were made, making the next
test-case fail due to interruption.
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.
