Difference between revisions of "Bitcoin and Litecoin Comparison"
From Litecoin Wiki
(latest github revision, mediawiki format but disabled links because of spam protection? removed p2pool section) |
(→Conclusion: updated) |
||
| Line 1: | Line 1: | ||
==CPU mining vs GPU mining== | ==CPU mining vs GPU mining== | ||
| − | For | + | For [https://en.bitcoin.it/wiki/Proof_of_work proof of work], Bitcoin uses the highly parallelizable SHA256 hash function, and therefore Bitcoin mining is a GPU-friendly task. Litecoin uses [http://www.tarsnap.com/scrypt.html scrypt] instead of SHA256 for proof of work. The scrypt hash function uses SHA256 as a subroutine, but it also depends on fast access to large amounts of memory rather than depending just on fast arithmetic operations, so it is more difficult to run many instances of scrypt in parallel by using the [http://en.wikipedia.org/wiki/Arithmetic_logic_unit ALUs] of a modern graphics card. This also implies that the manufacturing cost of specialized scrypt hardware (ASIC) will be significantly more expensive than SHA256 ASIC. Since modern graphics cards have plenty of RAM, they do prove useful for Litecoin mining, though the improvement over CPUs is less significant than it was for Bitcoin mining (about 10x speedup instead of 20x speedup when comparing Radeon 5870 GPU to quad-core CPU, see [[Mining hardware comparison|Litecoin hardware comparison]] and {https://en.bitcoin.it/wiki/Mining_hardware_comparison Bitcoin hardware comparison]). |
| + | |||
| + | The particular scrypt parameters that Litecoin uses (N=1024,p=1,r=1) let non-mining users who run the full client (and therefore need to verify the blocks) multitask in their operating system without affecting the responsiveness, while still reducing the advantage of ASIC by a 10-fold estimate (according to Colin Percival, the creator of scrypt, see [http://bitbin.it/7bmKZqTx]). | ||
See also: {http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda bcrypt in Cuda?], {https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU Why a GPU mines faster than a CPU], {http://en.wikipedia.org/wiki/Bcrypt bcrypt] (scrypt predecessor) | See also: {http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda bcrypt in Cuda?], {https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU Why a GPU mines faster than a CPU], {http://en.wikipedia.org/wiki/Bcrypt bcrypt] (scrypt predecessor) | ||
| Line 9: | Line 11: | ||
* If your computer already mines bitcoins, then the CPU on that computer is probably idle, so you can simultaneously mine litecoins without affecting the speed in which your GPU mines bitcoins. | * If your computer already mines bitcoins, then the CPU on that computer is probably idle, so you can simultaneously mine litecoins without affecting the speed in which your GPU mines bitcoins. | ||
| − | * There is a danger that some entities would make a large one-time investment in {http://en.wikipedia.org/wiki/Application-specific_integrated_circuit ASICs] to outcompete GPUs, thereby centralizing the mining aspect of the Bitcoin network, i.e. the market entry costs for Bitcoin mining would become too expensive for most people (this assumes that the objective of those entities isn't to sell their ASICs on the market). The scrypt algorithm used by Litecoin ensures that lots of memory is needed per hash attempt, basically by using the input as a seed to fill a large amount of memory with a {http://en.wikipedia.org/wiki/Pseudorandom_number_generator pseudorandom sequence], and then using another seed derived from the input in order to access this sequence at pseudorandom points while generating the output hash. Since memory is the resource of general-purpose computers which is the most expensive to reproduce for ASICs (in particular it's more expensive than ALUs), this means that a one-time investment in ASICs for Litecoin mining would be much more expensive {http://www.tarsnap.com/scrypt.html]. The memory size parameter of scrypt was selected (originally by ArtForz and Lolcust) to fit into | + | * There is a danger that some entities would make a large one-time investment in {http://en.wikipedia.org/wiki/Application-specific_integrated_circuit ASICs] to outcompete GPUs, thereby centralizing the mining aspect of the Bitcoin network, i.e. the market entry costs for Bitcoin mining would become too expensive for most people (this assumes that the objective of those entities isn't to sell their ASICs on the market). The scrypt algorithm used by Litecoin ensures that lots of memory is needed per hash attempt, basically by using the input as a seed to fill a large amount of memory with a {http://en.wikipedia.org/wiki/Pseudorandom_number_generator pseudorandom sequence], and then using another seed derived from the input in order to access this sequence at pseudorandom points while generating the output hash. Since memory is the resource of general-purpose computers which is the most expensive to reproduce for ASICs (in particular it's more expensive than ALUs), this means that a one-time investment in ASICs for Litecoin mining would be much more expensive {http://www.tarsnap.com/scrypt.html]. The memory size parameter of scrypt was selected (originally by ArtForz and Lolcust) to fit into 128.5kB, so that it'd only hit the {http://en.wikipedia.org/wiki/CPU_cache L1/L2 cache] and leave the L3 cache and the RAM alone. This means that it's possible to mine litecoins without affecting system responsiveness, and without affecting the GPUs speed in case the same computer also mines bitcoins, while still requiring a significantly large amount of memory per hash attempt. |
* Websites can easily embed a Litecoin miner so that casual visitors would be able to support the website by contributing their spare CPU cycles while browsing ({http://www.litecoinpool.org/embed example]). Having {http://en.wikipedia.org/wiki/OpenCL OpenCL] access through web browsers in order to utilize the GPU of casual visitors is much more problematic. | * Websites can easily embed a Litecoin miner so that casual visitors would be able to support the website by contributing their spare CPU cycles while browsing ({http://www.litecoinpool.org/embed example]). Having {http://en.wikipedia.org/wiki/OpenCL OpenCL] access through web browsers in order to utilize the GPU of casual visitors is much more problematic. | ||
| Line 16: | Line 18: | ||
===Cons=== | ===Cons=== | ||
| − | * Attacks by | + | * Attacks by [http://en.wikipedia.org/wiki/Botnet botnets]. If the botnet operator runs an unmodified litecoind in order to earn coins then such a botnet only attacks the computers under its control, not Litecoin itself, as it would actually strengthen the Litecoin network. However, the objective of a crypto-currency is to improve the world rather than to improve itself. Botnets with a high enough proportion of the total hash power could try [https://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending double-spending] attacks on the Litecoin network. |
==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 26: | 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 40: | 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== | ||
| Line 53: | Line 55: | ||
* Unstable difficulty might encourage chain hopping. | * Unstable difficulty might encourage chain hopping. | ||
| − | * Less security from attacks that rely on lowering the difficulty. Example: an attacker makes a one time investment in hash power, uses this hash power to start extending a recent block with his own fork of consecutive blocks while lowering the difficulty (easier to do with the shorter retarget window), isolates a node of e.g. some online bank from the rest of the network, waits until his fork is longer than what this node has already seen in the real blockchain, broadcasts his forked chain to this node, and with the lower difficulty he now needs less hash power to continue to communicate with the isolated node until it agrees to transact in the forked chain. | + | * Less security from attacks that rely on lowering the difficulty. Example: an attacker makes a one time investment in hash power, uses this hash power to start extending a recent block with his own fork of consecutive blocks while lowering the difficulty (easier to do with the shorter retarget window), isolates a node of e.g. some online bank from the rest of the network, waits until his fork is longer than what this node has already seen in the real blockchain, broadcasts his forked chain to this node, and with the lower difficulty he now needs less hash power to continue to communicate with the isolated node until it agrees to transact in the forked chain. [https://bitcointalk.org/index.php?topic=46498.msg556137#msg556137] |
==Total number of coins in existence== | ==Total number of coins in existence== | ||
| − | The total number of litecoins that will come into existence is 4 times the total number of bitcoins that will come into existence, 84 million compared to 21 million. The reward for each Litecoin block is 50 litecoins. The rate of litecoins generation is halved every 840,000 blocks, i.e. 4 times more blocks than with Bitcoin. Since Litecoin blocks are generated 4 times faster than Bitcoin blocks, this means that the monetary inflation of Litecoin follows the same trajectory as that of Bitcoin | + | The total number of litecoins that will come into existence is 4 times the total number of bitcoins that will come into existence, 84 million compared to 21 million. The reward for each Litecoin block is 50 litecoins. The rate of litecoins generation is halved every 840,000 blocks, i.e. 4 times more blocks than with Bitcoin. Since Litecoin blocks are generated 4 times faster than Bitcoin blocks, this means that the monetary inflation of Litecoin follows the same trajectory as that of Bitcoin [https://en.bitcoin.it/wiki/Controlled_Currency_Supply] [http://en.wikipedia.org/wiki/Bitcoin#Monetary_differences], so for example at the year 2020 around 3/4 of all litecoins will have already been generated. |
==Bug fixes== | ==Bug fixes== | ||
| − | * Time warp bug | + | * Time warp bug [https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772]: the Bitcoin difficulty calculation is off by one block, so an attacker can repeatedly try to generate the last block of each retarget window, and use a fabricated timestamp of 2 hours into the future in order to make the time difference from the first block in the retarget window high, thus lowering the difficulty by 0.5%. Because of the bug, the bogus timestamp isn't used as the first block in the next retarget window, and therefore the 2 extra hours aren't being compensated for in the next difficulty calculation. Once the difficulty is low, the attacker can mine many fast coins, or in the case of a small chain, an attacker with 51% hash power could reduce the difficulty to 1 and mine a new fork from the genesis block. This isn't a feasible attack on Bitcoin, because the probability of repeatedly generating the last block once every 2 weeks at such high difficulties is negligible. Although fixing this issue in Bitcoin is possible, it should be done carefully (by adding rules that encourage nodes to upgrade over time) so to avoid a chain fork, i.e. old clients who didn't upgrade might operate with another difficulty and therefore disagree regarding which blocks are valid. In Litecoin this bug is fixed. [https://github.com/coblee/litecoin/commit/b1be77210970a6ceb3680412cc3d2f0dd4ca8fb9] |
==Conclusion== | ==Conclusion== | ||
The purpose of Litecoin is to function as silver to Bitcoin's gold, in the sense of being a relatively less valuable coin that is easier to obtain and transact with. The properties that make Litecoin fit to accomplish this objective can be summarized as follows: | The purpose of Litecoin is to function as silver to Bitcoin's gold, in the sense of being a relatively less valuable coin that is easier to obtain and transact with. The properties that make Litecoin fit to accomplish this objective can be summarized as follows: | ||
| − | * Transactions are 4 times faster than with Bitcoin, in exchange for | + | * Transactions are 4 times faster than with Bitcoin, in exchange for possibly weaker security guarantees (depending on human behavior). |
| − | * CPU mining means that the barriers to entry into the Litecoin mining market are cheap relative to Bitcoin mining. | + | * CPU/GPU mining means that the barriers to entry into the Litecoin mining market are cheap relative to Bitcoin mining. |
* The total amount of litecoins is 4 times higher than the total amount of bitcoins. | * The total amount of litecoins is 4 times higher than the total amount of bitcoins. | ||
