public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: David Vorick <david.vorick@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
Date: Fri, 19 Jun 2015 23:49:28 -0400	[thread overview]
Message-ID: <CAFVRnyrDJCUo1VUsfK5mXZYMCc6iaWhho9-1ks0a-pE+1SGRng@mail.gmail.com> (raw)
In-Reply-To: <COL131-DS897EBDD5B5E7BD300318CCDBE0@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

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.
>
>  *From:* Gavin Andresen <gavinandresen@gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn@hotmail.com>
> *Cc:* Loi Luu <loi.luuthe@gmail.com> ; Bitcoin Dev
> <bitcoin-development@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@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
>
>

[-- Attachment #2: Type: text/html, Size: 4353 bytes --]

      reply	other threads:[~2015-06-20  3:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08  0:36 [Bitcoin-development] Block Size Experiment Underway Tom Harding
2015-06-08 20:07 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Raystonn .
     [not found]   ` <AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
2015-06-08 21:14     ` Raystonn .
2015-06-08 21:33       ` Peter Todd
2015-06-08 21:40         ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit Raystonn .
     [not found]         ` <4A74E0B9-869E-448A-BFC7-7FD2F50F142F@newcastle.ac.uk>
2015-06-08 22:26           ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Peter Todd
     [not found]       ` <7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
2015-06-08 21:33         ` Raystonn .
2015-06-08 21:44           ` Peter Todd
2015-06-08 22:01             ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit Raystonn .
2015-06-08 22:07               ` Btc Drak
2015-06-08 22:10                 ` Raystonn .
2015-06-08 22:18               ` Peter Todd
2015-06-08 22:46                 ` Raystonn .
2015-06-08 22:06             ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Bob McElrath
2015-06-08 22:28               ` Peter Todd
2015-06-09  9:33   ` Loi Luu
2015-06-09 13:36     ` Gavin Andresen
2015-06-09 14:18       ` Tier Nolan
2015-06-09 17:52       ` Raystonn .
2015-06-09 18:25         ` Gavin Andresen
2015-06-09 19:03           ` Raystonn .
2015-06-20  3:49             ` David Vorick [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFVRnyrDJCUo1VUsfK5mXZYMCc6iaWhho9-1ks0a-pE+1SGRng@mail.gmail.com \
    --to=david.vorick@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox