It will now listen on an IPv6 socket if possible or fall back to IPv4
if that doesn't work. It will no longer filter out all IPv6 addresses
and instead it will only filter out those that point to the local
network.
It looks like the DNS bootstrapping should just automatically work
because getaddrinfo already returns IPv6 addresses from the AAAA
record.
In order to convert from the ASCII representation of IPv6 addresses
and back we need inet_ntop and inet_pton. Python 2 doesn't currently
provide these for Windows so instead this patch provides a hot patch
to the socket module which wraps WSAStringToAddress and
WSAAddressToString using ctypes.
If this option is specified in keys.dat then Bitmessage will connect
to the host specified there instead of connecting to the hosts in the
list of known nodes. It will also stop listening for incoming
connections and the timing attack mitigation will be disabled.
The expected use case is for example where a user is running a daemon
on a dedicated machine in their local network and they occasionally
want to check for messages using a second instance of the client on
their laptop. In that case it would be much faster to catch up with
the messages by directly downloading from the dedicated machine over
the LAN. There is no need to connect to multiple peers or to do the
timing attack mitigation because the daemon is trusted.
The host is specified as hostname:port. Eg, ‘192.168.1.8:8444’.
Until now many parts of the code assumed that IP addresses are
unique for peers. However, more than one Bitmessage instance might
be running with a given IP address due to multi-user systems or
firewalls.
This allows other clients to insert headers in extra lines of text between
the Subject and Body fields of the message, as discussed on the 24x7 mailing
list. The PyBitmessage client was never able to meaningfully display
multi-line subjects, so this does not break anything. The extra lines are
thrown away and never stored anywhere, so this also protects against
watermarking attacks.
As per http://docs.python.org/2/howto/sockets.html#using-a-socket it's
possible that a socket recv() call returns 0 bytes if the remote closes
the connection. In that case, recv() does not obey settimeout(): it
just doesn't block and returns zero bytes immediately, which in this
case results in an infinite loop if the transmission was incomplete.
