0.2 Faster transaction time - Makh1/italcoin GitHub Wiki

The difficulty of ITAL coin adjusts so that a block is generated every 4 minutes on average, instead of the 10 minutes average of Bitcoin.

Pros

  • Many people are anxious to see their transaction confirmed in the blockchain as soon as possible.

  • Greater granularity, for example merchants may wish to accept transactions with only 2 confirmations in ITAL coin (8 minutes), while in Bitcoin you would have to wait at least 1 confirmation (10 minutes).

  • Less expected time and variance until a miner earns his reward. For example, if the network consists of 1000 miners where each of them has an equal amount of hashpower, then an individual miner is expected to earn his reward after 1000 blocks on average, but waiting for 1000 blocks is 2.5 times faster with ITAL coin compared to Bitcoin. This implies that it is easier to sustain a relatively small mining pool with ITAL coin, hence ITAL coin can potentially be more decentralized than Bitcoin.

  • Waiting for the additional confirmations during about the same time period that's used with Bitcoin (e.g. 15 ITAL coin blocks instead of 6 Bitcoin blocks) means that an attacker will start the gambler's ruin process with a greater deficit, so the probability for a double-spending attack to succeed is smaller.

  • Therefore, relative to Bitcoin the security may be enhanced for ITAL coin users who wish to wait for the extra confirmations.

Cons

  • More overhead, the blockchain becomes more bloated. Clients running in simple verification mode will be affected the most: in simple verification mode the client stores only the block headers and current wallet balance, so 2.5x more storage space will be needed for ITAL coin clients relative to Bitcoin clients running in this mode.

  • Less security if everyone waits for a fixed amount of confirmations (e.g. 6 blocks), because the higher amount of work that honest miners spend on losing branches implies that relatively less computing power is being put to good use while generating the blocks, so it would be easier for a dedicated attacker to double-spend ITAL coins compared to bitcoins.

  • This analysis is incomplete because it only takes into account the dilution in hash power of the honest miners, and not the fact that when the blockchain forks more frequently it means that an attacker (with no hash power) could scan the network and try to double-spend by broadcasting inconsistent transactions to the competing chains. However, the probability of a fork (by the honest miners) to persist diminishes exponentially with the length of the forked chains. Therefore, a merchant can take precautions either by waiting for more confirms, or by scanning the network and looking for an attempt to double-spend the transaction that he received .

  • Waiting for the same fixed amount of confirmations means that even if the probability of carrying out a double-spending attack isn't much higher than with slower blocks, the cost of carrying out the double-spending attack is cheaper: generating 6 blocks of 4min difficulty requires less hash power compared to generating 6 blocks of 10min difficulty. So an attacker could afford more double-spending attempts. Though in the case of an attacker with less than 50% of the hash power who competes against a network in which merchants wait for a greater number of confirmations (for example 12 ITAL coin confirmations instead of 6 Bitcoin confirmations), the expected cost of a successful double-spending attack would be higher in comparison to the network with the slower blocks, since the success probability of the attack decreases exponentially with the amount of confirmations.

  • To be secure against an attacker who attempts to obtain the majority of the total hashpower, the longer the blocktime the better. The assumption here is that the attacker has local (or relatively fast) access to his mining equipment, and therefore doesn't suffer from dilution due to propagation lag as the honest network does.

  • Another security risk arises with attacks that rely on network partitioning, for example if Europe and America lose internet connectivity then an attacker could spend his coins in both continents. The relevant parameter in these scenarios is the absolute time until all nodes have enough time to communicate with each other, not the frequency of generated blocks. Therefore, this isn't an inherent problem of the protocol, because waiting for 4 times the amount of blocks relative to Bitcoin would be adequate, or in other words the problem lies in the default amount of confirmations.

  • If the number of transactions increases by an extremely large factor, it will require more computational power to validate an increased number of ECDSA signatures at each block. With fast blocks, doing this validation in time could potentially be a problem: if there's a non-negligible probability that the time to find a nonce which generates a valid PoW is shorter than the time to validate all the ECDSA signatures in the block, then an attacker can gain an advantage over honest miners by purposely generating blocks that include fewer transactions (currently an attacker has very little to gain by trying to generate empty blocks, and one relevant effect is that the coins that he earns could become less worthy because their market value drops due to this attack).