This change paves the way for saving more than just the block database to
the filesystem (such as address manager data, index data, etc) where the
name "dbdir" no longer makes sense.
This commit changes the code so that all calls to .Add on waitgroups
happen before the associated goroutines are launched. Doing this after
the goroutine could technically cause a race where the goroutine started
and finished before the main goroutine has a chance to increment the
counter. In our particular case none of the goroutines exit quickly
enough for this to be an issue, but nevertheless the correct way should be
used.
This commit adds support for relaying blocks between peers. It keeps
track of inventory that has either already been advertised to remote peers
or advertised by remote peers using a size-limited most recently used
cache. This helps avoid relaying inventory the peer already knows as
much as possible while not allowing rogue peers to eat up arbitrary
amounts of memory with bogus inventory.
This commit reworks the getblocks handling a bit to clean it up and match
the reference implementation handling. In particular, it adds monitoring
for when peers request the final block advertised from a previous
getblocks message and automatically avertises the latest known block
inventory to trigger the peer to send another getblocks message.
When no blocks in the block locator are found, start with the block after
the genesis block. This means the client will start over with the genesis
block if unknown block locators are provided. This mirrors the behavior
in the reference implementation.
This commit reworks the getheaders handling a bit to clean it up and match
the reference implementation handling. In particular, in addition to the
normal handling where headers starting after the block locator up to the
stop hash are served, when no locator hashes are provided, the stop hash
acts as a way to specifically request that header. Next, an empty headers
message is sent when no hashes provided by the block locator can be
found. Finally, there was a bug that was limiting the number of headers
that could requested at once to 500 instead of the expected 2000.
Rather than only setting the services field for inbound peers, set it for
all peers. This field referes to the remote peer's services regardless of
inbound or outbound.
This commit significantly reworks the fetching code to interop better with
bitcoind. In particular, when an inventory message is sent, and the
remote peer requests the final block, the remote peer sends the current
end of the main chain to signal that there are more blocks to get.
Previously this code was automatically requesting more blocks when the
number of in-flight blocks was under a certain threshold. The original
approach does help alleviate delays in the "request final, wait for
orphan, request more" round trip, but due to the aforementioned mechanism,
it leads to double requests and other subtle issues.
When running in regression test mode, it is unlikely the user wants to
connect to permanent peers they have configured in their config file.
This commit modifies the code to ignore the config file entry when in
regression test mode. The user can still provide -a (or --addpeer) on the
command line to override this if they really want to connect out to a
specific peer during regression test mode.
This commit modifies the input message handler so that when a remote peer
sends a block, no further messages from that peer are accepted until the
block has been fully processed and therefore known good or bad. This
helps prevent a malicious peer from queueing up a bunch of bad blocks
before disconnecting (or being disconnected) and wasting memory.
Additionally, this behavior is depended on by at least the block
acceptance test tool as the reference implementation processes blocks in
the same thread and therefore blocks further messages until the block has
been fully processed as well.
The commit reworks the server statup and shutdown sequence to ensure the
server can always shutdown cleanly. The peer code depends on being able
to send messages to the address and block managers, so they need to have
their lifecycle tied to the peer handler to prevent issues with
asynchronous shutdown order.
Although not required if the proxy set is indeed Tor, setting this option
does the following:
- Sends DNS queries over the Tor network (during dns seed lookup). This
stops your IP from being leaked via DNS.
- Does not disable the listening port. This allows the hidden services
feature of Tor to be used.
Previously, the genesis block was only inserted when the database was
created, but it's possible due to rollback that the database is created
and the genesis block insert gets rolled back if the app is existed too
quickly. This commit modifies the logic to test the need for the genesis
block any time the database is loaded and insert it if necessary.
This commit provide support for a new nolisten option which disables
listening for incoming connections. It also disable listening when the
--connect option is used.
This commit disables the RPC server by default if no RPC username of
password is specified (either via the command line or through the config
file).
Closes#2.
This commit implements support for listening on multiple sockets and
changes the default listen code to use one socket per address family (IPv4
and IPv6).
In addition, it changes the default listen binding for the RPC server to
localhost so only local clients can connect to it.
There need to be several options added to allow customization of these
settings and those will be in future commits.
Fixes#3.
