bitcoin/bitcoin

Also, enable crc32 even if -msse4.2 wasn't added by us, as long as it works.
This allows custom flags (such as -march=native) to work as expected.

rbx needs to be stashed in a 64bit register on 64bit platforms. With this crash
in particular, it was holding a stack canary which was not properly restored
after the cpuid.

Split out the x86+PIC case so that x86_64 doesn't have to worry about it.

This addresss the TODO to avoid resolving twice.

In order to prevent mixups, our internal range is never allowed as a resolve
result. This means that no user-provided string will ever be confused with an
internal address.

We currently do two resolves for dns seeds: one for the results, and one to
serve in addrman as the source for those addresses.

There's no requirement that the source hostname resolves to the stored
identifier, only that the mapping is unique. So rather than incurring the
second lookup, combine a private subnet with a hash of the hostname.

The resulting v6 ip is guaranteed not to be publicy routable, and has only a
negligible chance of colliding with a user's internal network (which would be
of no consequence anyway).

This is a well-intentioned but realistically annoying warning. Unfortunately,
it's too easy for a warning in one header to cause dozens of repeated warnings.

also once half of all outgoing nodes have our preferred flags, require only
minimal flags from the rest.

When inserting two addresses of the same class, from the same source, they have
a 1/64 chance of colliding.

-BEGIN VERIFY SCRIPT-
sed -i "s/\(node\|to\|from\)->id/\1->GetId()/" src/net.cpp src/net_processing.cpp
-END VERIFY SCRIPT-

This was a long-standing and annoying problem.

If autogen.sh was not manually run after touching configure.ac,
bitcoin-config.h would not be properly regenerated. This causes very subtle
problems when configure appears to enable a new value, but it does not end up
reflected in the build.

These were meant to help build subdir targets from the top builddir, but cause
infinite recursion when going the other way.

If anyone actually uses these, we can add back specific targets.

This should make occurances of NodeId wrapping essentially impossible for
real-world usage.

zlib is sneaky and expects ar to be libtool on darwin.

ld64 is threaded, and uses a worker for each CPU to parse input files. But
there's a bug in the parser causing dependencies to be calculated differently
based on which files have already been parsed.

As a result, builders with more CPUs are more likely to see non-determinism.

This looks to have been fixed in a newer version of ld64, so just disable
threading for now. There's no noticible slowdown.

…ediately

This turns some compiler warnings into errors. Useful for c-i.

Newer compilers may switch to newer standards by default. For example, gcc6
uses std=gnu++14 by default.

This was skipped for the 0.14 cycle.

They're unused and produce nasty deprecation warnings

This is certainly not exhaustive, but it's better than nothing. Adds checks
for:

- Any message received before sending a version
- Any message received other than version/reject before sending a verack

It also tries to goad the remote into sending a pong, address, or block
announcement.

7a8c251 made this logic hard to follow. After that change, messages would
not be sent to a peer via SendMessages() before the handshake was complete, but
messages could still be sent as a response to an incoming message.

For example, if a peer had not yet sent a verack, we wouldn't notify it about
new blocks, but we would respond to a PING with a PONG.

This change makes the behavior straightforward: until we've received a verack,
never send any message other than version/verack/reject.

The behavior until a VERACK is received has always been undefined, this change
just tightens our policy.

This also makes testing much easier, because we can now connect but not send
version/verack, and anything sent to us is an error.

Prior to this change, all messages were ignored until a VERSION message was
received, as well as possibly incurring a ban score.

Since REJECT messages can be sent at any time (including as a response to a bad
VERSION message), make sure to always parse them.

Moving this parsing up keeps it from being caught in the
if (pfrom->nVersion == 0) check below.

7a8c251 made a change to avoid getting into SendMessages() until the
version handshake (VERSION + VERACK) is complete. That was done to avoid
leaking out messages to nodes who could connect, but never bothered sending
us their version/verack.

Unfortunately, the ban tally and possible disconnect are done as part of
SendMessages(). So after 7a8c251, if a peer managed to do something
bannable before completing the handshake (say send 100 non-version messages
before their version), they wouldn't actually end up getting
disconnected/banned. That's fixed here by checking the banscore as part of
ProcessMessages() in addition to SendMessages().

These are (afaik) all long-standing races or concurrent accesses. Going
forward, we can clean these up so that they're not all individual atomic
accesses.

- Reintroduce cs_vRecv to guard receive-specific vars
- Lock vRecv/vSend for CNodeStats
- Make some vars atomic.
- Only set the connection time in CNode's constructor so that it doesn't change