<p>There are different concerns about the needs transactions and blocks have.</p>
<p>Transactions are created by wallets and other software, whenever they want to transact. We generally want a system that supports anyone creating transactions at any time, with as little coordination needed with other parties, and with as much volume/frequency as possible.</p>
<p>Blocks on the other hand exist to order otherwise valid transactions, so as to decide between multiple conflicting transactions. When two distinct and otherwise valid transactions that both spend the same money are published, we cannot permit both, but how do we decide which one? In Bitcoin, this is performed by miners, by finding and publishing blocks.</p>
<p>Here is the distinction: transactions don't need synchronization with the entire world. They're created by the sender, and may in general be ordered in whatever way compared to most other transactions people worldwide create. But this isn't true for blocks: blocks refer to the <em>the</em> previous block, and whenever a block doesn't do that, there is a fork that needs to be resolved.</p>
<p>Let's think for a minute what the requirements are for the rate of block creation. Clearly we'd want blocks to be as fast as possible. But how fast can they go? <strong>If blocks go too fast, the network will fail to converge</strong>. Imagine it takes 1 second for blocks to propagate from any one miner to the next one (because the speed of light, and the speed of computer processing is finite, there has to be such a limit - and the more spread out miners are (something we want to encourage), the higher it is), and there would be more than 1 block per second. This would generally mean that blocks would be found by miners before they've heard about the previous block. The result would be massive reorganizations, or possibly just every miner building their own chain, being unable the incorporate blocks from other miners fast enough.</p>
<p>So, we want blocks to generally be slower than the time it takes for them to propagate across the network. But even if they're just a bit slower, they create potentially huge unfairness: <strong>when the ratio of interblock/propagation is non-negligible, larger miners benefit</strong>. This is because miners can build faster on top of their own blocks than on top of other miners' blocks (simply because it takes time for them to know about it). This generally results in a slight incentive to centralize - either by merging pools, or at least to be geographically/topologically close to other miners. Miners who are further (in terms of delay) away from the majority of the hashrate will win less than proportional to their hashrate many blocks. This is highly undesirable if the intent is a decentralized system.</p>

CC BY-SA 4.0
2021-06-04T18:59:44.930Z
2021-06-04T18:59:44.930Z
Pieter Wuille
<p>Why do transactions have to be bundled in a block? Why not mine single transactions separately?</p>
<p>What is the advantage of bundling transactions in a block?</p>
<p>Also are there any blockchains/decentralized ledgers that mine transactions separately?</p>

<transactions><blockchain><block>
Why do transactions have to be bundled in a block? Why not mine single transactions separately?
YulePale
# Why do transactions have to be bundled in a block? Why not mine single transactions separately?

(Asked by: username_0 on 2021-05-21)

Why do transactions have to be bundled in a block? Why not mine single transactions separately?

What is the advantage of bundling transactions in a block?

Also are there any blockchains/decentralized ledgers that mine transactions separately?

**Tags:** transactions, blockchain, block


---

## 1 answers

### Answer by username_1 on 2021-06-04. Score: 2

There are different concerns about the needs transactions and blocks have.

Transactions are created by wallets and other software, whenever they want to transact. We generally want a system that supports anyone creating transactions at any time, with as little coordination needed with other parties, and with as much volume/frequency as possible.

Blocks on the other hand exist to order otherwise valid transactions, so as to decide between multiple conflicting transactions. When two distinct and otherwise valid transactions that both spend the same money are published, we cannot permit both, but how do we decide which one? In Bitcoin, this is performed by miners, by finding and publishing blocks.

Here is the distinction: transactions don't need synchronization with the entire world. They're created by the sender, and may in general be ordered in whatever way compared to most other transactions people worldwide create. But this isn't true for blocks: blocks refer to the *the* previous block, and whenever a block doesn't do that, there is a fork that needs to be resolved.

Let's think for a minute what the requirements are for the rate of block creation. Clearly we'd want blocks to be as fast as possible. But how fast can they go? **If blocks go too fast, the network will fail to converge**. Imagine it takes 1 second for blocks to propagate from any one miner to the next one (because the speed of light, and the speed of computer processing is finite, there has to be such a limit - and the more spread out miners are (something we want to encourage), the higher it is), and there would be more than 1 block per second. This would generally mean that blocks would be found by miners before they've heard about the previous block. The result would be massive reorganizations, or possibly just every miner building their own chain, being unable the incorporate blocks from other miners fast enough.

So, we want blocks to generally be slower than the time it takes for them to propagate across the network. But even if they're just a bit slower, they create potentially huge unfairness: **when the ratio of interblock/propagation is non-negligible, larger miners benefit**. This is because miners can build faster on top of their own blocks than on top of other miners' blocks (simply because it takes time for them to know about it). This generally results in a slight incentive to centralize - either by merging pools, or at least to be geographically/topologically close to other miners. Miners who are further (in terms of delay) away from the majority of the hashrate will win less than proportional to their hashrate many blocks. This is highly undesirable if the intent is a decentralized system.


---

