user1878: 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?


user13751: 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.

user27029: 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.

1878: <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>
 13751: <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>
 27029: <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>
