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.
This check does not have any impact on existing apps as in full verification mode the UTXO set is already effectively performing this check, and general SPV wallets don't verify inputs meaningfully anyway (they could just be random). However it's useful for Lighthouse and can't hurt - a tx with a duplicated outpoint is always invalid.
Instead of useDummySignatures flag there is now a MissingSigMode enum
allowing to specify what to do with missing signatures.
Available modes:
USE_OP_ZERO - do nothing. OP_0 will be left in place of missing
signature
USE_DUMMY_SIG - insert dummy signature in place of missing sig.
THROW - throw an exception. It would be either MissingSignatureException
for P2SH or MissingPrivateKeyException for other tx types
Default mode is USE_DUMMY_SIG (for backward compatibility)
