public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Raystonn ." <raystonn@hotmail.com>
To: "Peter Todd" <pete@petertodd.org>
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 15:01:34 -0700	[thread overview]
Message-ID: <COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl> (raw)
In-Reply-To: <20150608214443.GC19826@muck>

> 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.

> 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.

> 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.


-----Original Message----- 
From: Peter Todd
Sent: Monday, June 08, 2015 2:44 PM
To: Raystonn .
Cc: Patrick Mccorry (PGR) ; Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential 
solution described: Dropped-transaction spam attack against the blocksize 
limit

On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spam 
> transactions, the attack succeeds when the attacker is well funded.  This 
> gives well-funded private and/or public entities the means to destroy 
> Bitcoin if they desire.  This is only true after the block size limit was 
> implemented.  Without the block size limit, the spam doesn’t harm Bitcoin. 
> It simply enriches miners at the cost of the spammers, which is a nicely 
> antifragile quality.

There will always be a blocksize limit based on technological 
considerations - the network has a finite bandwidth limit.

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.

The worst an attacker flooding the network with transactions with a 
blocksize limit can do is raise costs, without harming security. Keep in 
mind, that at some point it'd be cheaper to just 51% attack the network. 
Based on the current block subsidy of 25BTC/MB that's at the point where 
transaction fees are 25mBTC/KB, which corresponds to <$2/tx fees - not that 
cheap, but still quite affordable for a large percentage of Bitcoin's users 
right now. And that's the *absolute worst-case* attack possible.




  reply	other threads:[~2015-06-08 22:01 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             ` Raystonn . [this message]
2015-06-08 22:07               ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit 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

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=COL131-DS52C1B18F4EFC4D7D7EEA1CDBF0@phx.gbl \
    --to=raystonn@hotmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=patrick.mccorry@newcastle.ac.uk \
    --cc=pete@petertodd.org \
    /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