3

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?
Improve this question
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.

Improve this answer
2
  • 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. – halfbit Mar 12 '14 at 11:27
  • 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 Mar 12 '14 at 12:54
2

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.

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.