Transaction capacity per second (TPS) is block capacity divided by the block interval in seconds. The average size of a transaction is 350 bytes, so a 1 MIB block can contain 2995To validate new transactions and, with a block interval of 600 secondsnodes need to:

• a 1 MIB block supports 4, maybe 5 TPS
• a 2 MIB block supports 9, maybe 10 TPS
• a 4 MIB block supports 19, maybe 20 TPS

1. identify the path of the output being spent by each input (i.e. block:txid:vout),
What if blocks only contain TXIDs instead of full transaction data? An attacker might exploit2. locate the lack of transaction data by fabricating a false transaction history and then, for each phony transaction, iterate through the output payment address like a nonce until it's TXID matches one in the block. To fix thisblockchain, each TXID is paired with it's output group hash (OGH). An output group hash is generated from a transaction's group of outputs. An attacker can't match both the TXID and OGH, so the TXIDs can safely be used to validate full transaction data, which is queried separately.
3. check every input in every transaction in every block after to make sure it isn't already spent
If the OGH is also 256 bits:   3a. if spent, skip sig verification and discard new transaction without propagation.

• a 1 MIB block will support 27 TPS
• a 2 MIB block will support 54 TPS
• a 4 MIB block will support 109 TPS

   3b. if not spent, verify signature.
Of course      3b1. If sig fails, it gets even better withdiscard new transaction without propagation.
      3b2. If sig succeeds, propagate.

Once confirmed in a shorter block interval, signatures don't need to be checked again, even by new nodes, so it doesn't need to be saved.
Blocks only need to save output data and the path of the spent output for each input.
The output paths of inputs cannot be substituted with hashes because collisions will invalidate legitimate outputs.

Transaction capacity per second (TPS) is block capacity divided by the block interval in seconds. The average size of a transaction is 350 bytes, so a 1 MIB block can contain 2995 transactions and, with a block interval of 600 seconds:

• a 1 MIB block supports 4, maybe 5 TPS
• a 2 MIB block supports 9, maybe 10 TPS
• a 4 MIB block supports 19, maybe 20 TPS

What if blocks only contain TXIDs instead of full transaction data? An attacker might exploit the lack of transaction data by fabricating a false transaction history and then, for each phony transaction, iterate through the output payment address like a nonce until it's TXID matches one in the block. To fix this, each TXID is paired with it's output group hash (OGH). An output group hash is generated from a transaction's group of outputs. An attacker can't match both the TXID and OGH, so the block referencesTXIDs can safely be used to validate full transaction data, which is queried separately.

If the OGH is also 256 bits:

• a 1 MIB block will support 27 TPS
• a 2 MIB block will support 54 TPS
• a 4 MIB block will support 109 TPS

Of course, it gets even better with a shorter block interval.

Transaction capacity per second (TPS) is block capacity divided by the block interval in seconds. The average size of a transaction is 350 bytes, so a 1 MIB block can contain 2,9952995 transactions and, with a block interval of 600 seconds:

• a 1 MIB block supports 4, maybe 5 TPS
• a 2 MIB block supports 9, maybe 10 TPS
• a 4 MIB block supports 19, maybe 20 TPS

What if blocks only contain TXIDs instead of full transaction data? An attacker might exploit the lack of transaction data by fabricating a false transaction history and then, for each phony transaction, iterate through the output payment address like a nonce until it's TXID matches one in the block. To fix this, each TXID is paired with it's output group hash (OGH). An output group hash is generated from a transaction's group of outputs. An attacker can't match both the TXID and OGH, so the block references can safely be used to validate full transaction data, which is queried separately.

If the OGH is also 256 bits:

• a 1 MIB block will support 27 TPS
• a 2 MIB block will support 54 TPS
• a 4 MIB block will support 109 TPS

Of course, it gets even better with a shorter block interval.

Transaction capacity per second (TPS) is block capacity divided by the block interval in seconds. The average size of a transaction is 350 bytes, so a 1 MIB block can contain 2,995 transactions and, with a block interval of 600 seconds:

• a 1 MIB block supports 4, maybe 5 TPS
• a 2 MIB block supports 9, maybe 10 TPS
• a 4 MIB block supports 19, maybe 20 TPS

What if blocks only contain TXIDs instead of full transaction data? An attacker might exploit the lack of transaction data by fabricating a false transaction history and then, for each phony transaction, iterate through the output payment address like a nonce until it's TXID matches one in the block. To fix this, each TXID is paired with it's output group hash (OGH). An output group hash is generated from a transaction's group of outputs. An attacker can't match both the TXID and OGH, so the block references can safely be used to validate full transaction data, which is queried separately.

If the OGH is also 256 bits:

• a 1 MIB block will support 27 TPS
• a 2 MIB block will support 54 TPS
• a 4 MIB block will support 109 TPS

Of course, it gets even better with a shorter block interval.