public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bob McElrath <bob_bitcoin@mcelrath.org>
To: Peter Todd <pete@petertodd.org>, "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 block	size limit
Date: Mon, 08 Jun 2015 18:06:00 -0400	[thread overview]
Message-ID: <F0732D02-2452-46FC-BBAD-9DFDA95D2EFB@mcelrath.org> (raw)
In-Reply-To: <20150608214443.GC19826@muck>

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

There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too.

Of course this is a pretty serious redesign of bitcoin, and I'm not offering a concrete proposal at this time (but have one in the works, and I'd like to see others).

I call the parameters of these hacky heuristics "Consensus Threatening Quantities" (CTQs) because changing them induces a hard fork. Bitcoin is full of them (block time, block size, target difficulty, retarget time, etc) and bitcoin would do well to face difficult redesign questions head on, and remove them entirely. (Proposal to appear...)

On June 8, 2015 5:44:43 PM EDT, Peter Todd <pete@petertodd.org> wrote:
>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.
>
>-- 
>'peter'[:-1]@petertodd.org
>0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>
>
>!DSPAM:55760d26244955859016385!
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>!DSPAM:55760d26244955859016385!

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

  parent reply	other threads:[~2015-06-08 22:06 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             ` Bob McElrath [this message]
2015-06-08 22:28               ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit 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=F0732D02-2452-46FC-BBAD-9DFDA95D2EFB@mcelrath.org \
    --to=bob_bitcoin@mcelrath.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=patrick.mccorry@newcastle.ac.uk \
    --cc=pete@petertodd.org \
    --cc=raystonn@hotmail.com \
    /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