There is no reason to store thousands of orphan transactions;
normally an orphan's parents will either be broadcast or
mined reasonably quickly.

This pull drops the maximum number of orphans from 10,000 down
to 100, and adds a command-line option (-maxorphantx) that is
just like -maxorphanblocks to override the default.

Rebased-From: 7b45d943

Prevent denial-of-service attacks by banning
peers that send us invalid orphan transactions
and only storing orphan transactions given to
us by a peer while the peer is connected.

Rebased-From: c74332c6

reduces time to service requests improving performance

Rebased-From: 9189f5fe

It's only confusing people into thinking that they should mess with
boost versions, which should not be necessary to get bitcoind to work.

If there is a bug in the build system with autodetecting boost it needs
to be solved not worked around.

Rebased-From: 539abc47

Bitcoin core should work with any remotely recent boost version
if a proper build environment is present. Remove a confusing comment
from the build documentation.

Rebased-From: bd45b1ab

Rebased-From: 540ac451

Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>

Tighten resource constraints on CNode.

Rebased-From: d4168c82

Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>

Rebased-From: def2fdb4
Rebased-By: Wladimir J. van der Laan

Rebased-From: 89d91f6a

Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>

This does not add any new messages from transifex, it just filters the
current ones.

- Catch problems such as mismatched formatting characters. Remove
  messages that can give problems at runtime.

- Also remove unfinished/untranslated messages, they just take up space
  in the ts and waste parsing time.

Fixes #4774.

Rebased-From: da59f283
Rebased-By: Wladimir J. van der Laan

Also change build system: STATICLIB is now MINIUPNP_STATICLIB.

The homebrew instructions were outdated - berkeley-db4 hasn't worked for months, based on the questions I'm seeing on Google/SO.  So I added a section explaining how to install berkeley-db4 using homebrew and move on with your life.  Thanks for the rest of the documentation!
Conflicts:
	doc/build-osx.md

Rebased-From: b1ed7c29

Rebased-From: 565e5697

This probably never worked properly. Confirmed working now with every compiler
I throw at it.

Rebased-From: 8021cf8d

When the libpath doesn't line up with the value from config.sub, we don't find
the correct path to boost's libs. This adds a hack to try another path before
giving up.

Should close #3219.

Rebased-From: 54c7df81

Conflicts:
	src/qt/bitcoin.cpp

Rebased-From: 292cc072

Upgrade for https://www.openssl.org/news/secadv_20140806.txt

Rebased-From: 074bcdc
Github-Pull: #4648

The goal is to increase independence and privacy.

Rebased-From: 2e7009d6

Removes the limits on number of pubkeys for P2SH CHECKMULTISIG outputs.
Previously with the 500 byte scriptSig limit there were odd restrictions
where even a 1-of-12 P2SH could be spent in a standard transaction(1),
yet multisig scriptPubKey's requiring more signatures quickly ran out of
scriptSig space.

From a "stuff-data-in-the-blockchain" point of view not much has changed
as with the prior commit now only allowing the dummy value to be null
the newly allowed scriptSig space can only be used for signatures. In
any case, just using more outputs is trivial and doesn't cost much.

1) See 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
   Mined by BTC Guild.

redeemScripts >520bytes can't be spent due to the
MAX_SCRIPT_ELEMENT_SIZE limit; previously the addmultisigaddress and
createmultisig RPC calls would let you violate that limit unknowingly.

Also made the wallet code itself check the redeemScript prior to adding
it to the wallet, which in the (rare) instance that a user has added an
invalid oversized redeemScript to their wallet causes an error on
startup. The affected key isn't added to the wallet; other keys are
unaffected.

This avoids that long redeemScripts that were grandfathered in
prevent the wallet from loading.

Fixes #4313.

Rebased-From: 18116b06

Rebased-From: 88df548d

Previously if bitcoind is linked with an OpenSSL which is compiled
without EC support, this is seen as an assertion failure "pKey !=
NULL" at key.cpp:134, which occurs after several seconds. It is an
esoteric piece of knowledge to interpret this as "oops, I linked
with the wrong OpenSSL", and because of the delay it may not even
be noticed.

The new output is

: OpenSSL appears to lack support for elliptic curve cryptography. For
more information, visit
https://en.bitcoin.it/wiki/OpenSSL_and_EC_Libraries
: Initialization sanity check failed. Bitcoin Core is shutting down.

which occurs immediately after attempted startup.

This also blocks in an InitSanityCheck() function which currently only
checks for EC support but should eventually do more. See #4081.

Rebased-From: 4a09e1df

Block 295,000 seems to meet the criteria of a reasonable timestamp and
no strange transactions. 295,000 is the current block height in the
bootstrap.dat torrent provided by jgarzik.

Rebased-From: 125fba1b

and use it for most strings being serialized.

Rebased-From: 216e9a44

Rebased-From: 45abeb21

It's required when called from WalletModel

Rebased-From: ea3acaf3

Rebased-From: 954d2e72

Passes tests:

```
$ ./bitcoin-qt 'bitcoin:?r=http://www.example.com/'
.. fixed the original problem - this launches mainnet.

$ ./bitcoin-qt 'bitcoin:mngeNQbTKnmaMbx8EXCYdwUbnt9JJD52cC'
.. launches testnet

$ ./bitcoin-qt -testnet 'bitcoin:1NXXeQRyMFFFRfyUix2o7mk1vhvk2Nxp78'
.. sanity check - launches mainnet.
```

Fixes #4355. Closes #4411.

Rebased-From: dd49e92f

Rebased-From: 6265ecc8

Rebased-From: 48d8eb18 27bff74e 4f497cd9 05e3ecff 90320d67 b1fdd547

Rebased-From: a7e1d503