Difference between revisions of "Bitcoin and Litecoin Comparison"
From Litecoin Wiki
m (→CPU mining vs GPU mining) |
m (→Faster transaction time) |
||
| Line 21: | Line 21: | ||
==Faster transaction time== | ==Faster transaction time== | ||
| − | The | + | The [https://en.bitcoin.it/wiki/Difficulty difficulty] of Litecoin adjusts so that a block is generated every 2.5 minutes on average, instead of the 10 minutes average of Bitcoin. |
===Pros=== | ===Pros=== | ||
| Line 28: | Line 28: | ||
* Greater granularity, for example merchants may wish to accept transactions with only 2 confirmations in Litecoin (5 minutes), while in Bitcoin you would have to wait at least 1 confirmation (10 minutes). | * Greater granularity, for example merchants may wish to accept transactions with only 2 confirmations in Litecoin (5 minutes), while in Bitcoin you would have to wait at least 1 confirmation (10 minutes). | ||
| − | * Waiting for the additional confirmations during about the same time period that's used with Bitcoin (e.g. 24 Litecoin blocks instead of 6 Bitcoin blocks) means that an attacker will start the gambler's ruin process | + | * Waiting for the additional confirmations during about the same time period that's used with Bitcoin (e.g. 24 Litecoin blocks instead of 6 Bitcoin blocks) means that an attacker will start the gambler's ruin process [http://www.bitcoin.org/bitcoin.pdf] [https://bitcoil.co.il/Doublespend.pdf] [http://en.wikipedia.org/wiki/Gambler's_ruin] with a greater deficit, so the probability for a double-spending attack to succeed is smaller. To elaborate: assuming that SHA256 is a random function, the probability of successfully generating a block at each nonce attempt is constant and independent of all other attempts [https://bitcointalk.org/index.php?topic=5521.0]. Now suppose for the sake of argument that it takes on average one year to generate a block, that an attacker A has 20% of the total hash power, that an honest miner B has the other 80% of the hash power, that a merchant C waited for 4 confirmations i.e. about 4 years before sending the merchandise to A, and that during those 4 years A managed to generate 1 block (on average that's what we'd expect) in secret. So A and B now compete in the gambler's ruin game, with A starting the game with a deficit of 3 blocks, and having 1/5 chance of winning each round. Because all nonce attempts are independent, if A won the first round then all the work that B did in this round is disregarded, and A and B start the second round from scratch. For stronger security, C can wait for more than 4 blocks before sending the merchandise, so the initial deficit of A is expected to be higher, i.e. B can spare to lose more rounds and therefore the probability of A carrying out a successful double-spending attack is smaller. Intuitively, the stronger security is achieved because A has a better chance to defeat B in few rounds than in many rounds (because he's at a proportionate disadvantage in each round), so by forcing A to play more rounds before sending the merchandise he would need a higher proportion of wins during this confirmations period in order to stand a chance in the gambler's ruin game that follows (for example with 40 confirms and same 20% hash power he's expected to fork 10 secret blocks and have a deficit of 30 blocks, as opposed to 3 blocks). The average time of each round doesn't play a role in the analysis, the relevant parameters are the proportion between the hash power of A and B in each round, and the amount of rounds. So in case the average time to generate a block was e.g. one minute instead of one year, this analysis would still hold, unless the 1min block time has detrimental effects on the honest miner(s) relative to the attacker (see cons). |
** Therefore, relative to Bitcoin the security may be enhanced for Litecoin users who wish to wait for the extra confirmations. | ** Therefore, relative to Bitcoin the security may be enhanced for Litecoin users who wish to wait for the extra confirmations. | ||
===Cons=== | ===Cons=== | ||
| − | * More overhead, the blockchain becomes more bloated. Clients running in | + | * More overhead, the blockchain becomes more bloated. Clients running in [https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification simple verification mode] will be affected the most: in simple verification mode the client stores only the block headers and current wallet balance, so 4x more storage space will be needed for Litecoin 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 | + | * Less security if everyone waits for a fixed amount of confirmations (e.g. 6 blocks), because the higher amount of [https://en.bitcoin.it/wiki/Block_chain orphan blocks] implies that relatively less honest computing power is being put to good use while verifying the blocks, so it would be easier for an attacker to double-spend litecoins compared to bitcoins. To elaborate: let's assume network propagation time of 2 seconds, i.e. it takes 2 seconds for each node to broadcast the longest chain that it knows of to all other nodes. With 2.5min blocks, on average once every 150 seconds some node broadcasts the valid block that it found, so during the 2 seconds of propagating the new block, the other miners are wasting their hash power while working on a shorter chain, which implies that 2 out of 150 seconds are being wasted on average. If there's a fork where different groups of miners work on different chains of same length then that's ok, i.e. they don't dilute any of their hash power because of this fork, and if different groups of miners work on forks of different lengths then they'll switch to the longest chain after the network latency interval. So in total 2/150 of the honest hash power is being wasted, i.e. 1.33% dilution, compared to 10min blocks where 2/600 is 0.33% dilution. |
** 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 . | ** 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 2.5min difficulty requires 4x less hash power compared to generating 6 blocks of 10min difficulty. So an attacker could afford more double-spending attempts | + | ** 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 2.5min difficulty requires 4x less hash power compared to generating 6 blocks of 10min difficulty. So an attacker could afford more double-spending attempts [https://bitcointalk.org/index.php?topic=51504.msg615442#msg615442]. |
* 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. | * 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. | ||
| Line 42: | Line 42: | ||
* 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). | * 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). | ||
| − | See also: | + | See also: [https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation Myth - Point of sale with bitcoins isn't possible because of the 10 minute wait for confirmation] |
==Difficulty retarget== | ==Difficulty retarget== | ||
