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

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

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





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/

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.



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/

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/

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

78451: <p><a href="https://en.wikipedia.org/wiki/Bitcoin_Unlimited" rel="nofollow noreferrer">Wikipedia</a> explains the rationale behind the 1 MB block size limit as follows:</p>
<blockquote>
<p>The one megabyte block size limit was added in 2010 by Satoshi
Nakamoto as a temporary anti-DoS measure</p>
</blockquote>
<p>A <a href="https://bitcoin.stackexchange.com/questions/57120/why-does-a-larger-block-size-infer-a-bigger-attack-vector/78978#78978">SE post</a> expounds on this:</p>
<blockquote>
<p>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</p>
</blockquote>
<p>What I don't understand is:</p>
<p><strong>1)</strong> 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?</p>
<p><strong>2)</strong> 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?</p>
<p>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.</p>
<p>Thanks</p>
 -1: <p>This does not address your main question but response to some of the wrong assumptions in the question:</p>
<ol>
<li>Bitcoin blocksize is not 1 MB: <a href="https://bitcoin.stackexchange.com/questions/98810/whats-the-blocksize-limit-after-segwit-and-how-do-legacy-nodes-deal-with-segwit/">What&#39;s the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?</a></li>
</ol>
<p><a href="https://i.stack.imgur.com/bWFh2.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/bWFh2.png" alt="Blocksize" /></a></p>
<ol start="2">
<li>
<blockquote>
<p>A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.</p>
</blockquote>
</li>
</ol>
<p><a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel="nofollow noreferrer">https://bitcoincore.org/en/2016/01/26/segwit-benefits/</a></p>
<ol start="3">
<li>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.</li>
</ol>
<p><a href="https://i.stack.imgur.com/D8T3H.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/D8T3H.png" alt="blocksize-decentralizations" /></a></p>
<ol start="4">
<li><p>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: <a href="https://bitcoin.stackexchange.com/a/100829/">https://bitcoin.stackexchange.com/a/100829/</a></p>
</li>
<li><p>Bitcoin scaling works in layers: <a href="https://bitcoinkpis.com/layer2" rel="nofollow noreferrer">https://bitcoinkpis.com/layer2</a> and this does not mean on-chain development has stopped or will not focus on scaling. Example:</p>
</li>
</ol>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href="https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/" rel="nofollow noreferrer">https://web.archive.org/web/20201214095704/https://www.advancingbitcoin.com/blog/evolution-signature-size-bitcoin/</a></p>
 41313: <p>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.</p>
<p>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 &quot;spam&quot; transaction you want to send.</p>
