<p>After reading the existing answers, and your comments on this, I believe what you're looking for is this.</p>

<p>Your question is based on a misunderstanding. The figure "Bitcoin can process 7 transactions per second" is not a burst rate. It is talking about the long-term network-wide average, and results from the fact that (a) blocks are limited in size and (b) the block production rate is limited.</p>

<p>Individual Bitcoin node implementations can process far more transactions per second than that, but they necessarily need to be many times faster than the rate at which the whole network operates.</p>

<p>When a new block is created, nodes in the network need to be able to process it quickly, in order to not delay how long it takes before other miners can start building on top of that block. Due to the inherent variance in block production, the next block has a small but significant probability of being found just seconds later. If network nodes can't verify the previous block within that time, they are disadvantaged. However, the miner who created the block himself has no such penalty (he already knows his own block is valid). Generally these delays in processing tend to benefit the larger and well-connected miners proportionally more than smaller ones - an effect that is very detrimental to decentralization of the network, so to be avoided at all cost. For that reason, the time between blocks must be many times larger than the time it takes to verify the transactions in it.</p>

CC BY-SA 4.0
2018-06-07T17:32:02.543Z
2018-06-07T18:01:38.910Z
2018-06-07T18:01:38.910Z
Pieter Wuille
<p>I was in the same situation you are a month ago but reading around carefully and giving time to things seeping in has actually helped me understand a lot.</p>
<p>I'll try and keep my answer completely non-technical, just for better understanding purposes.</p>
<p>For a technical explanation, Andrew gave a good overview, Rich gave the exact calculations behind the scenes and Pieter explained where you might be misunderstanding the transaction's process.</p>
<blockquote>
<p>Q1. I recently read (Scalability link) that bitcoin can do 3.3 to 7 transactions per second</p>
<blockquote>
<p>A. The metric used to calculate the transaction speed is incorrect. What we can actually calculate is how many transactions are appearing in the blockchain every 10 mins, as the acceptance of each block to the blockchain takes approximately that much time. Hence, with the size of the block being 1MB and it getting added to the chain every 10 mins, currently, we can store only a limited amount (whatever 1MB can fit) of transactions every 10 mins.</p>
<blockquote>
<p>How can this improve?</p>
<blockquote>
<p>There are newer technologies, like <a href="https://en.wikipedia.org/wiki/SegWit" rel="nofollow noreferrer" title="Read more about SegWit">SegWit</a>, being added to the Bitcoin's core, which helps in breaking the data into useful information (transactions) and redundant information (signatures). There are also new hashing algorithms, like <a href="https://en.wikipedia.org/wiki/Schnorr_signature" rel="nofollow noreferrer" title="Read more about Schnorr">Schnorr</a>, which are under speculation to reduce the data usage of the block per transaction. There is also a second-layer on top of the Bitcoin blockchain, that handles transactions (even micro-transactions) separately altogether, a good example of which would be the <a href="https://en.wikipedia.org/wiki/Lightning_Network" rel="nofollow noreferrer" title="Read more about Lightning Network">Lightning Network</a>.</p>
</blockquote>
</blockquote>
</blockquote>
<p>Q2. I am curious, what is the bottleneck for the transaction rate?</p>
<blockquote>
<p>A. People have correctly &quot;chimed in&quot; while saying that the bottleneck is the block size.</p>
<blockquote>
<p>Going a little deeper...</p>
<blockquote>
<p>For once there was a proposition of increasing the block size to eradicate the scaling problem <a href="https://en.wikipedia.org/wiki/SegWit2x" rel="nofollow noreferrer" title="Read more about the planned hard fork">2MB block size in SegWit2x</a>. You can find 'Bitcoin scalability problem' as a linked article in the 'see also' section on Wikipedia.</p>
</blockquote>
</blockquote>
</blockquote>
<p>Q3. Is it verifying the signatures? or maybe it's verifying sufficient funds?</p>
<blockquote>
<p>A. No, verification of the signature occurs almost instantly and the sufficient funds part is handled by the client (maybe some wallet software or some exchange) you're using.</p>
<blockquote>
<p>Still not convinced that it happens locally?</p>
<blockquote>
<p>Here are a few references to back my claims: <a href="https://bitcoin.stackexchange.com/questions/40824/how-to-calculate-signature-generation-signature-verification-transaction-verif">How to calculate signature generation, signature verification, transaction verification speed?</a> , <a href="https://bitcoin.stackexchange.com/questions/7363/how-much-time-it-takes-to-verify-a-bitcoin-signature-in-the-satoshi-client">How much time it takes to verify a Bitcoin signature in the Satoshi client?</a> , <a href="https://bitcoin.stackexchange.com/questions/9248/how-do-nodes-verify-bitcoin-transactions">How do nodes verify Bitcoin Transactions?</a> , <a href="https://bitcoin.stackexchange.com/questions/23363/verification-of-transaction-once-trasaction-is-broadcasted/23366#23366">Verification of transaction once trasaction is broadcasted</a></p>
</blockquote>
</blockquote>
</blockquote>
<p>Q4. My question is, what process is hogging the resources limiting the number of transactions per second?</p>
<blockquote>
<p>A. The process called 'Proof of Work' is limiting the number of transactions per second (actually per 10 mins to be more precise)</p>
<blockquote>
<p>If u still don't trust what I say...</p>
<blockquote>
<p><a href="https://en.bitcoin.it/wiki/Proof_of_work" rel="nofollow noreferrer" title="Read more about the Proof of Work">Please go through this wiki - Proof of Work (PoW)</a> as it'll briefly introduce you to PoW - <code>&quot;The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes&quot;</code>.  You can even read through other pages in that wiki for better understanding.</p>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<p>I hope this clarifies each and every question of yours.</p>

CC BY-SA 4.0
2018-06-08T09:57:29.560Z
2018-06-08T09:57:29.560Z
2020-06-16T11:10:03.350Z
Junaid Shaikh
<p>The bottleneck is the number of transactions that can fit in a block, and the frequency of blocks.</p>

<p>You can create an infinite number of transactions per second and broadcast them to the network, but that is irrelevant because those transactions are not considered final. They are considered reversible and insecure.</p>

<p>For a transaction to be considered final and secure, it must be included in a block. So the transaction rate that is often cited as being 3 to 7 transactions per second is limited by the number of transactions that can fit in a block and the frequency of blocks as that metric only considers transactions that are final and secure.</p>

<hr>

<p>The actual number of transactions per second that bitcoind can verify is somewhere in the thousands of transactions per second. Transactions can be verified very quickly and the limiting factor becomes hardware. Furthermore, it depends on your hardware; a slow CPU could be the bottleneck for some devices, while a slow hard drive may be the bottleneck for others.</p>

<p>However the number of transactions that bitcoind can verify is irrelevant as those transactions are not confirmed and thus not final, which is what really matters. The rate at which transactions become confirmed and final is limited by the block size as explained earlier.</p>

CC BY-SA 4.0
2018-06-01T23:58:16.160Z
Thank you for your answer, however, I am more interested in the technical details of the bottleneck, I have updated my question with some examples of what I believe the bottle neck might be
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-02T00:02:02.737Z
No, there is a hardcoded limit to the size of blocks, and blocks above that size are simply rejected by nodes that validate them. The reasons for why that limit exist are already answered in several other questions.
Pieter Wuille
CC BY-SA 4.0
2018-06-05T04:31:22.943Z
ok, I understand that, but that doesn't tell me why bitcoind doesn't process more than 7 transactions a second...
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-05T04:36:44.833Z
No more than a certain number of transactions can fit in a block, which are found, on average, every 10 minutes. Since "processing a transaction" means including it in a block, the bottleneck is in the number of transactions that can be included in a block and the amount of time required to produce a block. When you take the maximum number of transactions that can fit in a block and divide that by the average time to find a block, then you get a number that is around 7 transactions per second.
Ava Chow
CC BY-SA 4.0
2018-06-05T11:18:27.843Z
So what you are telling me, is that if 10 transactions get broadcast in one second, then bitcoind can include them in the next block within a second? What if a 100 transactions were broadcast in one second?
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-05T13:08:50.333Z
@JeffreyL.Roberts blocks get mined every 10 minutes. A typical 1-input-2-outputs transaction takes around 250 bytes. Each block has 1MB room for transactions so it can take around 4000. 4000/10minutes = 6.67/sec
Mike D
CC BY-SA 4.0
2018-06-05T14:30:01.823Z
hrmmm, my last comment, my apologies, but to me, that is the average amount of transactions per second, not the transactions per second rate
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-05T23:24:42.780Z
The transactions per second rate that is commonly cited is exactly that: the average amount of transactions per second.
Ava Chow
CC BY-SA 4.0
2018-06-05T23:31:36.820Z
So what is the max? Im guessing hardware plays a role in that, but there should be a range, the range ive found is 3.3 to 7 transactions per second, now back to my question, what is the limiting factor or resource hog that limits bitcoind to 7 transactions per second?
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-06T05:32:14.353Z
As has been stated multiple times in this answer, the limiting factor is the number of transactions that can fit in a block. This is completely unrelated to bitcoind, it is related to Bitcoin's consensus rules. bitcoind itself can verify many thousands of transactions per second with the limiting factor being your hardware. But for the network as a whole, the limit is in the consensus rules.
Ava Chow
CC BY-SA 4.0
2018-06-06T05:32:41.167Z
What exactly do you not understand about the answer? You keep asking the same question over and over again. Please clarify what you don't understand about the answer.
Ava Chow
CC BY-SA 4.0
2018-06-07T03:15:14.563Z
I think something is getting lost in translation here, you keep offering me the average number of transactions per second, and I am looking for the limiting factor of the actual number of transactions per second...
Jeffrey L. Roberts
CC BY-SA 4.0
2018-06-07T09:45:27.300Z
The  number that you have cited (which I assume is what you believe is the "actual number of transactions per second") is actually the average number of transactions per second. The actual number of transactions per second that bitcoind can handle is very large, on the order of thousands of transactions per second and varies highly due to hardware.
Ava Chow
CC BY-SA 4.0
2018-06-07T10:29:10.697Z
I know comments are not for thank-you but, I wanted you to know I upvoted your answer anyway.
Willtech
CC BY-SA 4.0
2018-06-01T22:09:06.993Z
2018-06-07T09:48:49.620Z
2018-06-07T09:48:49.620Z
Ava Chow
<blockquote>
  <p>I am curious, what is the bottle neck for the transaction rate?</p>
</blockquote>

<p>If I broadcast several thousand <strong>valid</strong> transactions per second onto the Bitcoin network;</p>

<ol>
<li><p>Those transactions will be validated when received by each node and enter each node's individual mempool until the individual mempool resources are exhausted, in which case each node has its own rules about how to handle additional new transactions. Some nodes with slower hardware may not keep up but that is irrelevant as the mempool is not ever in consensus.</p></li>
<li><p>A miner draws a number of transactions from their own mempool using any selection criteria that they wish (transactions in mempool have already been validated), not more than the maximum block size in block weight per consensus rules, constructs a proposed block and attempts to make it valid by incrementing nonce (simplified). This process of solving a block takes on average ten minutes and is regulated to maintain that average block time per consensus rules. Ten minutes is currently considered the optimum for security and reliability.</p></li>
<li><p>Since there is a fixed maximum block size in block weight AND a regulated average interval, this is the limiting factor for transaction bandwidth rate since a non-infinite number of transactions may be compiled into a valid block and will take an average of ten minutes to solve. This can be shown as:
(average number of transactions that will fit in a block in block weight)/average block time in seconds = approximately 7 transactions per second maximum, however, this ideal figure would be seldom possible to maintain using real data.</p></li>
</ol>

<p>Note that I have marked valid at the top of these statements in bold.</p>

<blockquote>
  <p>My question is, what process is hogging the resources limiting the amount of transactions per second... </p>
</blockquote>

<p>It is not a process, it is the application of consensus rules.</p>

CC BY-SA 4.0
2018-06-07T10:40:28.983Z
2018-06-07T10:53:02.733Z
2018-06-07T10:53:02.733Z
Willtech
<blockquote>
  <p>I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...</p>
</blockquote>

<p>A block can hold no more than 1 MB of transactions. This sets the network's transaction speed limit.</p>

<p>A block is generated once every 10 minutes on average. We can calculate the block chain's write speed with:</p>

<p>w = s * g</p>

<p>where <em>w</em> is write speed MB/hour, <em>s</em> is block size limit in megabytes (1 MB/block), and <em>g</em> is the rate of block generation per hour (6 blocks/hour).</p>

<p>Plugging in the value yields:</p>

<pre><code>w = 1 MB/block * 6 blocks/hour = 6 MB/hour
</code></pre>

<p>Converting to bytes/second, that's:</p>

<pre><code>6 MB/hour * (1 hour/60 minutes) * (1 minute/60 seconds) * (1,000,000 bytes/1 MB) = 1,700 bytes/second
</code></pre>

<p>In other words, think of the blockchain as a hard drive. We can write to this hard drive at a rate of 1,700 bytes/second.</p>

<p>Even if we develop faster computers, we can't write data faster than this because the network rejects any block larger than 1 MB. We need to make some allowances for SegWit, but for now, let's keep things simple.</p>

<p>A one-input, one-output Alice-Pays-Bob transaction requires ~ 200 bytes. This is the absolute best case. We can, therefore, obtain an upper bound on the transaction rate using:</p>

<pre><code>v = w / z
</code></pre>

<p>where <em>v</em> is the maximum transaction volume, <em>w</em> is the write speed calculated above (1,700 bytes/second), and <em>z</em> is the average size of a transaction (200 bytes/transaction).</p>

<p>Plugging in the numbers:</p>

<pre><code>v = 1,700 bytes/second * (1 transaction / 200 bytes) = 8 transactions/second
</code></pre>

<blockquote>
  <p>The answer to my question should be something like verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.</p>
</blockquote>

<p>The network might appear to have a limit based on hardware or validation, but it does not. At least not directly.</p>

<p>As to why we should limit the block chain's write speed in the first place, the answer has to do with network security. Increasing write speed means:</p>

<ol>
<li>data flows through the network at a higher rate;</li>
<li>more data must be stored by every node;</li>
<li>more transactions must be validated by every node.</li>
</ol>

<p>Every node sends and receives every block, and every block must be stored. Increasing the blockchain write speed means that every node pays the price. Some won't be able to keep up, regardless of write speed.</p>

<p>Transaction validation is a resource hog due to signature validation and UTXO set manipulation. Storage space and bandwidth are also considerations, but less resource-intensive than validation.</p>

<p>Now, if you're asking why we have a 1 MB limit given XXX computer has such-and-such technical capabilities, that's the realm of the Never Ending Debate. Calculations have been done and simulations have been reported. They are not hard to find. They are, however, hard to believe given their wildly-differing claims and underlying assumptions.</p>

<p>The best thing I can recommend is to download a copy of Bitcoin Core 0.16.0 and try syncing a node from scratch. Report back when you're done.</p>

<p>The write speed limit we see is a compromise between inclusivity (more people using bitcoin) and security (difficulty of double-spending attacks). The limit may not have been set correctly, but figuring out where (or even how) to set it is exceedingly difficult. Not because of lack of ideas, but because of too many and lack of widely-accepted selection criteria.</p>

CC BY-SA 4.0
2018-06-07T15:46:12.960Z
2018-06-08T13:33:40.850Z
2018-06-08T13:33:40.850Z
Rich Apodaca
<p>I recently read (<a href="https://en.wikipedia.org/wiki/Bitcoin_scalability_problem" rel="noreferrer">Scalability link</a>) that bitcoin can do 3.3 to 7 transactions per second...</p>

<p>I am curious, what is the bottle neck for the transaction rate?</p>

<p>Is it verifying the signatures? or maybe it's verifying sufficient funds?</p>

<p>My question is, what process is hogging the resources limiting the amount of transactions per second... </p>

<p>EDIT:</p>

<p>I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...</p>

<p>The answer to my question should be something like, verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds. </p>

<bitcoin-core><bitcoind>
What is the transaction rate bottle neck?
Jeffrey L. Roberts
# What is the transaction rate bottle neck?

(Asked by: username_0 on 2018-06-01)

I recently read ([Scalability link](https://en.wikipedia.org/wiki/Bitcoin_scalability_problem)) that bitcoin can do 3.3 to 7 transactions per second...

I am curious, what is the bottle neck for the transaction rate?

Is it verifying the signatures? or maybe it's verifying sufficient funds?

My question is, what process is hogging the resources limiting the amount of transactions per second...

EDIT:

I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...

The answer to my question should be something like, verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.

**Tags:** bitcoin-core, bitcoind


---

## 5 answers

### Answer by username_6 on 2018-06-07. Score: 6 | Accepted answer

> I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...

A block can hold no more than 1 MB of transactions. This sets the network's transaction speed limit.

A block is generated once every 10 minutes on average. We can calculate the block chain's write speed with:

w = s \* g

where *w* is write speed MB/hour, *s* is block size limit in megabytes (1 MB/block), and *g* is the rate of block generation per hour (6 blocks/hour).

Plugging in the value yields:

```
w = 1 MB/block * 6 blocks/hour = 6 MB/hour

```

Converting to bytes/second, that's:

```
6 MB/hour * (1 hour/60 minutes) * (1 minute/60 seconds) * (1,000,000 bytes/1 MB) = 1,700 bytes/second

```

In other words, think of the blockchain as a hard drive. We can write to this hard drive at a rate of 1,700 bytes/second.

Even if we develop faster computers, we can't write data faster than this because the network rejects any block larger than 1 MB. We need to make some allowances for SegWit, but for now, let's keep things simple.

A one-input, one-output Alice-Pays-Bob transaction requires ~ 200 bytes. This is the absolute best case. We can, therefore, obtain an upper bound on the transaction rate using:

```
v = w / z

```

where *v* is the maximum transaction volume, *w* is the write speed calculated above (1,700 bytes/second), and *z* is the average size of a transaction (200 bytes/transaction).

Plugging in the numbers:

```
v = 1,700 bytes/second * (1 transaction / 200 bytes) = 8 transactions/second

```

> The answer to my question should be something like verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.

The network might appear to have a limit based on hardware or validation, but it does not. At least not directly.

As to why we should limit the block chain's write speed in the first place, the answer has to do with network security. Increasing write speed means:

1. data flows through the network at a higher rate;
2. more data must be stored by every node;
3. more transactions must be validated by every node.

Every node sends and receives every block, and every block must be stored. Increasing the blockchain write speed means that every node pays the price. Some won't be able to keep up, regardless of write speed.

Transaction validation is a resource hog due to signature validation and UTXO set manipulation. Storage space and bandwidth are also considerations, but less resource-intensive than validation.

Now, if you're asking why we have a 1 MB limit given XXX computer has such-and-such technical capabilities, that's the realm of the Never Ending Debate. Calculations have been done and simulations have been reported. They are not hard to find. They are, however, hard to believe given their wildly-differing claims and underlying assumptions.

The best thing I can recommend is to download a copy of Bitcoin Core 0.16.0 and try syncing a node from scratch. Report back when you're done.

The write speed limit we see is a compromise between inclusivity (more people using bitcoin) and security (difficulty of double-spending attacks). The limit may not have been set correctly, but figuring out where (or even how) to set it is exceedingly difficult. Not because of lack of ideas, but because of too many and lack of widely-accepted selection criteria.


---

### Answer by username_1 on 2018-06-07. Score: 5

After reading the existing answers, and your comments on this, I believe what you're looking for is this.

Your question is based on a misunderstanding. The figure "Bitcoin can process 7 transactions per second" is not a burst rate. It is talking about the long-term network-wide average, and results from the fact that (a) blocks are limited in size and (b) the block production rate is limited.

Individual Bitcoin node implementations can process far more transactions per second than that, but they necessarily need to be many times faster than the rate at which the whole network operates.

When a new block is created, nodes in the network need to be able to process it quickly, in order to not delay how long it takes before other miners can start building on top of that block. Due to the inherent variance in block production, the next block has a small but significant probability of being found just seconds later. If network nodes can't verify the previous block within that time, they are disadvantaged. However, the miner who created the block himself has no such penalty (he already knows his own block is valid). Generally these delays in processing tend to benefit the larger and well-connected miners proportionally more than smaller ones - an effect that is very detrimental to decentralization of the network, so to be avoided at all cost. For that reason, the time between blocks must be many times larger than the time it takes to verify the transactions in it.


---

### Answer by username_2 on 2018-06-08. Score: 4

I was in the same situation you are a month ago but reading around carefully and giving time to things seeping in has actually helped me understand a lot.

I'll try and keep my answer completely non-technical, just for better understanding purposes.

For a technical explanation, Andrew gave a good overview, username_6 gave the exact calculations behind the scenes and username_1 explained where you might be misunderstanding the transaction's process.

> Q1. I recently read (Scalability link) that bitcoin can do 3.3 to 7 transactions per second
>
> > A. The metric used to calculate the transaction speed is incorrect. What we can actually calculate is how many transactions are appearing in the blockchain every 10 mins, as the acceptance of each block to the blockchain takes approximately that much time. Hence, with the size of the block being 1MB and it getting added to the chain every 10 mins, currently, we can store only a limited amount (whatever 1MB can fit) of transactions every 10 mins.
> >
> > > How can this improve?
> > >
> > > > There are newer technologies, like [SegWit](https://en.wikipedia.org/wiki/SegWit "Read more about SegWit"), being added to the Bitcoin's core, which helps in breaking the data into useful information (transactions) and redundant information (signatures). There are also new hashing algorithms, like [Schnorr](https://en.wikipedia.org/wiki/Schnorr_signature "Read more about Schnorr"), which are under speculation to reduce the data usage of the block per transaction. There is also a second-layer on top of the Bitcoin blockchain, that handles transactions (even micro-transactions) separately altogether, a good example of which would be the [Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network "Read more about Lightning Network").
>
> Q2. I am curious, what is the bottleneck for the transaction rate?
>
> > A. People have correctly "chimed in" while saying that the bottleneck is the block size.
> >
> > > Going a little deeper...
> > >
> > > > For once there was a proposition of increasing the block size to eradicate the scaling problem [2MB block size in SegWit2x](https://en.wikipedia.org/wiki/SegWit2x "Read more about the planned hard fork"). You can find 'Bitcoin scalability problem' as a linked article in the 'see also' section on Wikipedia.
>
> Q3. Is it verifying the signatures? or maybe it's verifying sufficient funds?
>
> > A. No, verification of the signature occurs almost instantly and the sufficient funds part is handled by the client (maybe some wallet software or some exchange) you're using.
> >
> > > Still not convinced that it happens locally?
> > >
> > > > Here are a few references to back my claims: [How to calculate signature generation, signature verification, transaction verification speed?](https://bitcoin.stackexchange.com/questions/40824/how-to-calculate-signature-generation-signature-verification-transaction-verif) , [How much time it takes to verify a Bitcoin signature in the Satoshi client?](https://bitcoin.stackexchange.com/questions/7363/how-much-time-it-takes-to-verify-a-bitcoin-signature-in-the-satoshi-client) , [How do nodes verify Bitcoin Transactions?](https://bitcoin.stackexchange.com/questions/9248/how-do-nodes-verify-bitcoin-transactions) , [Verification of transaction once trasaction is broadcasted](https://bitcoin.stackexchange.com/questions/23363/verification-of-transaction-once-trasaction-is-broadcasted/23366#23366)
>
> Q4. My question is, what process is hogging the resources limiting the number of transactions per second?
>
> > A. The process called 'Proof of Work' is limiting the number of transactions per second (actually per 10 mins to be more precise)
> >
> > > If u still don't trust what I say...
> > >
> > > > [Please go through this wiki - Proof of Work (PoW)](https://en.bitcoin.it/wiki/Proof_of_work "Read more about the Proof of Work") as it'll briefly introduce you to PoW - `"The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes"`. You can even read through other pages in that wiki for better understanding.

I hope this clarifies each and every question of yours.


---

### Answer by username_3 on 2018-06-01. Score: 3

The bottleneck is the number of transactions that can fit in a block, and the frequency of blocks.

You can create an infinite number of transactions per second and broadcast them to the network, but that is irrelevant because those transactions are not considered final. They are considered reversible and insecure.

For a transaction to be considered final and secure, it must be included in a block. So the transaction rate that is often cited as being 3 to 7 transactions per second is limited by the number of transactions that can fit in a block and the frequency of blocks as that metric only considers transactions that are final and secure.

---

The actual number of transactions per second that bitcoind can verify is somewhere in the thousands of transactions per second. Transactions can be verified very quickly and the limiting factor becomes hardware. Furthermore, it depends on your hardware; a slow CPU could be the bottleneck for some devices, while a slow hard drive may be the bottleneck for others.

However the number of transactions that bitcoind can verify is irrelevant as those transactions are not confirmed and thus not final, which is what really matters. The rate at which transactions become confirmed and final is limited by the block size as explained earlier.

> **Comments:**
> **username_0**: Thank you for your answer, however, I am more interested in the technical details of the bottleneck, I have updated my question with some examples of what I believe the bottle neck might be  
> **username_1**: No, there is a hardcoded limit to the size of blocks, and blocks above that size are simply rejected by nodes that validate them. The reasons for why that limit exist are already answered in several other questions.  
> **username_0**: ok, I understand that, but that doesn't tell me why bitcoind doesn't process more than 7 transactions a second...  
> **username_3**: No more than a certain number of transactions can fit in a block, which are found, on average, every 10 minutes. Since "processing a transaction" means including it in a block, the bottleneck is in the number of transactions that can be included in a block and the amount of time required to produce a block. When you take the maximum number of transactions that can fit in a block and divide that by the average time to find a block, then you get a number that is around 7 transactions per second.  
> **username_0**: So what you are telling me, is that if 10 transactions get broadcast in one second, then bitcoind can include them in the next block within a second? What if a 100 transactions were broadcast in one second?  
> **username_4**: @JeffreyL.username_0 blocks get mined every 10 minutes. A typical 1-input-2-outputs transaction takes around 250 bytes. Each block has 1MB room for transactions so it can take around 4000. 4000/10minutes = 6.67/sec  
> **username_0**: hrmmm, my last comment, my apologies, but to me, that is the average amount of transactions per second, not the transactions per second rate  
> **username_3**: The transactions per second rate that is commonly cited is exactly that: the average amount of transactions per second.  
> **username_0**: So what is the max? Im guessing hardware plays a role in that, but there should be a range, the range ive found is 3.3 to 7 transactions per second, now back to my question, what is the limiting factor or resource hog that limits bitcoind to 7 transactions per second?  
> **username_3**: As has been stated multiple times in this answer, the limiting factor is the number of transactions that can fit in a block. This is completely unrelated to bitcoind, it is related to Bitcoin's consensus rules. bitcoind itself can verify many thousands of transactions per second with the limiting factor being your hardware. But for the network as a whole, the limit is in the consensus rules.  
> **username_3**: What exactly do you not understand about the answer? You keep asking the same question over and over again. Please clarify what you don't understand about the answer.  
> **username_0**: I think something is getting lost in translation here, you keep offering me the average number of transactions per second, and I am looking for the limiting factor of the actual number of transactions per second...  
> **username_3**: The  number that you have cited (which I assume is what you believe is the "actual number of transactions per second") is actually the average number of transactions per second. The actual number of transactions per second that bitcoind can handle is very large, on the order of thousands of transactions per second and varies highly due to hardware.  
> **username_5**: I know comments are not for thank-you but, I wanted you to know I upvoted your answer anyway.  

---

### Answer by username_5 on 2018-06-07. Score: 1

> I am curious, what is the bottle neck for the transaction rate?

If I broadcast several thousand **valid** transactions per second onto the Bitcoin network;

1. Those transactions will be validated when received by each node and enter each node's individual mempool until the individual mempool resources are exhausted, in which case each node has its own rules about how to handle additional new transactions. Some nodes with slower hardware may not keep up but that is irrelevant as the mempool is not ever in consensus.
2. A miner draws a number of transactions from their own mempool using any selection criteria that they wish (transactions in mempool have already been validated), not more than the maximum block size in block weight per consensus rules, constructs a proposed block and attempts to make it valid by incrementing nonce (simplified). This process of solving a block takes on average ten minutes and is regulated to maintain that average block time per consensus rules. Ten minutes is currently considered the optimum for security and reliability.
3. Since there is a fixed maximum block size in block weight AND a regulated average interval, this is the limiting factor for transaction bandwidth rate since a non-infinite number of transactions may be compiled into a valid block and will take an average of ten minutes to solve. This can be shown as:
   (average number of transactions that will fit in a block in block weight)/average block time in seconds = approximately 7 transactions per second maximum, however, this ideal figure would be seldom possible to maintain using real data.

Note that I have marked valid at the top of these statements in bold.

> My question is, what process is hogging the resources limiting the amount of transactions per second...

It is not a process, it is the application of consensus rules.


---

