I disagree that 11 is a reasonable value. That's less than 2 hours, which probably wouldn't even last peak trading hours. You want the mempool to be big enough that low-fee transactions introduced during peak hours are still around when there's much less activity (it maximizes miner profit and prevents people/wallets from needing to resubmit after activity has died down).

I think you'd want something closer to 72. At 1mb or even 8mb blocks, the memory requirements are pretty reasonable. 20mb blocks and you may have to reconsider that limit.

On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . <raystonn@hotmail.com> wrote:
You are right of course.  This will work.  I like this idea more than my own proposed fix, as it doesn’t make any big changes to the economics of the system in the way that burning would have.
 
Sent: Tuesday, June 09, 2015 11:25 AM
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
 
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote:
That does sound good on the surface, but how do we enforce #1 and #2?  They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source.
 
It doesn't have to be enforced. As long as a reasonable percentage of hash rate is following that policy an attacker that tries to flood the network will fail to prevent normal transaction traffic from going through and will just end up transferring some wealth to the miners.
 
Although the existing default mining policy (which it seems about 70% of hashpower follows) of setting aside some space for high-priority transactions regardless of fee might also be enough to cause this attack to fail in practice.
 
--
--
Gavin Andresen
 

------------------------------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development