Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

["Raystonn ." <raystonn@hotmail.com>]

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

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

For attacks being waged to push up minimum fees for the benefit of miners, by filling the mempool with enough spam transactions with the floor fee to cover a new block every time another block is discovered, they stand to gain.  Whatever fees they are paying, real transactions will have to pay more to get through.  It can be a net gain depending on how many miners are participating.


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

    If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.

  You are assuming here that you can identify which transactions are spam, and which are not, and then segregate the spam into a separate channels of transactions for inclusion on a 50/50 basis alongside other transactions. There is no guarantee you will be able to identify those transactions. Sure, if you can do that, then the easy fix is just to put them into a lower class channel of transactions that guarantee no pressure on the non-spam transactions.  But it's just not possible to do this in any meaningful way. If you wanted to try, it would certainly add quite a bit of cost and complexity on the miner's side, and you aren't going to get anything other than the simple spam that comes from the same set of addresses.

Well it depends how the transactions spam - if you do a huge link of transactions (one after another, with the total bitcoins "sent" being reduced by a fee each time) this is easily identifiable - if you were to do it using unlinked transactions then this would require 2x the setup (do a lot of mixing to get 1 million unlinked outputs and then commence attack) which doubles the cost of the attack. 

    If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes

  You need to account for the transactions coming from real users.  Every real transaction is approximately one less spam transaction you need to fill the blocks.


I was suggesting the cost of an adversary to send the spam - if he did manage to fill the entire block each time that's the maximum charge. Of course the costs get spread out if normal transactions are included. 

    there is no memory pool cap currently

  Real hardware does not have an infinite amount of RAM.  Memory pool sizes cannot grow unbounded.  Some transactions with insufficient fees do get dropped today after many hours.

That's true that's why I used 250mb as an example to cost $30k. Cheap laptops today (around £300) come with 6gb ram - so the attack would be expensive. 

I do doubt the miners codes probably are not prepared for an attack of this type - but it is really expensive to pull off from what I can see. 

Sent from my iPhone

On 8 Jun 2015, at 22:14, Raystonn . <raystonn@hotmail.com> wrote:


    If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.


  You are assuming here that you can identify which transactions are spam, and which are not, and then segregate the spam into a separate channels of transactions for inclusion on a 50/50 basis alongside other transactions. There is no guarantee you will be able to identify those transactions. Sure, if you can do that, then the easy fix is just to put them into a lower class channel of transactions that guarantee no pressure on the non-spam transactions.  But it's just not possible to do this in any meaningful way. If you wanted to try, it would certainly add quite a bit of cost and complexity on the miner's side, and you aren't going to get anything other than the simple spam that comes from the same set of addresses.


    If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes


  You need to account for the transactions coming from real users.  Every real transaction is approximately one less spam transaction you need to fill the blocks.


    there is no memory pool cap currently


  Real hardware does not have an infinite amount of RAM.  Memory pool sizes cannot grow unbounded.  Some transactions with insufficient fees do get dropped today after many hours.


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

  Please correct me if I'm wrong (hopefully understood it). I don't think normal users would need to pay a higher fee - as miners can just ignore the spam (since they will all be linked).

  If I were to spam a lot of transactions to fill the memory pool it would cost $120 every 10 minutes (assuming 4,000 tx can fit inside a block and 3 cents per transaction), anything exceeding that may be considered "spam" - although I don't know if it would be "free" as the miner will eventually claim all the fees, delayed payment is probably a better way to describe it. IIRC, there is no memory pool cap currently. To spam 1 million transactions would cost $30k which would take up approx 250 blocks (around 250mb) which is around 42 hours to process. I think the memory pool can handle this data today (someone more knowledgeable can check this for me) - so the attack is v.expensive to carry out.

  A good way to prevent this spamming the memory pool is to only accept up to a 'x' length of 0-confirmed transactions to make it more difficult to pull off (not impossible).

  If I were a miner under this attack, I would just use the spam to fill up blocks alongside normal transactions maximising my profit.

  Sent from my iPhone


    On 8 Jun 2015, at 21:09, Raystonn . <raystonn@hotmail.com> wrote:



    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





    ------------------------------------------------------------------------------

    _______________________________________________

    Bitcoin-development mailing list

    Bitcoin-development@lists.sourceforge.net

    https://lists.sourceforge.net/lists/listinfo/bitcoin-development 



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