<p>This is a potential issue in bitcoin but much more so in altcoins.  Bitcoin is very conservative in the richness of its transaction script.  Altcoins with a faster block time and/or less restrictive scripting engines need to make substantial optimizations for this not to be a risk.  </p>

<p>This one of the issues around increasing the blocksize to something like 8MB.  </p>

<p>Rusty Russell discusses in a post about the megatransaction (<a href="https://rusty.ozlabs.org/?p=522" rel="nofollow">https://rusty.ozlabs.org/?p=522</a>).</p>

<p>According to Rusty </p>

<blockquote>
  <p>if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB
  of outputs takes over 11 minutes to hash.  If you can mine one of
  those, you can keep competitors off your heels forever, and own the
  bitcoin network</p>
</blockquote>

<p>The bitcoin core developers have been making substantial improvements to bitcoin infrastructure (like libsecp256k1) to make future expansion possible.  But this is an example of how a simple constant change can have far reaching effects.</p>

CC BY-SA 3.0
2016-05-14T01:38:33.390Z
2016-05-14T01:38:33.390Z
Jonathan
<p>You shouldn't need to worry about this ever happening.</p>

<p>There are no loop opcodes in scripts. Every script opcode can only be executed once, and the slowest opcode is probably ECDSA signature verification (because it involves EC_point_multiply). Even so, it only takes about 50~100μs on a single core of a modern CPU to process.</p>

<p>Let's assume a 1MB block (max size) contains 100% signature verification opcodes, that's 1 million signature verification and takes at most 100 seconds CPU time of a single core, this is still much lower than the block time. In practice each scriptSig is accompanied by at least 100 bytes of data (pubkey + ECDSA signature) so it probably takes less than 1 second of CPU time.</p>

CC BY-SA 3.0
2014-03-12T11:27:53.523Z
Your right about Bitcoin.  I did narrow the scope of my question to alt coins after I read this answer. Some others are changing what's possible in script.
makerofthings7
CC BY-SA 3.0
2014-03-12T12:54:21.310Z
As OP says, this could become a problem for an alt-coin whose block generation time is less than 100 secs should they have always 1MiB blocks: wallets in machines with slow/single-core CPUs would fall behind the network. So perhaps the block max. size should be tweaked as well when an alt-coin is created to prevent this...
Joe Pineda
CC BY-SA 3.0
2014-03-12T06:19:52.523Z
2014-03-12T06:28:52.930Z
2014-03-12T06:28:52.930Z
uminatsu
<p>If its just a single node that lags behind, any of it's generated blocks could easily become an orphan block unaccepted by the network. If this is a flaw/bug in the altcoin the difficulty adjusts downwards until the minimum since it sees no nodes are completing blocks fast enough (which is impossible if block processing will always take longer than the block time).</p>

<p>As mentioned this bug is not likely to happen as processing times are negligible for blocks. Unless your block time is that low, but you will run into bigger problems if your block time is sub-second.</p>

CC BY-SA 3.0
2014-03-12T21:12:23.047Z
2014-03-12T21:12:23.047Z
John T
<p>I don't know when and how often a script is executed, but it seems to me that there would be a problem if a single script (or a sum of all scripts in a block) exceeds the time it takes to be included in a block. </p>

<p>Given that the trend in alt coins is to decrease the block time duration,  I think this could become an issue or race condition where the TX never gets included in a block. </p>

<p>Considering that as the various alt coin block sizes grow ... Perhaps larger than 1mb, this risk would grow as well, given the higher quantity of transactions. </p>

<p>So my question is: </p>

<ul>
<li>When are transaction scripts evaluated (or not )?</li>
</ul>

<p>I heard that certain old TX scripts aren't validated during the initial sync to speed up the process, so perhaps there are other times that a TX isn't executed. (Perhaps it's an unknown script.)</p>

<ul>
<li>What role does CPU load have on the network and the risk of a fork?</li>
</ul>

<p>Perhaps only miners are only affected.... I'm unsure.</p>

<ul>
<li>If the network running full nodes has capacity issues with either CPU or bandwidth could a fork occur?</li>
</ul>

<script><altcoin><blockchain-fork><transaction-verification><block-interval>
What if the execution time for an alt coin script exceeds the block time?
makerofthings7
# What if the execution time for an alt coin script exceeds the block time?

(Asked by: username_0 on 2014-03-12)

I don't know when and how often a script is executed, but it seems to me that there would be a problem if a single script (or a sum of all scripts in a block) exceeds the time it takes to be included in a block.

Given that the trend in alt coins is to decrease the block time duration, I think this could become an issue or race condition where the TX never gets included in a block.

Considering that as the various alt coin block sizes grow ... Perhaps larger than 1mb, this risk would grow as well, given the higher quantity of transactions.

So my question is:

* When are transaction scripts evaluated (or not )?

I heard that certain old TX scripts aren't validated during the initial sync to speed up the process, so perhaps there are other times that a TX isn't executed. (Perhaps it's an unknown script.)

* What role does CPU load have on the network and the risk of a fork?

Perhaps only miners are only affected.... I'm unsure.

* If the network running full nodes has capacity issues with either CPU or bandwidth could a fork occur?

**Tags:** script, altcoin, blockchain-fork, transaction-verification, block-interval


---

## 3 answers

### Answer by username_1 on 2016-05-14. Score: 3

This is a potential issue in bitcoin but much more so in altcoins. Bitcoin is very conservative in the richness of its transaction script. Altcoins with a faster block time and/or less restrictive scripting engines need to make substantial optimizations for this not to be a risk.

This one of the issues around increasing the blocksize to something like 8MB.

Rusty Russell discusses in a post about the megatransaction (<https://rusty.ozlabs.org/?p=522>).

According to Rusty

> if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB
> of outputs takes over 11 minutes to hash. If you can mine one of
> those, you can keep competitors off your heels forever, and own the
> bitcoin network

The bitcoin core developers have been making substantial improvements to bitcoin infrastructure (like libsecp256k1) to make future expansion possible. But this is an example of how a simple constant change can have far reaching effects.


---

### Answer by username_2 on 2014-03-12. Score: 2

You shouldn't need to worry about this ever happening.

There are no loop opcodes in scripts. Every script opcode can only be executed once, and the slowest opcode is probably ECDSA signature verification (because it involves EC\_point\_multiply). Even so, it only takes about 50~100μs on a single core of a modern CPU to process.

Let's assume a 1MB block (max size) contains 100% signature verification opcodes, that's 1 million signature verification and takes at most 100 seconds CPU time of a single core, this is still much lower than the block time. In practice each scriptSig is accompanied by at least 100 bytes of data (pubkey + ECDSA signature) so it probably takes less than 1 second of CPU time.

> **Comments:**
> **username_0**: Your right about Bitcoin.  I did narrow the scope of my question to alt coins after I read this answer. Some others are changing what's possible in script.  
> **username_3**: As OP says, this could become a problem for an alt-coin whose block generation time is less than 100 secs should they have always 1MiB blocks: wallets in machines with slow/single-core CPUs would fall behind the network. So perhaps the block max. size should be tweaked as well when an alt-coin is created to prevent this...  

---

### Answer by username_4 on 2014-03-12. Score: 0

If its just a single node that lags behind, any of it's generated blocks could easily become an orphan block unaccepted by the network. If this is a flaw/bug in the altcoin the difficulty adjusts downwards until the minimum since it sees no nodes are completing blocks fast enough (which is impossible if block processing will always take longer than the block time).

As mentioned this bug is not likely to happen as processing times are negligible for blocks. Unless your block time is that low, but you will run into bigger problems if your block time is sub-second.


---

