public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Raystonn ." <raystonn@hotmail.com>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
Date: Mon, 8 Jun 2015 13:07:59 -0700	[thread overview]
Message-ID: <COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl> (raw)
In-Reply-To: <5574E39C.3090904@thinlink.com>

When implemented, the block size limit was put in place to prevent the 
potential for a massive block to be used as an attack to benefit the miner 
of that block.  The theory goes that such a massive block would enrich its 
miner by delaying other miners who are now busy downloading and validating 
that huge block.  The original miner of that large-block would be free to 
continue hashing the next block, giving it an advantage.

Unfortunately, this block size limit opened a different attack.  Prior to 
the limit, any attempt to spam the network by anyone other than someone 
mining their own transactions would have been economically unfeasible.  As 
every transaction would have a fee, there would have been a real cost for 
every minute of spam.  The end result would have been a transfer of wealth 
from spammer to Bitcoin miners, which would have harmed the spammers and 
encouraged further mining of Bitcoin, a very antifragile outcome.

But now we have the block size limit.  Things are very different with this 
feature in place.  The beginning of a spam attack on the Bitcoin network 
will incur transaction fees, just like before.  But if spam continues at a 
rate exceeding the block size limit long enough for transactions to be 
dropped from mempools, the vast majority of spam transaction fees will never 
have to be paid.  In fact, as real users gain in desperation and pay higher 
fees to get their transactions through in a timely manner, the spammers will 
adjust their fees to minimize the cost of the attack and maximize 
effectiveness.  Using this method, they keep their fees at a point that 
causes most of the spam transactions to be dropped without confirmation 
(free spam), while forcing a floor for transaction fees.  Thus, while spam 
could be used by attackers to disable the network entirely, by paying 
high-enough fees to actually fill the blocks with spam, it can also be used 
by a single entity to force a transaction fee floor.  Real users will be 
forced to pay a transaction fee higher than the majority of the spam to get 
their transactions confirmed.  So this is an effective means for a minority 
of miners to force higher fees through spam attacks, even in the face of 
benevolent miners who would not support a higher fee floor by policy. 
Miners would simply have no way to fix this, as they can only put in the 
transactions that will fit under the block size limit.

In the face of such a spam attack, Bitcoin's credibility and usability would 
be severely undermined.  The block size limit enables this attack, and I now 
argue for its removal.  But we can't just remove it and ignore the problem 
that it was intended to address.  We need a new fix for the large-block 
problem described in the first paragraph that does not suffer from the 
dropped-transaction spam-attack problem that is enabled by the block size 
limit today.  My proposal is likely to be controversial, and I'm very much 
open to hearing other better proposals.

Large blocks created by a miner as a means to spam other miners out of 
competition is a problem because miners do not pay fees for their own 
transactions when they mine them.  They collect the fees they pay.  This 
breaks the economic barrier keeping people from spamming the network, as the 
spamming is essentially free.  The proposed fix is to add a new rule on how 
fees are handled.  Some amount of every fee should be considered as burned 
and can never be spent.  I will propose 50% of the fee here, but there may 
be better numbers that can be discovered prior to putting this into place. 
If we'd like miners to continue to collect the same fees after this change, 
we can suggest the default fee per transaction to be doubled.  Half of every 
fee would be burned and disappear forever, effectively distributing the 
value of those bitcoins across the entire money supply.  The other half 
would be collected by the miner of the block as is done today.  This 
solution would mean large blocks would cost a significant number of bitcoin 
to create, even when all of the transactions are created by the miner of 
that block.  For this to work, we'd need to ensure a minimum fee is paid for 
most of the transactions in every block, and the new transaction fee rule is 
in place.  Then the block size limit can be removed.

Raystonn




  reply	other threads:[~2015-06-08 20:08 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 ` Raystonn . [this message]
     [not found]   ` <AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
2015-06-08 21:14     ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit 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

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-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl \
    --to=raystonn@hotmail.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