Quote from: JorgeStolfi on October 13, 2015, 09:06:45 PM

Quote from: muyuu on October 13, 2015, 05:15:37 PM

For the spam justification of the limit you have to ask Satoshi.

Spam attacks have also been proven a very real threat.

There are several hypothetical attacks that could be called "spam attacks".

One type (1) is what we have seen since July this year: issue hundreds of MB of cheap transactions, to fill the queues and maybe crash the relay nodes (and generally cause trouble for software that deals with the queues. That attack does not affeact transactions that pay fees higher than the attacker pays. It will delay zero- and low-fee transactions. The delay depends on the clearance C - T between the average capacity C of the network (currently ~0.80 MB/block) and the average non-spam incoming traffic T (currently ~0.45 MB/block). Currently, with less than 50'000 USD anyone can launch an attack that clog the queues and delay low-fee transactions for 2-3 weeks or more.

Another type (2), that we have not seen yet, tries to delay some of the high-paying fee too. To hold up 50% of the legitimate traffic, for example, an attacker of this type would keep issuing transactions with suitable fees to ensure that the top 0.80 MB of the queue always included at least 0.58 MB of his own transactions. That is, he would have to issue C - T/2 transactions per block, with enough fees to keep the low half of the legitimate traffic perpetually out of the next block. I don't know how much this attack would cost per hour; but I guess that an attacker with 50'000 USD budget would be able to keep it up for at least half a day.

Yet another type (3) of attack may be a miner creating and solving a large bock to cause relay nodes and some clients to crash. Rumor is that the 1 MB limit was introduced to prevent hypothetical type (3) attacks, or some similar one. But there was no such attack during the 20 months or so in 2009 and 2010 that bitcoin operated with a 32 MB block size limit; and it is not clear whether such a rogue miner could do much damage except to himself.

On the other hand, presently it is the 1 MB limit that makes attacks of type (2) viable, and causes type (1) attacks to delay low-fee transactions by weeks.

If the block size limit were to be raised to 8 MB, the effective capacity C would rise from 0.80 MB/block to maybe 6.00 MB/block . The clearance C - T would then increase from 0.35 to 5.65 MB/block. That would speed up the recovery after type (1) attacks some 15-fold, so a backlog that now takes 2 weeks to clear (like the one that exists now) would be cleared in 1 day.

If the block size limit were to be raised to 8 MB, a type (2) attacker who wanted to hold up 50% of the legitimate traffic would have to issue 5.77 MB of transactions per block, instead of 0.58 MB/block; but he would need to pay the same fees in order to keep the half of the traffic out. Therefore the cost to the attacker, per hour, would be ~10 times larger.

Far from being an argument against a block size increase, spam attacks are one of the strongest reasons why the increase should be a no-brainer. In fact, deterrence of and resilience against spam attacks demand a large increase rather than a small one.

(4) The apparent cloning of transactions, with a slight difference. Only one of which is valid. Causing spurs and reshuffles. this apparently with less cost because the invalid transactions are eventually rejected as such.