<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <span dir="ltr">&lt;<a href="mailto:gavinandresen@gmail.com" target="_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How about this for mitigating this potential attack:<div><br></div><div>1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11)</div><div>2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions.</div><div>3. Allow blocks to grow in size in times of high transaction demand.</div><div><br></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><br></div><div class="gmail_quote"></div><div class="gmail_quote">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.<br><br></div><div class="gmail_quote">For allowing large blocks when block space is in high demand, you could limit the average block size.<br><br></div><div class="gmail_quote">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.<br></div></div></div>