It is easily confused with CCoinsViewCache(CCoinsView*), which creates a sub-cache, but instead of creating a sub-cache, the copy constructor would copy the original and use that original's base, defeating the intended isolation.
Previously an empty script wouldn't be hashed, and CScriptID would be
assigned the incorrect value of 0 instead. This bug can be seen in the
RPC decodescript command:
$ btc decodescript ""
{
"asm" : "",
"type" : "nonstandard",
"p2sh" : "31h1vYVSYuKP6AhS86fbRdMw9XHieotbST"
}
Correct output:
$ btc decodescript ""
{
"asm" : "",
"type" : "nonstandard",
"p2sh" : "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy"
}
Don't allow immediate inv driven block downloads if
a peer already has MAX_BLOCKS_IN_TRANSIT_PER_PEER
active downloads. Prevents bogus inv spam from
blowing up block transfer tracking data structures.
Previously the minRelayTxFee was only enforced on user specified values.
It was possible for smartfee to produce a fee below minRelayTxFee which
would just result in the transaction getting stuck because it can't be
relayed.
This also introduces a maxtxfee option which sets an absolute maximum
for any fee created by the wallet, with an intention of increasing
user confidence that the automatic fees won't burn them. This was
frequently a concern even before smartfees.
If the configured fee policy won't even allow the wallet to meet the relay
fee the transaction creation may be aborted.
'Sane' was already defined by this code as:
fee.GetFeePerK() > minRelayFee.GetFeePerK() * 10000
But sanity was only enforced for data loaded from disk.
Note that this is a pretty expansive definition of 'sane': A 10 BTC
fee is still passes the test if its on a 100kb transaction.
This prevents a single insane fee on the network from making us reject
our stored fee data at start. We still may reject valid saved fee
state if minRelayFee is changed between executions.
This also reduces the risk and limits the damage from a cascading
failure where one party pays a bunch of insane fees which cases
others to pay insane fees.