<blockquote>
  <p>I understand that a block is generated whenever a proof of work is
  submitted by a miner; this happens when the miner processes a
  transaction</p>
</blockquote>

<p>That's not correct. The miners doesn't submit a found block (proof-of-work) when he processes a transaction. He does when he found a block hash that was valid.</p>

<p>That can take a long time and in the time he looks for a good block, he will receive probably thousands of transactions.</p>

<p>He will verify those as they come in and put them in the block he is currently working on, all of them, one by one (until the limit is reached). When he then finds a valid block hash, he will submit the entire block consisting of all, or most of, the transactions he received.</p>

<p>So, to answer your questions, transactions do not necessarily get slower over time, on the condition that the upper limit of transactions in a block is high enough. If the limit is too low, there can arise a bottleneck for transactions trying to be verified.</p>

<p>FYI: You can see that all miners have all those transactions in their working block, but only one of them can submit the block. To prevent transactions from occurring twice, once a miner receives a new valid block from a fellow miner, he checks what transactions in his pool are also in that block. He will remove them from his pool and continues mining for the next block with the transactions from his pool that were not in the block of the fellow miner.</p>

CC BY-SA 3.0
2014-05-23T14:24:22.350Z
@Steven, Isn't it possible that in the near future we would have so much transactions that it takes over an hour merely to *process* the transactions?
Pacerier
CC BY-SA 3.0
2014-05-24T21:11:22.453Z
Well, hopefully, when the amount of transaction grows, the processing performance of the mining servers will as well. But you are right that Bitcoin is not very much made to scale to very large transaction sizes. Ripple does a much better job at that.
Steven Roose
CC BY-SA 3.0
2013-05-27T07:59:12.550Z
2013-05-27T07:59:12.550Z
Steven Roose
<p>Miners don't process transactions one at a time, they process blocks which contain many transactions. Currently each block can contain about 2000 transactions, if needed this figure might be increased.</p>

CC BY-SA 3.0
2014-05-23T14:19:36.073Z
How long does it take to process 2000 transactions?
Pacerier
CC BY-SA 3.0
2014-05-23T14:53:30.350Z
@Pacerier: The main work required per transaction is verifying the ECDSA signatures. I don't know the exact number but verifying 2,000 transactions should take a few seconds on a decent computer.
Meni Rosenfeld
CC BY-SA 3.0
2014-05-23T14:58:41.560Z
Hmm, this means that verifying transactions could be a bottleneck when bitcoin is broadly adopted in the future right?
Pacerier
CC BY-SA 3.0
2014-05-23T15:44:44.073Z
@Pacerier: It would be something to consider. But I'm not really worried about Bitcoin's scalability, as I explained in http://bitcoin.stackexchange.com/a/2800/575 (though that answer focused on data storage).
Meni Rosenfeld
CC BY-SA 3.0
2014-05-23T16:04:44.713Z
I consider that answer as irrelevant (despite its upvotes) because it focused on data storage which is a red herring. [Scalability](http://highscalability.com/blog/2007/8/16/scaling-secret-2-denormalizing-your-way-to-speed-and-profit.html) has much much more to do with "time" than "storage".
Pacerier
CC BY-SA 3.0
2014-05-25T08:51:45.893Z
@Pacerier: That's silly. Take every mention of "storage" and replace it with "ECDSA verification", the points will still be relevant (except for #2).
Meni Rosenfeld
CC BY-SA 3.0
2014-05-25T15:44:25.423Z
The answer as it is now made no mention of "ECDSA verification" but only talks about storage.
Pacerier
CC BY-SA 3.0
2014-05-29T11:26:38.497Z
@Pacerier: Why do I have to repeat myself? Replace "storage" with "ECDSA verification" and you're done. "The answer as it is now" is not what matters, what matters are the arguments within. The arguments apply equally well to ECDSA verification (1. Full nodes will have better hardware than consumer PCs. 3. Off-chain payments. 4. The amortized total cost per tx is low. 5. Hardware will improve with Moore's law.) I could have repeated the arguments here, but why should I when they're all already written?
Meni Rosenfeld
CC BY-SA 3.0
2014-05-29T15:05:34.590Z
You are missing the point. The question in that thread is *"Are there any studies into the size of the blockchain scaling over time?"*. Your answer in that thread **as it is** made no mention of "ECDSA verification" but only talks about storage. Perhaps you expect the reader to mind-replace "storage" with "ECDSA verification" while reading your answer. That's fine, except, your answer in that thread as it is made no mention of "ECDSA verification" but only talks about storage.
Pacerier
CC BY-SA 3.0
2014-05-29T20:56:04.717Z
@Pacerier: Which reader? The linked question was about storage, so my answer to that question was about storage. In the discussion here with you, I said there are multiple factors that will prevent the cost of ECDSA verification from becoming unbearable, and that these are the same factors as those mentioned in the linked answer, so I linked it instead of repeating the arguments. The only person I asked to make the leap from "storage" to "ECDSA verification" is you, and you repeatedly refused to do so. I have no idea what it is that we are arguing about, so it's probably best if we stop here.
Meni Rosenfeld
CC BY-SA 3.0
2014-05-29T20:57:57.460Z
@Pacerier: Perhaps the point you're missing is that the linked question was, in fact, about storage? If you read the question you'll notice this point.
Meni Rosenfeld
CC BY-SA 3.0
2014-05-30T02:31:35.653Z
I see we have talked past each other. I am in fact referring to the linked post, not this one. "readers" of course would mean the readers of the thread http://bitcoin.stackexchange.com/q/2798/1475 . Do read the question again carefully. [It is clear](https://www.google.com/search?q=do+what+i+mean+not+what+i+say) that it is asking about the scalability of the size of the blockchain, misassuming that storage is the only factor. But data storage is a red herring as the scalability of the size of the blockchain has much much more to do with "time" than "storage".
Pacerier
CC BY-SA 3.0
2014-05-30T08:42:13.383Z
@Pacerier: Maybe. I think that question was specific enough to warrant an answer to the question itself (which did make multiple references to storage), rather than speculating about different potential challenges for scalability.
Meni Rosenfeld
CC BY-SA 3.0
2013-05-27T05:26:03.267Z
2013-05-27T05:26:03.267Z
Meni Rosenfeld
<p>The number of blocks formed is 1 every 10 minutes. As the number of transactions increase, wouldn't the time taken for a transaction to confirm become slower?</p>

<p>I am asking this because this the number of people transacting increases but how fast blocks get generated is constant. Or am I going about it all wrong?</p>

<p>From what I read, I understand that a block is generated whenever a proof of work is submitted by a miner; this happens when the miner processes a transaction. So in addition to the transaction, he also gets some bitcoins which are once again added to the block chain.</p>

<transactions><blockchain>
Do transactions get slower over time?
Enthusiast
# Do transactions get slower over time?

(Asked by: username_0 on 2013-05-27)

The number of blocks formed is 1 every 10 minutes. As the number of transactions increase, wouldn't the time taken for a transaction to confirm become slower?

I am asking this because this the number of people transacting increases but how fast blocks get generated is constant. Or am I going about it all wrong?

From what I read, I understand that a block is generated whenever a proof of work is submitted by a miner; this happens when the miner processes a transaction. So in addition to the transaction, he also gets some bitcoins which are once again added to the block chain.

**Tags:** transactions, blockchain


---

## 2 answers

### Answer by username_1 on 2013-05-27. Score: 3 | Accepted answer

> I understand that a block is generated whenever a proof of work is
> submitted by a miner; this happens when the miner processes a
> transaction

That's not correct. The miners doesn't submit a found block (proof-of-work) when he processes a transaction. He does when he found a block hash that was valid.

That can take a long time and in the time he looks for a good block, he will receive probably thousands of transactions.

He will verify those as they come in and put them in the block he is currently working on, all of them, one by one (until the limit is reached). When he then finds a valid block hash, he will submit the entire block consisting of all, or most of, the transactions he received.

So, to answer your questions, transactions do not necessarily get slower over time, on the condition that the upper limit of transactions in a block is high enough. If the limit is too low, there can arise a bottleneck for transactions trying to be verified.

FYI: You can see that all miners have all those transactions in their working block, but only one of them can submit the block. To prevent transactions from occurring twice, once a miner receives a new valid block from a fellow miner, he checks what transactions in his pool are also in that block. He will remove them from his pool and continues mining for the next block with the transactions from his pool that were not in the block of the fellow miner.

> **Comments:**
> **username_2**: @username_1, Isn't it possible that in the near future we would have so much transactions that it takes over an hour merely to *process* the transactions?  
> **username_1**: Well, hopefully, when the amount of transaction grows, the processing performance of the mining servers will as well. But you are right that Bitcoin is not very much made to scale to very large transaction sizes. Ripple does a much better job at that.  

---

### Answer by username_3 on 2013-05-27. Score: 2

Miners don't process transactions one at a time, they process blocks which contain many transactions. Currently each block can contain about 2000 transactions, if needed this figure might be increased.

> **Comments:**
> **username_2**: How long does it take to process 2000 transactions?  
> **username_3**: @username_2: The main work required per transaction is verifying the ECDSA signatures. I don't know the exact number but verifying 2,000 transactions should take a few seconds on a decent computer.  
> **username_2**: Hmm, this means that verifying transactions could be a bottleneck when bitcoin is broadly adopted in the future right?  
> **username_3**: @username_2: It would be something to consider. But I'm not really worried about Bitcoin's scalability, as I explained in http://bitcoin.stackexchange.com/a/2800/575 (though that answer focused on data storage).  
> **username_2**: I consider that answer as irrelevant (despite its upvotes) because it focused on data storage which is a red herring. [Scalability](http://highscalability.com/blog/2007/8/16/scaling-secret-2-denormalizing-your-way-to-speed-and-profit.html) has much much more to do with "time" than "storage".  
> **username_3**: @username_2: That's silly. Take every mention of "storage" and replace it with "ECDSA verification", the points will still be relevant (except for #2).  
> **username_2**: The answer as it is now made no mention of "ECDSA verification" but only talks about storage.  
> **username_3**: @username_2: Why do I have to repeat myself? Replace "storage" with "ECDSA verification" and you're done. "The answer as it is now" is not what matters, what matters are the arguments within. The arguments apply equally well to ECDSA verification (1. Full nodes will have better hardware than consumer PCs. 3. Off-chain payments. 4. The amortized total cost per tx is low. 5. Hardware will improve with Moore's law.) I could have repeated the arguments here, but why should I when they're all already written?  
> **username_2**: You are missing the point. The question in that thread is *"Are there any studies into the size of the blockchain scaling over time?"*. Your answer in that thread **as it is** made no mention of "ECDSA verification" but only talks about storage. Perhaps you expect the reader to mind-replace "storage" with "ECDSA verification" while reading your answer. That's fine, except, your answer in that thread as it is made no mention of "ECDSA verification" but only talks about storage.  
> **username_3**: @username_2: Which reader? The linked question was about storage, so my answer to that question was about storage. In the discussion here with you, I said there are multiple factors that will prevent the cost of ECDSA verification from becoming unbearable, and that these are the same factors as those mentioned in the linked answer, so I linked it instead of repeating the arguments. The only person I asked to make the leap from "storage" to "ECDSA verification" is you, and you repeatedly refused to do so. I have no idea what it is that we are arguing about, so it's probably best if we stop here.  
> **username_3**: @username_2: Perhaps the point you're missing is that the linked question was, in fact, about storage? If you read the question you'll notice this point.  
> **username_2**: I see we have talked past each other. I am in fact referring to the linked post, not this one. "readers" of course would mean the readers of the thread http://bitcoin.stackexchange.com/q/2798/1475 . Do read the question again carefully. [It is clear](https://www.google.com/search?q=do+what+i+mean+not+what+i+say) that it is asking about the scalability of the size of the blockchain, misassuming that storage is the only factor. But data storage is a red herring as the scalability of the size of the blockchain has much much more to do with "time" than "storage".  
> **username_3**: @username_2: Maybe. I think that question was specific enough to warrant an answer to the question itself (which did make multiple references to storage), rather than speculating about different potential challenges for scalability.  

---

