<p>This will not slow down the finding of a new block, because it is not necessary to include every new transaction in the next block. Miners can decide which and how many transactions to include and can only update the transaction set they mine on at arbitrary times. They could for example only update the data set every time they receive a new block, or every minute.</p>

<p><em><strong>below line is the answer to the previous edit of the question.</em></strong></p>

<hr>

<h2>The scenario you describe cannot come to pass.</h2>

<p>The Bitcoin network is self-regulating and automatically resets the difficulty every 2016 blocks to sustain an expected time of 10 minutes between blocks. The difficulty will be adjusted by up to factor four.</p>

<h2>Extremely fast verification cannot be sustained</h2>

<p>If a new block would be found every second in average (still magnitudes slower than your scenario calls for), the difficulty would be reset after 2016 seconds (33.6 minutes). The difficulty would quadruple, so in order to sustain that verification speed the networks hashing power would also have to increase four-fold in the same time! I am sure it is obvious, why the hashing power of the Bitcoin network will not quadruple every half hour for a significant frame of time.</p>

<h2>Between blocks transactions are collected and verified together in the block</h2>

<p>Every miner will collect all transactions transmitted to him, and whenever he tries to find a new block, he will try to include all unverified transactions together in that same block. </p>

<p>Once somebody finds a block, it will be broadcasted to the network and any receiving miner will check if it is valid and increases the length of his blockchain. If both is the case, he will accept it as a parent for the block he is trying to find. He will remove any transactions that have now been verified from his "unverified transactions" pool and will recommence to find a new block to verify the remaining transactions. Whenever more transactions are relayed to him, he will add them to his "unverified transactions" pool and will adjust the parameters of the block he is trying to find.</p>

<p><strong>Blocks cannot be changed after they have been found!</strong> However, there can be several blocks that compete with each other to be accepted into the blockchain next, but such races will eventually be decided when a successor is found for one of the competitors. These "mini-forks" happen every once in a while, but is very unlikely that competing blockchain ends find new blocks several times in the row at the same time. Eventually, one will definitely be first and all other competitors become invalid.</p>

<h2>Block size limit</h2>

<p>There is some concern that the current block size limit will become a problem, because it cannot handle a sufficient amount of transactions. Should this come to pass, however, it would not change the amount of time between blocks, but rather that every block would be filled with transactions and transactions that didn't make it into the block to be on a waiting list for a future block. There is currently an ongoing effort to adjust the blocksize limit in order to support a bigger number of transactions per time.</p>

CC BY-SA 3.0
2013-12-12T12:41:57.013Z
2013-12-12T13:09:15.077Z
2013-12-12T13:09:15.077Z
Murch
<p>Let's imagine, that the bitcoin network becomes very responsive in the future. So, that the time of exchange of transactions between peers is comparable with a time of evaluation of a bunch of hashes. The bad situation comes, when the transactions rate is so high, that even if someone finds the new block, it becomes invalid with a very high probability due to the new accepted transactions.</p>

<p>Can this possibly slow down the finding of the new blocks? May this even be a problem, or do I miss something?</p>

CC BY-SA 3.0
2013-12-12T07:27:38.330Z
Transaction could not be added to already mined block: once the block is found and broadcast, it is set in stone and can not include new transactions --- they all go to the new block. The number of transactions in the block and their rate do not affect block difficulty. Besides, what do you mean by "verification": [the check for tx validity](https://en.bitcoin.it/wiki/Transactions#Verification) or the time to "establish" transaction in blockchain by mining several blocks after it was included?
aland
CC BY-SA 3.0
2013-12-12T11:10:04.360Z
@aland No, I misused term "verification" - I mean the process of an appending of transactions to the current top block.
abyss.7
CC BY-SA 3.0
2013-12-12T12:44:37.430Z
Please feel free to use the *edit* link under your question in order to clarify your question.
Murch
CC BY-SA 3.0
2013-12-12T12:49:00.510Z
@Murch Done so. According to your current answer - I think, we don't clearly understand each other.
abyss.7
CC BY-SA 3.0
2013-12-12T12:56:13.703Z
Ah, I see. A block doesn't become invalid because a new transaction came to pass. A block can verify any amount of transactions between 0 and block size limit to be valid. So, the miners could just change the dataset they are mining on only every minute, without any problem.
Murch
<transactions><weaknesses>
What will happen, if transaction's rate becomes very high?
abyss.7
# What will happen, if transaction's rate becomes very high?

(Asked by: username_0 on 2013-12-12)

Let's imagine, that the bitcoin network becomes very responsive in the future. So, that the time of exchange of transactions between peers is comparable with a time of evaluation of a bunch of hashes. The bad situation comes, when the transactions rate is so high, that even if someone finds the new block, it becomes invalid with a very high probability due to the new accepted transactions.

Can this possibly slow down the finding of the new blocks? May this even be a problem, or do I miss something?

**Tags:** transactions, weaknesses

> **Comments:**
> **username_1**: Transaction could not be added to already mined block: once the block is found and broadcast, it is set in stone and can not include new transactions --- they all go to the new block. The number of transactions in the block and their rate do not affect block difficulty. Besides, what do you mean by "verification": [the check for tx validity](https://en.bitcoin.it/wiki/Transactions#Verification) or the time to "establish" transaction in blockchain by mining several blocks after it was included?  
> **username_0**: @username_1 No, I misused term "verification" - I mean the process of an appending of transactions to the current top block.  
> **username_2**: Please feel free to use the *edit* link under your question in order to clarify your question.  
> **username_0**: @username_2 Done so. According to your current answer - I think, we don't clearly understand each other.  
> **username_2**: Ah, I see. A block doesn't become invalid because a new transaction came to pass. A block can verify any amount of transactions between 0 and block size limit to be valid. So, the miners could just change the dataset they are mining on only every minute, without any problem.  

---

## 1 answers

### Answer by username_2 on 2013-12-12. Score: 0 | Accepted answer

This will not slow down the finding of a new block, because it is not necessary to include every new transaction in the next block. Miners can decide which and how many transactions to include and can only update the transaction set they mine on at arbitrary times. They could for example only update the data set every time they receive a new block, or every minute.

***below line is the answer to the previous edit of the question.***

---

## The scenario you describe cannot come to pass.

The Bitcoin network is self-regulating and automatically resets the difficulty every 2016 blocks to sustain an expected time of 10 minutes between blocks. The difficulty will be adjusted by up to factor four.

## Extremely fast verification cannot be sustained

If a new block would be found every second in average (still magnitudes slower than your scenario calls for), the difficulty would be reset after 2016 seconds (33.6 minutes). The difficulty would quadruple, so in order to sustain that verification speed the networks hashing power would also have to increase four-fold in the same time! I am sure it is obvious, why the hashing power of the Bitcoin network will not quadruple every half hour for a significant frame of time.

## Between blocks transactions are collected and verified together in the block

Every miner will collect all transactions transmitted to him, and whenever he tries to find a new block, he will try to include all unverified transactions together in that same block.

Once somebody finds a block, it will be broadcasted to the network and any receiving miner will check if it is valid and increases the length of his blockchain. If both is the case, he will accept it as a parent for the block he is trying to find. He will remove any transactions that have now been verified from his "unverified transactions" pool and will recommence to find a new block to verify the remaining transactions. Whenever more transactions are relayed to him, he will add them to his "unverified transactions" pool and will adjust the parameters of the block he is trying to find.

**Blocks cannot be changed after they have been found!** However, there can be several blocks that compete with each other to be accepted into the blockchain next, but such races will eventually be decided when a successor is found for one of the competitors. These "mini-forks" happen every once in a while, but is very unlikely that competing blockchain ends find new blocks several times in the row at the same time. Eventually, one will definitely be first and all other competitors become invalid.

## Block size limit

There is some concern that the current block size limit will become a problem, because it cannot handle a sufficient amount of transactions. Should this come to pass, however, it would not change the amount of time between blocks, but rather that every block would be filled with transactions and transactions that didn't make it into the block to be on a waiting list for a future block. There is currently an ongoing effort to adjust the blocksize limit in order to support a bigger number of transactions per time.


---

