Update serialize comments to be doxygen compatible
The first thing that SelectParams does is call SelectBaseParams. Therefore, we do not need to call SelectBaseParams immediately prior to calling SelectParams.
Avoid a bunch of copying/conversion in script/sign
depends: boost: hard-code hidden symbol visibility

tl;dr: This solves boost visibility problems for default/release build configs
on non-Linux platforms.

When Bitcoin builds against boost's header-only classes, it ends up with
objects containing symbols that the upstream boost libs also have. Since
Bitcoin builds by default with hidden symbol visibility, it can end up trying
to link against a copy of the same symbols with default visibility.
This is not a problem on Linux because 3rd party static libs are un-exported
by default (--exclude-libs,ALL), but that is not available for MinGW and OSX.

Those platforms (and maybe others?) end up confused about which version to use.

The OSX linker spews hundreds of: "ld: warning: direct access in <foo> to
global weak symbol guard variable for <bar> means the weak symbol cannot be
overridden at runtime. This was likely caused by different translation units
being compiled with different visibility settings."

MinGW's linker complains similarly.

Since the default symbol visibility for Bitcoin is hidden and releases are
built that way as well, build Boost with hidden visibility. Linux builds Boost
this way also, but only for the sake of continuity.

This means that the linker confusion logic is reversed, so the problem will
will now be encountered if Bitcoin is built with --disable-reduce-exports, but
that's better than the current situation.
Reduce bitcoin-cli dependencies
Rearrange initial config checks: AC, AM, compiler, libtool.
Removed some repeated and unused prog checks.
Always log number of threads for script verification

Helps for troubleshooting.
Change -genproclimit default to 1

This is less surprising.

Avoids the overload-the-CPU default of using N threads for script
verification as well as N threads for generation where N is number of cores.
Merge pull request #5221

93a6022 Reduce bitcoin-cli dependencies (Pieter Wuille)
Reduce bitcoin-tx dependencies
Merge pull request #5213

0246ab6 depends: boost: hard-code hidden symbol visibility (Cory Fields)
Merge pull request #5223

bfe029f Reduce bitcoin-tx dependencies (Pieter Wuille)
Merge pull request #5214

eefb766 Rearrange initial config checks: AC, AM, compiler, libtool. Removed some repeated and unused prog checks. (kiwigb)
Fixing warning C4099: 'CExtPubKey' : type name first seen using 'class' now seen using 'struct'
Merge pull request #5232

5985ba9 Fixing warning C4099: 'CExtPubKey' : type name first seen using 'class' now seen using 'struct' (ENikS)
doc: Correct several typos in bootstrap.md

- Also remove references to the blockchain size
Merge pull request #5225

369be58 doc: Correct several typos in bootstrap.md (sandakersmann)
Make sure that GetRandomBytes never fails

We're using GetRandomBytes in several contexts where it's either
unwieldy to return an error, or an error would mean a fatal exception
anyhow.

@gmaxwell checked OpenSSL a while ago and discovered that it never
actually fails, but it can't hurt to be a bit paranoid here.
gather_inputs: use correct variable in error message

"amount" and "fee" do not exist (anymore?).
Do not use third party services for IP detection.

This is a simplified re-do of closed pull #3088.

This patch eliminates the privacy and reliability problematic use
of centralized web services for discovering the node's addresses
for advertisement.

The Bitcoin protocol already allows your peers to tell you what
IP they think you have, but this data isn't trustworthy since
they could lie. So the challenge is using it without creating a
DOS vector.

To accomplish this we adopt an approach similar to the one used
by P2Pool: If we're announcing and don't have a better address
discovered (e.g. via UPNP) or configured we just announce to
each peer the address that peer told us. Since peers could
already replace, forge, or drop our address messages this cannot
create a new vulnerability... but if even one of our peers is
giving us a good address we'll eventually make a useful
advertisement.

We also may randomly use the peer-provided address for the
daily rebroadcast even if we otherwise have a seemingly routable
address, just in case we've been misconfigured (e.g. by UPNP).

To avoid privacy problems, we only do these things if discovery
is enabled.