If a key is seen in a filtered block that is too far inside our lookahead zone, discard that block and any further blocks being sent to us by a remote peer and recalculate the Bloom filter after more keys are pre-calculated. Then restart the chain download process. This ensures that we can catch up/replay the block chain and keep up with the deterministic key sequence.
This patch addresses two suboptimal behaviors in the `TorDiscovery` class:
1. Currently it uses the DNS-lookup timeout as the timeout for opening
circuits as well as for actually looking up the IP numbers. It may
be this timeout value, which is five seconds hard-coded into the
`PeerGroup` class, was not intended for this purpose. Moreover,
the `TorConfig` class has a value, circuitBuildTimeout, apparently
for this purpose; at least its default of 60 seconds may be more
appropriate for this purpose than the five-second lookup timeout.
2. Currently, the process of opening circuits for the DNS lookups will
take exactly as long as the timeout value, no more, no less, which
practically guarantees that the client will either wait longer than
necessary, or else experience timeout errors that could have been
avoided by waiting a bit longer.
The changes herein use the return value of`TorConfig.getCircuitBuildTimeout()`
as the timeout for opening circuits, rather than using the DNS lookup
timeout value that is passed by `PeerGroup` as an argument to
`PeerDiscovery.getPeers()`. Moreover, as soon as a circuit either has
been opened or failed to be opened for each router, the DNS lookups
then begin without waiting for the timeout time to elapse.
Notes:
1. There are no tests with these changes. There don't seem to be any
tests for the `TorDiscovery` class. There probably ought to be.
2. The `TorDiscovery` class's DNS lookup procedure has the same
timeout characteristic as the one this patch removes from the
circuit-opening procedure, namely it waits for as long as the
timeout value, no more no less. If the changes proposed in this
patch are acceptable, I would consider making the same change for
the process of looking up the peer IP numbers.
Now LocalTransactionSigner populates ProposedTransaction.keyPaths map even if
there is no private key in the wallet. Other signers may take advantage
of that.
Now LocalTransactionSigner populates ProposedTransaction.keyPaths map even if
there is no private key in the wallet. Other signers may take advantage
of that.
1. Client requests a time window, in seconds relative to now.
2. Server suggests an expire time, absolute time in seconds
3. Client accepts or rejects the servers proposal.
Note that the IPaymentChannelClient.ClinentConnection interface has a new method. This will break old implementations.
Let the client request the duration of a payment channel. Server can set allowed time window.
