[Bitcoin-development] Block Size Experiment Underway

[Bitcoin-development] Block Size Experiment Underway

[Tom Harding]

In September, 2014, a collective experiment began in the bitcoin
ecosystem.  Available block space (1MB) began to sometimes fall short of
the space required to mine all of the transactions that would otherwise
have been included.

This chart, posted earlier, shows the onset of the
some-blocks-at-maximum era. http://i.imgur.com/5Gfh9CW.png

Although the average block is only about 400K, real blocks are bigger or
smaller due to the random length of time between blocks (and other
factors).  I look at how often this is predicted to happen.

Recently, transactions have been confirmed at a rate of about
100000/day*.  The average transaction size for the past 6000 blocks has
been 545 bytes.  Using these values,

txesPerMinute = 100000 / 24 / 60 = 69.4
txesInMaxBlock = 999977 / 545 = 1834
minutesToFillBlock = txesInMaxBlock/txesPerMinute = 26.4

Using the theoretical formula for the time before an inter-block
interval of at least a given length **

blockChickenMinutes[x] := 10 (exp(x/10) - x/10 - 1)

we obtain

minutesBetweenFullBlocks = blockChickenMinutes[minutesToFillBlock] = 104

We currently expect a maximum-size block every 1 hour + 44 minutes, on
average.  If the transaction rate doubles, we should expect a
maximum-size block every 14 minutes, on average.  The non-linearity
makes sense, because doubling the average without raising the maximum
requires disproportionately more maximum-size blocks.

This estimate is understated because transaction size and submission
rate have their own distributions.  Using the averages of 545 bytes and
100000/day ignores the fact that for some blocks, there are unusually
big and/or numerous transactions, which increases the block size
variance and causes blocks over the threshold to be encountered more
frequently.

These calculations are confirmed by empirical observation of the most
recent 6000 blocks:

http://i.imgur.com/0pQUsdl.png

In many cases, the miner chose to create a 750KB block, which is
unusually likely to be followed by another 750KB or 1MB block, because
the next interval starts off with a 250KB backlog.  Some backlog
transactions may experience more than 1 block delay in these cases.


* https://www.quandl.com/data/BCHAIN/NTRAN-Bitcoin-Number-of-Transactions

** This is a chicken-crossing-the-road problem. Wait time = (exp(λx) −
λx - 1) / λ
Some discussion at
https://github.com/nanotube/supybot-bitcoin-marketmonitor/pull/68.

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

[Raystonn .]

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

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

[Raystonn .]

> 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 

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

[Peter Todd]

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

On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > 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.

Actually they don't, which is an unfortunate problem with the existing
mempool implementation; the only way a transaction can be removed from a
Bitcoin Core mempool is through it getting mined, double-spent, or the
node restarting.

The protection that we have against that attack is that you need access
to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
consumed, and furthermore, actually getting that many transactions to
propagate over the network is non-trivial. (no, I'm not going to tell
you how)

The obvious solution is to cap the size of the mempool and evict
transactions lowest fee/KB first, but if you do that they you (further)
break zeroconf security. On the other hand, if you don't break zeroconf
security an attacker can prevent reasonable fee transactions from
propagating.

I probably should get around to fixing this...

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

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

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

[Raystonn .]

[-- 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 --]

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

[Raystonn .]

> the only way a transaction can be removed from a Bitcoin Core mempool is 
> through it getting mined, double-spent, or the node restarting.

Right.  And that results in some transactions with insufficient fees getting 
dropped today after many hours.

> The protection that we have against that attack is that you need access to 
> a lot of bitcoins to pay enough fees.

That's no protection against a well-funded private and/or public entity. 
Without the block size limit, this attack doesn't exist.  It would simply 
result in a transfer of wealth from spammer to miners, which is a nicely 
antifragile response for the Bitcoin network.


-----Original Message----- 
From: Peter Todd
Sent: Monday, June 08, 2015 2:33 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

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

Actually they don't, which is an unfortunate problem with the existing
mempool implementation; the only way a transaction can be removed from a
Bitcoin Core mempool is through it getting mined, double-spent, or the
node restarting.

The protection that we have against that attack is that you need access
to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum
relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
consumed, and furthermore, actually getting that many transactions to
propagate over the network is non-trivial. (no, I'm not going to tell
you how)

The obvious solution is to cap the size of the mempool and evict
transactions lowest fee/KB first, but if you do that they you (further)
break zeroconf security. On the other hand, if you don't break zeroconf
security an attacker can prevent reasonable fee transactions from
propagating.

I probably should get around to fixing this... 

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

[Peter Todd]

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

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

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

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

[Raystonn .]

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

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

[Bob McElrath]

[-- 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 --]

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

[Btc Drak]

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

On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . <raystonn@hotmail.com> wrote:

> No, with no blocksize limit, a spammer would would flood the network with
> transactions until they ran out of money.


I think you are forgetting even if you remove the blocksize limit, there is
still a hard message size limit imposed by the p2p protocol. Block would
de-facto be limited to this size.

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

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

[Raystonn .]

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

Not forgetting, simply deferring discussion on that.  We’ve a much smaller limit to deal with right now.  But even that limit would have to go to remove this attack.

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

On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . <raystonn@hotmail.com> wrote:

  No, with no blocksize limit, a spammer would would flood the network with
  transactions until they ran out of money.

I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size.

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

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

[Peter Todd]

[-- 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 --]

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

[Peter Todd]

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

On Mon, Jun 08, 2015 at 10:13:10PM +0000, Patrick Mccorry (PGR) wrote:
> With the 0.01mBTC/KB minimum
> relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
> 
> IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and $23k/GB (assuming $23 * 1000, as each $23 is 1mb). Only pointing out as it highlights thats it's even more expense to do.

Mike Hearn reduced the minimum relay fee to 0.01mBTC/KB:

https://github.com/bitcoin/bitcoin/pull/3305

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

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

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

[Peter Todd]

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

On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote:
> 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.

You know, you can think of Bitcoin as a system that maintains a ledger
for transferrable hashcash... Which means transaction fees *are* paid in
hashcash.

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

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

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

[Raystonn .]

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

Bandwidth can be purchased.  Infrastructure to handled increasing 
transaction volume can be purchased.  The very fees being paid by a spammer 
will be used to increase the miners' ability to absorb even more fees.  The 
blocksize limit cannot respond in such a dynamic way to attacks.  Miners 
cannot buy a greater blocksize limit in response to a spammer that is paying 
high fees to deny transaction confirmation to the rest of the planet in an 
attempt to destroy the network.  The blocksize limit is creating an attack 
that can be maintained forever by any organization that can afford to fill 
the blocks.  This attack would get incredibly cheaper once the BTCUSD market 
tanks in response to the lack of usability of the Bitcoin network, meaning 
it would be a self-reinforcing attack that would likely destroy Bitcoin for 
as long as an attacker wants to keep it up, or until you patch it to remove 
the limit after-the-fact, which might be too little too late.

If this isn't fixed, I would expect to see it carried out at some point by 
someone with a large short position in BTCUSD.

-----Original Message----- 
From: Peter Todd
Sent: Monday, June 08, 2015 3:18 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 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

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

[Loi Luu]

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

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


I would propose another practical rule rather than burning 50% of the fee.
For example, you can
credit 50% of the transaction fee to the next block. Thus, the attacker
cannot perform
the attack with 0-fee any more, yet you don't have to double the price of
the TX fee for the fix.

Thanks,
Loi Luu.

On Tue, Jun 9, 2015 at 4:07 AM, 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: 6853 bytes --]

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

[Gavin Andresen]

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

How about this for mitigating this potential attack:

1. Limit the memory pool to some reasonable number of blocks-worth of
transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict
transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.

The combination of (1) and (2) means an attacker needs to prepare lots of
confirmed inputs to pull off the attack. By itself that means they MUST pay
transaction fees.

(3) further mitigates the attack because it allows miners to just absorb
fees that the attacker is throwing at miners.


On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <loi.luuthe@gmail.com> wrote:

> 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
>
>
> I would propose another practical rule rather than burning 50% of the fee.
> For example, you can
> credit 50% of the transaction fee to the next block. Thus, the attacker
> cannot perform
> the attack with 0-fee any more, yet you don't have to double the price of
> the TX fee for the fix.
>
> Thanks,
> Loi Luu.
>
> On Tue, Jun 9, 2015 at 4:07 AM, 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
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
--
Gavin Andresen

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

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

[Tier Nolan]

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

On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB.  If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.

The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds.  This means that the cost
to maintain the attack increases.

With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool.  I think
the replace by fee code already does this.  This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.

For allowing large blocks when block space is in high demand, you could
limit the average block size.

If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower.  This gives an average of 1MB per block, but allows bursts.

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

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

[Raystonn .]

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

That does sound good on the surface, but how do we enforce #1 and #2?  They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source.

From: Gavin Andresen 
Sent: Tuesday, June 09, 2015 6:36 AM
To: Loi Luu 
Cc: Raystonn . ; Bitcoin Dev 
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

How about this for mitigating this potential attack: 

1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.

The combination of (1) and (2) means an attacker needs to prepare lots of confirmed inputs to pull off the attack. By itself that means they MUST pay transaction fees.

(3) further mitigates the attack because it allows miners to just absorb fees that the attacker is throwing at miners.


On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <loi.luuthe@gmail.com> wrote:

    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

  I would propose another practical rule rather than burning 50% of the fee. For example, you can
  credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform
  the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix.

  Thanks,
  Loi Luu.


  On Tue, Jun 9, 2015 at 4:07 AM, 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



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

  _______________________________________________
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development






-- 

--
Gavin Andresen

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

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

[Gavin Andresen]

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

On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote:

>   That does sound good on the surface, but how do we enforce #1 and #2?
> They seem to be unenforceable, as a miner can adjust the size of the memory
> pool in his local source.
>

It doesn't have to be enforced. As long as a reasonable percentage of hash
rate is following that policy an attacker that tries to flood the network
will fail to prevent normal transaction traffic from going through and will
just end up transferring some wealth to the miners.

Although the existing default mining policy (which it seems about 70% of
hashpower follows) of setting aside some space for high-priority
transactions regardless of fee might also be enough to cause this attack to
fail in practice.

-- 
--
Gavin Andresen

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

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

[Raystonn .]

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

You are right of course.  This will work.  I like this idea more than my own proposed fix, as it doesn’t make any big changes to the economics of the system in the way that burning would have.

From: Gavin Andresen 
Sent: Tuesday, June 09, 2015 11:25 AM
To: Raystonn . 
Cc: Loi Luu ; Bitcoin Dev 
Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote:

  That does sound good on the surface, but how do we enforce #1 and #2?  They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source.

It doesn't have to be enforced. As long as a reasonable percentage of hash rate is following that policy an attacker that tries to flood the network will fail to prevent normal transaction traffic from going through and will just end up transferring some wealth to the miners.

Although the existing default mining policy (which it seems about 70% of hashpower follows) of setting aside some space for high-priority transactions regardless of fee might also be enough to cause this attack to fail in practice.

-- 

--
Gavin Andresen


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

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

[David Vorick]

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

I disagree that 11 is a reasonable value. That's less than 2 hours, which
probably wouldn't even last peak trading hours. You want the mempool to be
big enough that low-fee transactions introduced during peak hours are still
around when there's much less activity (it maximizes miner profit and
prevents people/wallets from needing to resubmit after activity has died
down).

I think you'd want something closer to 72. At 1mb or even 8mb blocks, the
memory requirements are pretty reasonable. 20mb blocks and you may have to
reconsider that limit.

On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . <raystonn@hotmail.com> wrote:

>   You are right of course.  This will work.  I like this idea more than
> my own proposed fix, as it doesn’t make any big changes to the economics of
> the system in the way that burning would have.
>
>  *From:* Gavin Andresen <gavinandresen@gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn@hotmail.com>
> *Cc:* Loi Luu <loi.luuthe@gmail.com> ; Bitcoin Dev
> <bitcoin-development@lists.sourceforge.net>
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block size
> limit
>
>   On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote:
>
>>   That does sound good on the surface, but how do we enforce #1 and #2?
>> They seem to be unenforceable, as a miner can adjust the size of the memory
>> pool in his local source.
>>
>
> It doesn't have to be enforced. As long as a reasonable percentage of hash
> rate is following that policy an attacker that tries to flood the network
> will fail to prevent normal transaction traffic from going through and will
> just end up transferring some wealth to the miners.
>
> Although the existing default mining policy (which it seems about 70% of
> hashpower follows) of setting aside some space for high-priority
> transactions regardless of fee might also be enough to cause this attack to
> fail in practice.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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