Quote from: AlexGR on February 22, 2016, 09:59:21 PM

Quote from: Adrian-x on February 22, 2016, 08:36:18 PM

that same spam attack today with limited block space will crash nodes and block the mem pool for hours if not days, and cost the spammer nothing as his fees are returned to him.

0.12 (to be released tomorrow I think - still one can build from source right now) can be tuned in terms of mempool size to avoid problems.

Quote

Memory pool limiting

Previous versions of Bitcoin Core had their mempool limited by checking a transaction's fees against the node's minimum relay fee. There was no upper bound on the size of the mempool and attackers could send a large number of transactions paying just slighly more than the default minimum relay fee to crash nodes with relatively low RAM. A temporary workaround for previous versions of Bitcoin Core was to raise the default minimum relay fee.

Bitcoin Core 0.12 will have a strict maximum size on the mempool. The default value is 300 MB and can be configured with the -maxmempool parameter. Whenever a transaction would cause the mempool to exceed its maximum size, the transaction that (along with in-mempool descendants) has the lowest total feerate (as a package) will be evicted and the node's effective minimum relay feerate will be increased to match this feerate plus the initial minimum relay feerate. The initial minimum relay feerate is set to 1000 satoshis per kB.

Bitcoin Core 0.12 also introduces new default policy limits on the length and size of unconfirmed transaction chains that are allowed in the mempool (generally limiting the length of unconfirmed chains to 25 transactions, with a total size of 101 KB). These limits can be overriden using command line arguments; see the extended help (--help -help-debug) for more information.
....
https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

For non-technical guys, this means Bitcoin becomes much more hardened against possible issues that arise from spam/stress situations, despite "blocks are full".

It looks like the Core Developers did not understand the full impact of their policy change.

It seems the cause of the problem is Core 0.12 nodes and miners not relaying valid transactions, causing the mempool to expand. The net result is less nodes and nodes that don't switch to the centralized control of Core 0.12 will become overloaded contributing to the problem.