The synchronizer's work is done from the network proxy's main loop.
A minor problem with the old synchronizer was that it considered itself
out of date if the network was out of date. This was too generic: the
network can have pending requests unrelated to the synchronizer. This
resulted in the synchronizer often unnecessarily flipping the wallet
between up-to-date and not-up-to-date, and causing unnecessary calls
to wallet.save_transactions(). This was observable when opening the
network dialog box: frequently just opening it would cause a wallet
status change and transaction flush, simply because the network dialog
sends a get_parameters() request. This rework of the synchronizer does
not have that issue.
This is a layering violation - the SocketPipe doesn't own
the socket and provides no other way to close the socket, leading
to unnecessary complexity like that in interface.py.
I looked at deamon.py and NetworkProxy - the two other users,
and they don't close the sockets explicitly, just let them be
garbage collected.
Set timeout and socket options on all simple sockets. At present
some code paths can miss it, such as when the SSL certificate is
CA-signed.
Add a missing check for failure.
Remove interface communication out of blockchain.py
into network.py. network.py handles protocol requests
for headers and chunks. blockchain.py continues to
handle their analysis and verification.
If an interface provides a header chain that doesn't
connect, it is dismissed, as per a previous TODO comment.
This removes a thread and another source of timeouts.
I see no performance issues with this when truncating the
blockchain.
Rename 'result' to 'header' for clarity.
This allows us to distinguish between connecting and connected
state in interface.py (used to be done in network.py but that
had other issues).
This means we don't switch to a connecting server, and get_interfaces()
does not report connecting ones.
Two callers of get_spendable_coins were removing frozen addrs
before calling. Put that functionality in the function.
We shouldn't be able to send_from a frozen address. This was
possible in the current release because logic assumed a two-element
tuple was returned when it is now three-element. Fix that too.
Command line options listunspent and createrawtransaction currently
ignore frozen addresses. I'm not sure that's right but I've preserved
that behaviour.
With this patch only the wallet class refers to self.frozen_addresses;
other clients use is_frozen() now.
Speedup mainly from writing to storage only once.
Make frozen_addresses a set in memory, as sets give cleaner
code and are more efficient.
Minor change in behaviour: command line freezing used to return
False if the address isn't in the wallet OR the address was already
frozen. Now it returns more like a success code: it returns False
only if the address isn't in the wallet regardless of frozen state.
Similarly for unfreezing.
interfaces we have created.
Existing code has the concept of pending servers, where a connection
thread is started but has not sent a connection notification, and
and interfaces which have received the notification.
This separation caused a couple of minor bugs, and given the cleaner
semantics of unifying the two I don't think the separation is beneficial.
The bugs:
1) When stopping the network, we only stopped the connected interface
threads, not the pending ones. This would leave Python hanging
on exit if we don't make them daemon threads.
2) start_interface() did not check pending servers before starting
a new thread. Some of its callers did, but not all, so it was
possible to initiate two threads to one server and "lose" one thread.
Apart form fixing the above two issues, unification causes one more
change in semantics: we are now willing to switch to a connection
that is pending (we don't switch to failed interfaces). I don't
think that is a problem: if it times out we'll just switch
again when we receive the disconnect notification, and previously the
fact that an interface was in the interaces dictionary wasn't a
guarantee the connection was good anyway: we might not have processed
a pending disconnection notification.
As discussed on #electrum yesterday.
Increase change gap limit to 6.
Choose the next unused change address, if any, otherwise pick
one at random from the gap limit.
