<blockquote>
  <p>Is the estimate above correct, or am I missing something?</p>
</blockquote>

<p>Your estimations seem (more or less) fine.</p>

<blockquote>
  <p>If it's correct, what are the impacts of switching from a 1 MiB block size to 586 MiB?</p>
</blockquote>

<p>The two major ones I see are:</p>

<ul>
<li>large blocks make full nodes more difficult/expensive to operate (i.e. requires better specs and better upload/download speeds); thus bad for decentralization as not many people will be able to run a full node</li>
<li>the blocks will take longer to propagate through the network, thus it increases the chances of orphan blocks and double spends.</li>
</ul>

<p>For a more detailed list see <a href="https://en.bitcoin.it/wiki/Block_size_limit_controversy#Arguments_in_opposition_to_increasing_the_blocksize" rel="nofollow">here</a>.</p>

<p>Note, that these concerns/drawbacks for an increased block size were raised for a 4, 8 or 32MBs increase... a 586MB increase would be way too excessive. And if you keep the parameters similar to bitcoin you would have the same issues in the side chain.</p>

CC BY-SA 3.0
2016-02-02T19:24:10.123Z
So, basically it would be better to change the other parameters as well in order to improve this chain performance? Considering `32 MiB` as block size limit, decreasing the block mining average time to `30 s`, I would be able to process `~2200 tps`. But this could impact the security of my chain, right?
Henrique Barcelos
CC BY-SA 3.0
2016-02-02T19:37:04.497Z
If you reduce the block time to 30s, 32MiB blocks would never manage to properly propagate through the network before the next block is due. This is a tough problem and I don't know any research on the topic to give you pointers. However, I would advice you to study (experiment with) some of the altcoins and their capabilities. For example Zetacoin has a 30s block time.  A list of SHA256 altcoins including their block times can be found [here](http://www.coinwarz.com/miningprofitability/sha-256).
karask
CC BY-SA 3.0
2016-02-02T20:01:30.400Z
@HenriqueBarcelos The reason Satoshi came up with 10 minutes is because of this propagation delay: if 10% of the 10 minutes is spent propagating the block, then that means ~10% of the mining capacity is wasted and it gives an significant unfair advantage to miners that receive the block first compared to last. So if anything, you would want to _increase_ the block time. Although even that doesn't help that much and will quickly make settlements take hours or days.
Jannes
CC BY-SA 3.0
2016-02-02T19:19:00.603Z
2016-02-02T19:58:28.280Z
2016-02-02T19:58:28.280Z
karask
<p>This is what the current block size debate is about and has been for more than a year now. I'll try not to repeat all of that here.</p>

<p>Your numbers seem roughly correct. Whether 600MB blocks are possible in your side chain depends on how your side chain would work. If you get rid of the Proof-of-Work security and it's all data center grade hardware and bandwidth between parties that trust each other to some degree, then there is no problem. It would probably make sense to lower the block time in that case too, for example 60MB every 1 minute. In fact, blocks probably wouldn't make sense at all anymore, why not just an append-only database of single transactions with some checksums for security?</p>

<p>Sidechains can trade some properties to gain other properties, which could make perfect sense. In the above example you trade decentralized trustless for high efficiency but trusted (users need to trust you and some other parties involved, and the government(s), and... ).</p>

<p>Bitcoin itself has as primary property that it's decentralized. Uncensorable, low barrier to entry for miners and for full nodes, peer2peer and all those good things are very much related and intertwined with that primary property. 600MB per block would completely destroy all that.</p>

<p>That is not to say there aren't many way cooler tricks that Bitcoin has up its sleeve. SegWit is currently being rolled out and will make making blocks smaller for certain nodes and better prunable, while making the effective blocksize around 1.75MB. As well as opening up paths to many more cool efficiency improvements like making multi-sig transactions significantly smaller.</p>

<p>An even bigger step will be made with two-way payment channels and networks built using those. Lightning Network is most well known name in this space. The idea is to cache hundreds and thousands (or orders more) of small transactions over weeks or months without putting a single one in a block. Only at the very beginning when opening such a channel and at the end when closing the channel will a transaction actually end up in a block. Organising these channels in a peer2peer network allows anyone to send and forward money through multiple hops, thus allowing everyone to pay anyone else without having to trust a single node and even having true instant and trustless payments (no need to wait for block confirmations).</p>

<p>Scaling is seldom simply turning one dial merely making an existing thing larger. Clever solutions have a much bigger impact while offering better trade offs.</p>

<p>Excuse me for not answering your exact question of listing all impacts of switching to a large block size. They are numerous and each can lead to its own endless bike shedding and handwaving discussion. The most important is that once a block has been mined it needs to propagate ASAP around the world or there's a risk that another miner will find another block where one of those blocks will be "orphaned" (wasted). More orphaned blocks leads to more centralized mining, as bigger miners have a bigger chance to win such an orphan race. "ASAP" in the case of a 10 minute interval is therefore on the order of seconds. Now that doesn't mean that the whole 600MB would need to be transferred to all nodes around the world within a few seconds, but it's still quite a challenge.</p>

<p>Currently 2MB is deemed the maximum safe blocksize, which SegWit pretty much covers. After further enhancements and efficiency improvements another doubling is likely possible in one or two years.</p>

CC BY-SA 3.0
2016-02-03T13:30:08.103Z
thank your for your comprehensive response. I've been catching up with bitcoin news, which I've been distant for over 1 year. This is more a conceptual question: "dropping the cryptographic proof-of-work mechanism does not make the solution a **non-blockchain** one?"
Henrique Barcelos
CC BY-SA 3.0
2016-02-03T14:50:16.890Z
@HenriqueBarcelos yeah it sort of does. The concept of a blockchain is meant to amplify the effectiveness of PoW: by linking the blocks together changing one old block requires new PoW for not just one block, but for ALL blocks since. Without PoW you might still want to chain transactions such that changing on transactions would require rewriting all checksum for newer transactions (data integrity), but there's not really a need anymore for putting transactions in blocks. It's not really a blockchain anymore, more like a linked-list with hash pointers instead of memory pointers.
Jannes
CC BY-SA 3.0
2016-02-02T19:54:38.080Z
2016-02-02T19:54:38.080Z
Jannes
<p>It's widely known that Bitcoin has a limit of <code>1 MB</code> per block.</p>

<p>However, the average block size is currently about <code>0.6 MB</code>:</p>

<p><img src="https://i.sstatic.net/jbH9G.png" alt="Bitcoin average block size"></p>

<p>(<a href="https://blockchain.info/charts/avg-block-size" rel="nofollow noreferrer">original data</a>)</p>

<p>According to this <a href="https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101" rel="nofollow noreferrer">thread</a>, Bitcoin transactions has an average size of <code>512 B</code>. For the sake of simplicity, I'm not considering the <code>80 B</code> of block header.</p>

<p>Given that, it's possible to fit about <code>1200</code> transactions in a block today. Considering that a new block will be mined every 10 minutes, the current capacity of the network is <code>2 tps</code>:</p>

<pre><code>1200 transactions/block / 10 min/block / 60 sec/min = 2 transactions/s
</code></pre>

<p>This seems like a very low throughput, specially when compared to Paypal's average rate of <code>~115tps</code> and Visa's average rate of <code>~2000 tps</code>.</p>

<p>Now imagine that I want to build a side chain that can handle as much traffic as Visa network. I want to mantain most of the parameters of the Bitcoin's blockchain (10 min/block, ~512 B/transaction), but being able to process <code>2000 tps</code>.</p>

<p>In this case, my block size would be the following:</p>

<pre><code>2000 transaction/s * 512 B/transaction * 60 s/min * 10 min/block = 586 MB/block
</code></pre>

<p>Is the estimate above correct, or am I missing something?</p>

<p>If it's correct, what are the impacts of switching from a <code>1 MB</code> block size to <code>586 MB</code>?</p>

<block-size-increase><blocksize>
Block size depending on transaction count
Henrique Barcelos
# Block size depending on transaction count

(Asked by: username_0 on 2016-02-02)

It's widely known that Bitcoin has a limit of `1 MB` per block.

However, the average block size is currently about `0.6 MB`:

![Bitcoin average block size](https://i.sstatic.net/jbH9G.png)

([original data](https://blockchain.info/charts/avg-block-size))

According to this [thread](https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101), Bitcoin transactions has an average size of `512 B`. For the sake of simplicity, I'm not considering the `80 B` of block header.

Given that, it's possible to fit about `1200` transactions in a block today. Considering that a new block will be mined every 10 minutes, the current capacity of the network is `2 tps`:

```
1200 transactions/block / 10 min/block / 60 sec/min = 2 transactions/s

```

This seems like a very low throughput, specially when compared to Paypal's average rate of `~115tps` and Visa's average rate of `~2000 tps`.

Now imagine that I want to build a side chain that can handle as much traffic as Visa network. I want to mantain most of the parameters of the Bitcoin's blockchain (10 min/block, ~512 B/transaction), but being able to process `2000 tps`.

In this case, my block size would be the following:

```
2000 transaction/s * 512 B/transaction * 60 s/min * 10 min/block = 586 MB/block

```

Is the estimate above correct, or am I missing something?

If it's correct, what are the impacts of switching from a `1 MB` block size to `586 MB`?

**Tags:** block-size-increase, blocksize


---

## 2 answers

### Answer by username_1 on 2016-02-02. Score: 1

> Is the estimate above correct, or am I missing something?

Your estimations seem (more or less) fine.

> If it's correct, what are the impacts of switching from a 1 MiB block size to 586 MiB?

The two major ones I see are:

* large blocks make full nodes more difficult/expensive to operate (i.e. requires better specs and better upload/download speeds); thus bad for decentralization as not many people will be able to run a full node
* the blocks will take longer to propagate through the network, thus it increases the chances of orphan blocks and double spends.

For a more detailed list see [here](https://en.bitcoin.it/wiki/Block_size_limit_controversy#Arguments_in_opposition_to_increasing_the_blocksize).

Note, that these concerns/drawbacks for an increased block size were raised for a 4, 8 or 32MBs increase... a 586MB increase would be way too excessive. And if you keep the parameters similar to bitcoin you would have the same issues in the side chain.

> **Comments:**
> **username_0**: So, basically it would be better to change the other parameters as well in order to improve this chain performance? Considering `32 MiB` as block size limit, decreasing the block mining average time to `30 s`, I would be able to process `~2200 tps`. But this could impact the security of my chain, right?  
> **username_1**: If you reduce the block time to 30s, 32MiB blocks would never manage to properly propagate through the network before the next block is due. This is a tough problem and I don't know any research on the topic to give you pointers. However, I would advice you to study (experiment with) some of the altcoins and their capabilities. For example Zetacoin has a 30s block time.  A list of SHA256 altcoins including their block times can be found [here](http://www.coinwarz.com/miningprofitability/sha-256).  
> **username_2**: @username_0 The reason Satoshi came up with 10 minutes is because of this propagation delay: if 10% of the 10 minutes is spent propagating the block, then that means ~10% of the mining capacity is wasted and it gives an significant unfair advantage to miners that receive the block first compared to last. So if anything, you would want to _increase_ the block time. Although even that doesn't help that much and will quickly make settlements take hours or days.  

---

### Answer by username_2 on 2016-02-02. Score: 1

This is what the current block size debate is about and has been for more than a year now. I'll try not to repeat all of that here.

Your numbers seem roughly correct. Whether 600MB blocks are possible in your side chain depends on how your side chain would work. If you get rid of the Proof-of-Work security and it's all data center grade hardware and bandwidth between parties that trust each other to some degree, then there is no problem. It would probably make sense to lower the block time in that case too, for example 60MB every 1 minute. In fact, blocks probably wouldn't make sense at all anymore, why not just an append-only database of single transactions with some checksums for security?

Sidechains can trade some properties to gain other properties, which could make perfect sense. In the above example you trade decentralized trustless for high efficiency but trusted (users need to trust you and some other parties involved, and the government(s), and... ).

Bitcoin itself has as primary property that it's decentralized. Uncensorable, low barrier to entry for miners and for full nodes, peer2peer and all those good things are very much related and intertwined with that primary property. 600MB per block would completely destroy all that.

That is not to say there aren't many way cooler tricks that Bitcoin has up its sleeve. SegWit is currently being rolled out and will make making blocks smaller for certain nodes and better prunable, while making the effective blocksize around 1.75MB. As well as opening up paths to many more cool efficiency improvements like making multi-sig transactions significantly smaller.

An even bigger step will be made with two-way payment channels and networks built using those. Lightning Network is most well known name in this space. The idea is to cache hundreds and thousands (or orders more) of small transactions over weeks or months without putting a single one in a block. Only at the very beginning when opening such a channel and at the end when closing the channel will a transaction actually end up in a block. Organising these channels in a peer2peer network allows anyone to send and forward money through multiple hops, thus allowing everyone to pay anyone else without having to trust a single node and even having true instant and trustless payments (no need to wait for block confirmations).

Scaling is seldom simply turning one dial merely making an existing thing larger. Clever solutions have a much bigger impact while offering better trade offs.

Excuse me for not answering your exact question of listing all impacts of switching to a large block size. They are numerous and each can lead to its own endless bike shedding and handwaving discussion. The most important is that once a block has been mined it needs to propagate ASAP around the world or there's a risk that another miner will find another block where one of those blocks will be "orphaned" (wasted). More orphaned blocks leads to more centralized mining, as bigger miners have a bigger chance to win such an orphan race. "ASAP" in the case of a 10 minute interval is therefore on the order of seconds. Now that doesn't mean that the whole 600MB would need to be transferred to all nodes around the world within a few seconds, but it's still quite a challenge.

Currently 2MB is deemed the maximum safe blocksize, which SegWit pretty much covers. After further enhancements and efficiency improvements another doubling is likely possible in one or two years.

> **Comments:**
> **username_0**: thank your for your comprehensive response. I've been catching up with bitcoin news, which I've been distant for over 1 year. This is more a conceptual question: "dropping the cryptographic proof-of-work mechanism does not make the solution a **non-blockchain** one?"  
> **username_2**: @username_0 yeah it sort of does. The concept of a blockchain is meant to amplify the effectiveness of PoW: by linking the blocks together changing one old block requires new PoW for not just one block, but for ALL blocks since. Without PoW you might still want to chain transactions such that changing on transactions would require rewriting all checksum for newer transactions (data integrity), but there's not really a need anymore for putting transactions in blocks. It's not really a blockchain anymore, more like a linked-list with hash pointers instead of memory pointers.  

---

