public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: "Raystonn ." <raystonn@hotmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
	"Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle•ac.uk>
Subject: Re: [Bitcoin-development] New attack identified and potential solution	described: Dropped-transaction spam attack against the blocksize limit
Date: Mon, 8 Jun 2015 18:18:43 -0400	[thread overview]
Message-ID: <20150608221843.GA4275@muck> (raw)
In-Reply-To: <COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl>

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

On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
> >There will always be a blocksize limit based on technological
> >considerations - the network has a finite bandwidth limit.
> 
> A bandwidth limit is not the same as a blocksize limit.  Bandwidth
> is unique to every individual.  Miners in China have different
> bandwidth and connectivity than miners in the U.S., for example.
> But the block size limit is dictated for eveyone.  They are not
> comparable.

Bitcoin is a global consensus system - if you're bandwidth isn't
sufficient to keep up you are not part of the consensus.

The blocksize limit *is* what determines the minimum bandwidth required
to stay in consensus.

> >Without a blocksize limit the attacker would just flood the
> >network until the bandwidth usage became so great that consensus
> >would fail, rendering Bitcoin both worthless, and insecure.
> 
> No, with no blocksize limit, a spammer would would flood the network
> with transactions until they ran out of money.  Meanwhile, everyone
> would jump on board trying to mine the blocks to collect the fees
> from the spammers.  It could be one of the greatest transfers of
> wealth ever.  Bitcoin infrastructure would build up to handle the
> required bandwidth, paid for by the very entity spamming the
> network.  Bitcoin would flourish, growing wildly as long as the fees
> kept coming.  This is antifragility at its best.

Again, in your scenario if the bandwidth consumed by those transactions
was sufficiently high, the network would collapse because consensus
would fail.

Why wouldn't that bandwidth be high enough to cause that collapse?
Because of the blocksize limit! (combined with an intelligent mempool
that increases the minimum fee/KB appropriately - we don't have that
yet)

> >The worst an attacker flooding the network with transactions with
> >a blocksize limit can do is raise costs, without harming security.
> 
> No, at attacker flooding the network with transactions with a
> blocksize limit can keep their fees high enough that perhaps 1% of
> transactions coming from real end-users go through.  At this point
> everyone would give up on Bitcoin as it would become completely
> unusable.  The BTCUSD market would tank, making it even easier to
> pay the transaction fees to keep real transactions out of blocks, as
> it would continue to become cheaper and eventually cost-free to
> obtain the bitcoin fees through market purchase.

I already did the math for you on that: the maximum transaction fee
you'd see in that kind of attack is around $2.5 USD/tx. That definitely
is not high enough to make Bitcoin non-viable - I personally could
easily afford fees like that for about 90% of my transactions this year
by value, as I mainly use Bitcoin to get paid by my clients around the
world. In fact, just today O'Reilly paid $15 USD to send me a wire
transfer for expenses related to a conference I was invited too.

A much more realistic transaction flood scenario - one that didn't raise
serious questions about whether or not the attacker could afford to 51%
attack Bitcoin - would raise tx fees to something more like $0.25/tx

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  parent reply	other threads:[~2015-06-08 22:19 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 [this message]
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

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=20150608221843.GA4275@muck \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=patrick.mccorry@newcastle$(echo .)ac.uk \
    --cc=raystonn@hotmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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