drop workaround for bitcoin v0.1.5
Revert "PPCoin: More stack trace dump during serialization"

This reverts commit 59f05238ced81a41dff7499b6b7e1699bdbf9629.

Conflicts:
	src/serialize.h
Revert "PPCoin: Stack trace dump for ReadCompactSize() exception"

This reverts commit 17382b40fae13629d0a7c77806bd9e73972f061d.

Conflicts:
	src/makefile.unix
	src/serialize.h
	src/util.cpp
	src/util.h
Reject non-canonically-encoded sizes

The length of vectors, maps, sets, etc are serialized using
Write/ReadCompactSize -- which, unfortunately, do not use a
unique encoding.

So deserializing and then re-serializing a transaction (for example)
can give you different bits than you started with. That doesn't
cause any problems that we are aware of, but it is exactly the type
of subtle mismatch that can lead to exploits.

With this pull, reading a non-canonical CompactSize throws an
exception, which means nodes will ignore 'tx' or 'block' or
other messages that are not properly encoded.

Please check my logic... but this change is safe with respect to
causing a network split. Old clients that receive
non-canonically-encoded transactions or blocks deserialize
them into CTransaction/CBlock structures in memory, and then
re-serialize them before relaying them to peers.

And please check my logic with respect to causing a blockchain
split: there are no CompactSize fields in the block header, so
the block hash is always canonical. The merkle root in the block
header is computed on a vector<CTransaction>, so
any non-canonical encoding of the transactions in 'tx' or 'block'
messages is erased as they are read into memory by old clients,
and does not affect the block hash. And, as noted above, old
clients re-serialize (with canonical encoding) 'tx' and 'block'
messages before relaying to peers.

Conflicts:
	src/main.cpp
	src/test/serialize_tests.cpp
Only send reorged txn to mempool after checkpoint

Conflicts:
	src/main.cpp
Fix multi-block reorg transaction resurrection

Conflicts:
	src/main.cpp
Revert "Partially revert "Remove broken option to skip input checking for wallet"

This reverts commit 7c2f170a5917037b9bdeabfe40eeee70cbb0533f.

Conflicts:
	src/main.cpp
	src/main.h
qt: get required locks upfront in polling functions

This avoids the GUI from getting stuck on
periodical polls if the core is holding the locks for a longer time -
for example, during a wallet rescan.

Conflicts:
	src/qt/transactiontablemodel.cpp
	src/qt/walletmodel.cpp
askpassphrasedialog: clear pass fields on accept
fix memory leak
AvailableCoins: acquire cs_main mutex

It's required when called from WalletModel
refactor coin selection for staking
update readme-qt.rst
fix relock on sending coins when "for staking only" is activated

Sets the checkbox in the askpassphrase dialog to the previous value of
fWalletUnlockStakingOnly resolving the issue that the wallet gets locked
after sending coins when "for staking only" is activated.
Allocate receive buffers in on the fly
remove unused CNode::Cleanup()

Conflicts:
	src/net.cpp
Internal RNG for approximateBestSubset to prevent degenerate behavior.

This fixes test_bitcoin failures on openbsd reported by dhill on IRC.

  On some systems rand() is a simple LCG over 2^31 and so it produces
an even-odd sequence.  ApproximateBestSubset was only using the least
significant bit and so every run of the iterative solver would be the
same for some inputs, resulting in some pretty dumb decisions.

Using something other than the least significant bit would paper over
the issue but who knows what other way a system's rand() might get us
here.  Instead we use an internal RNG with a period of something like
2^60 which is well behaved.  This also makes it possible to make the
selection deterministic for the tests, if we wanted to implement that.
Remove -detachdb and stop's detach argument.

As the only BDB database left is the wallet, and it is always
detached.

Also remove IsChainFile() predicate and related chainfile-specific
logic.

Conflicts:
	src/bitcoinrpc.cpp
	src/db.cpp
	src/qt/bitcoinstrings.cpp
Treat non-final transactions as non-standard

At least one service that accepted zero-confirmation transactions
was vulnerable because an attacker could send a transaction
with a lock time far in the future, and then have plenty of time in
which to get a double-spend mined (perhaps from a miner who wasn't
on the network when the first transaction was broadcast).

That is a variation on the "Finney attack". We still don't
recommend anybody accept 0-confirmation transactions as final
payment for anything. This change keeps non-final transactions
from appearing in the wallet, and, assuming most of the network
accepts this change, will prevent them from being relayed until
they are final.
Comments for constants

Conflicts:
	src/main.h