[Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

[David Vorick]

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 at 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.
>
>  *From:* Gavin Andresen <gavinandresen at gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn at hotmail.com>
> *Cc:* Loi Luu <loi.luuthe at gmail.com> ; Bitcoin Dev
> <bitcoin-development at lists.sourceforge.net>
> *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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/792f2553/attachment.html>