On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:

How about this for mitigating this potential attack:

1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.

I think 2 should just be fee per kB. If the pool is full and a transaction arrives, it has to have a fee per kB that is higher than the lowest transaction in the pool.

The effect is that the fee per kB threshold for getting a transaction into the memory pool increases as the attack proceeds. This means that the cost to maintain the attack increases.

With replace by fee, the new transaction would have to have a fee that is more than a fixed amount more than the lowest already in the pool. I think the replace by fee code already does this. This prevents transactions with fees that increase by 1 Satoshi at a time being relayed.

For allowing large blocks when block space is in high demand, you could limit the average block size.

If the average was set to 1MB, the rule could be that blocks must be 2MB or lower and the total size of the a block and the previous 99 must be 100MB or lower. This gives an average of 1MB per block, but allows bursts.