0

Wikipedia explains the rationale behind the 1 MB block size limit as follows:

The one megabyte block size limit was added in 2010 by Satoshi Nakamoto as a temporary anti-DoS measure

A SE post expounds on this:

Usually Denial Of Service(DoS) attack may take place on larger sized blocks. So to avoid this condition initially block size Bitcoin was chosen to be 1Mb. Because attacker sends a lot of data in the network to make it busy so that the actual transactions are not able to take place

What I don't understand is:

1) What stops an attacker from sending illegitimate transactions to quickly filling up the 1 Mb block size in order to perform a DoS attack? What is it about bigger block size that makes this attack more likely?

2) Is there a way to empirically demonstrate that a block size of 1 Mb is less likely to suffer a DoS attack compared to a block size of say 1 GB?

Considering the block size is one of the biggest bottle necks to BTC scalability it seems like a no-brainer that something like has to be proven. A block size of 1 GB would be able to process 1,000 x more transactions per sec compared to a block size of 1 mb.

Thanks

2
  • 2
    You're misunderstanding: this is about DoS concerns on validating nodes, who need to process all transactions in all blocks, keep up with the network, and the ability for nodes to validate history. It isn't about the ability for transactions creators to get their transactions accepted; that's just a free market where everyone can bid for the available space - there are no illegitimate transactions from that perspective. Jan 24 at 5:31
  • The question links to the BU Wikipedia page. This has nothing to do with Bitcoin. Any amateur or scammer can take the Bitcoin source and proclaim their own coin, including revisionist history.
    – Jannes
    Jan 24 at 11:40
3

The DoS the block size limitation is trying to prevent is a miner creating a huge block of garbage data that now every single Bitcoin miner must download, validate, and store the entirety of. Imagine if some miner decided to create block after block of 1GB of garbage, and now every single Bitcoin node in the world must store and validate all of this garbage. If it were possible, this would be in the best interests of larger miners to do: smaller miners, who don't have the ability to download and validate these giant blocks of garbage as efficiently, will not be able to keep up with mining.

Also, people do attempt to submit spam to the blockchain. Trying to do so to the point of blocking out legitimate transactions will be quite expensive, considering you would have to pay transaction fees for every "spam" transaction you want to send.

11
  • @ ieatpizza thanks for your reply. If you could clarify 1) If the block turns out to be "garbage" (by that you mean it would contain invalid transactions or just missing/fake hash?) the miner won't get reward so wouldn't that reduce his incentive to do so? 2) what stops a miner from repeatedly producing garbage blocks of 1 MB? True, it is easier/faster to download/process but what stops a miner from producing thousands of illegitimate blocks? 3) What is the main bottleneck here - bandwidth, processing (CPU) or storage (hard drive)?
    – S.O.S
    Jan 24 at 6:04
  • 2
    @S.O.S 1) By garbage data in blocks I mean some miner mining a valid block but including spam transactions (such as transactions that include a large amount of junk data). They still get the block reward since it is still a valid block, they are just missing out on transaction fees from legitimate transactions. 2) Because the profit margins are already so low, and by doing so they lose out on the fees that make up a large portion of their profit. If they won't take that profit, another miner will. 3) All 3, although I expect bandwidth and storage are the most expensive.
    – ieatpizza
    Jan 24 at 6:18
  • thanks for the clarification. From a purely tech perspective, wouldn't it be possible to detect when a miner includes "spam" data (or "junk data" as you call it) and have the nodes reject these kind of blocks (in order to disincentives miners from doing this)?
    – S.O.S
    Jan 24 at 6:28
  • 1
    The nice thing about a market that competes for blockspace is that nobody needs to make a determination about what is spam and what isn't (which is highly undesirable... how do you prevent such a system from being abused for targetted censorship?). Jan 24 at 6:45
  • 1
    @DavidLynch Your proposed solution is to take away one of the main selling points of BTC. The way it's set up right now is meant to limit BTC inflation, and it's not likely the majority of BTC users, many of whom see BTC as an asset to protect against arbitrary inflation, are going to agree with a fork that would allow such extreme inflation. It would ruin the value of all existing coins. As for future, more sustainable alternatives to proof-of-work mining, I prefer moving to a proof-of-stake algorithm eventually, but it's debatable. But, this is probably a topic for another question. :)
    – ieatpizza
    Jan 24 at 16:55
2

This does not address your main question but response to some of the wrong assumptions in the question:

  1. Bitcoin blocksize is not 1 MB: What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Blocksize

  1. A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

  1. Increasing the blocksize every few months or increasing it by more than 1000x will most probably increase the blockchain size unexpectedly/rapidly, cost to run full nodes and other issue so decrease decentralization.

blocksize-decentralizations

  1. 1 Bitcoin transaction can be done for more than 1 real world payment so transactions per second when comparing with few other systems is a wrong metric in my opinion and explained here: https://bitcoin.stackexchange.com/a/100829/

  2. Bitcoin scaling works in layers: https://bitcoinkpis.com/layer2 and this does not mean on-chain development has stopped or will not focus on scaling. Example:

Compared to ECDSA signatures, Schnorr signatures are between 6 and 9 byte shorter. These savings stem from the removed encoding overhead and the default SigHash flag. With a Schnorr signature adoption of 20%, and assuming all of the 800.000 inputs spent per day contain only a single signature, more than 1MB of blockchain space is saved per day.

https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/

5
  • @_Prayank Regarding Point 4: Increasing the # of outputs in a single transaction also increases size it's just not as much as sending it in two separate transactions (approx. 1/5th of data). Am I right?. Regarding Point 5: A savings of 20% is not much when compared to the scaling requirements if Bitcoin were to be adapted by the mainstream..
    – S.O.S
    Jan 24 at 5:53
  • 4. I have mentioned one example in this answer with 5 outputs: bitcoin.stackexchange.com/a/101629 5. 20% here 20% there adds up to scaling the layer 1 of a decentralized peer to peer network. Mainstream doesn't need to do everything on layer 1.
    – Prayank
    Jan 24 at 6:11
  • So you get about 5x transactions for 2 x price = 250% increase in throughput
    – S.O.S
    Jan 24 at 6:29
  • 1
    @S.O.S No simple optimization is going to make a significant difference about what kind of applications on-chain settlement is good for. We may get a small constant factor scale improvements, sure, but ultimately, for some kinds of activity there will be space, and for others there won't (or there will only be until they become popular), and the network needs to deal with that. A global consensus system where everyone needs to observe what everyone does is just not a good fit for small payments, but it's great for auditable settlement of layers on top that can have much more throughput. Jan 24 at 6:47
  • 1
    @S.O.S Regarding your response to point 5, when discussing scaling requirements, most of the serious proposals have transactions take place off-chain (like with Lightning Network) and merely settled on the blockchain. While implementing Schnorr signatures will help, the primary goal of increasing transaction throughput is implementing more usable off-chain solutions.
    – ieatpizza
    Jan 24 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.