Litecoin (LTC) is a peer-to-peer cryptocurrency that aims to enable fast and low-cost payments to anyone in the world.
The Litecoin Project was conceived and created by Charles Lee, a former Coinbase employee, with the support of multiple members in the Bitcoin community. It was launched on October 13th 2011, and has introduced a number of modifications based on the original Bitcoin protocol.
The most prominent of these is Litecoin’s Proof-of-Work consensus: its algorithm is based on Scrypt, instead of SHA-256d. Furthermore, Litecoin has a target block time of 2.5 minutes, and a total supply of 84 million.
In May 2017, Litecoin adopted Segregated Witness (SegWit). In the same month, the first Lightning Network transaction was completed on Litecoin, transferring 0.00000001 LTC from Zürich to San Francisco in under one second.
Future development areas include the addition of privacy-features (an implementation of the MimbleWimble protocol), the support of Schnorr Signatures, and Taproot (a privacy preserving switchable scripting feature).
1. What is Litecoin (LTC)?
Litecoin (LTC) is a peer-to-peer cryptocurrency powered by the Scrypt Proof-of-Work algorithm. The project aims to provide an alternative to Bitcoin by making modifications to the original Bitcoin Protocol.
A Proof-of-Work algorithm creates a computational challenge to be solved by the network of computers in order to verify a block of transactions. The Scrypt algorithm was developed in 2009 by Colin Percival (Tarsnap Inc.). In contrast with Bitcoin’s SHA-256d, it serves to inhibit hardware scalability by requiring a significant amount of memory when performing its calculations.
This change aimed to reduce the efficiency gain and economic incentive to develop custom hardware such as Application Specific Integrated Circuits (“ASIC”). While this initially prevented ASIC mining, new machines have been more performant than GPU mining, leading to most of LTC mining activities being conducted by ASIC machines (e.g., Antminer L3+).
Litecoin has an average block time of 2.5 minutes, and a total supply of 84 million. The short block time inevitably leads to an increase in orphaned blocks.
Besides total supply and block time, other Bitcoin parameters have remained largely unchanged. For instance, the number of blocks between difficulty changes1 and the target number of years between block reward halving on Litecoin (4 years) remains the same as those on the Bitcoin protocol.
Unlike public blockchain infrastructures supporting the development of decentralized applications, such as Ethereum, Litecoin is primarily used only as a currency and does not support smart contracts.
2. Litecoin’s key features
Segregated Witness (shared with Bitcoin)
Segregated Witness (often abbreviated to SegWit) is a protocol upgrade proposal that went live in May 20172 for Litecoin (vs. August 2017 for Bitcoin).
It separates witness signatures from transaction-related data. Witness signatures in “legacy Bitcoin blocks” often take more than 50% of the block size. By removing witness signatures from the transaction block, this protocol effectively increases the number of transactions that can be stored in a single block, rendering the network capable of handling more transactions per second. As a result, SegWit increases the scalability of Nakamoto consensus-based blockchain networks Litecoin.
SegWit also makes transactions cheaper. Since transaction fees are derived from how much data is being processed by the block producer, the more transactions that can be stored in a 1MB block, the cheaper individual transactions become.
The legacy Bitcoin block has a block size limit of 1 megabyte, and any change on the block size would require a network hard-fork. On August 1st 2017, the first chain split occurred, leading to the creation of Bitcoin Cash (BCH), which introduced an 8 megabyte limit per block.
Conversely, Segregated Witness was a soft-fork: it never changed the transaction block-size limit of the network. Instead, it has added an extended block with an upper limit of 3 megabytes, which contains solely witness signatures, to the 1-megabyte block that contains only transaction data. This new block type can be processed even by nodes that have not completed this protocol upgrade.
Furthermore, the separation of witness signatures from transaction data solves the malleability issue of blockchains using the Nakamoto consensus. Without Segregated Witness, these signatures could be altered before the block is validated by miners. Indeed, alterations can be done in such a way that if the system does a mathematical check, the signature would still be valid. However, since the values in the signature are changed, the two signatures would create vastly different hash values.
For instance, if a witness signature states “6,” it has a mathematical value of 6, and would create a hash value of 12345. However, if the witness signature were changed to “06”, it would maintain a mathematical value of 6 while creating a (faulty) hash value of 67890.
Since the mathematical values are the same, the altered signature remains a valid signature. Hence, this would create a bookkeeping issue, as transactions in Nakamoto consensus-based blockchain networks are documented with these hash values or transaction IDs. Effectively, one can alter a transaction ID to a new one, and the new ID can still be valid.
This can create many issues as illustrated below:
Alice sends Bob 1 BTC, and Bob sends Merchant Carol this 1 BTC for some goods.
Bob sends Carols this 1 BTC, while the transaction from Alice to Bob is not yet validated. Carol sees this incoming transaction of 1 BTC to him, and immediately ships goods to B.
At the moment, the transaction from Alice to Bob is still not confirmed by the network, and Bob can change the witness signature, therefore changing this transaction ID from 12345 to 67890.
Now Carol will not receive his 1 BTC, as the network looks for transaction 12345 to ensure that Bob’s wallet balance is valid.
As this particular transaction ID changed from 12345 to 67890 the network will not be able to find this. The transaction from Bob to Carol will fail, and Bob gets his goods while still holding his BTC.
With the Segregated Witness update, such instances can not happen again. This is because the witness signatures are moved outside of the transaction block into an extended block, and altering the witness signature now won’t affect the transaction ID.
Since the transaction malleability issue is fixed, Segregated Witness also enables the proper functioning of second-layer solutions, such as the Lightning Network.
Lightning Network (shared with Bitcoin)
Lightning Network is a micropayment solution based on the Bitcoin protocol. It aims to enable near-instant and low-cost payments between merchants and customers that use Bitcoin.
Specifically, Lightning Network aims to enable near-instant and low-cost payments between merchants and customers that wish to use bitcoins.
Lightning Network was conceptualized in a whitepaper by Joseph Poon and Thaddeus Dryja in 2015. Since then, it has been implemented by multiple companies. The most prominent of them include Blockstream, Lightning Labs, and ACINQ.
For a list of curated resources relevant to Lightning Network, please visit this link.
In the Lightning Network, if a customer wishes to transact with a merchant, both of them need to open a payment channel, which operates off the Bitcoin blockchain (i.e., off-chain vs. on-chain). None of the transaction details from this payment channel are recorded on the blockchain. Hence, only when the channel is closed will the end result of both party’s wallet balances be updated to the blockchain. The blockchain only serves as a settlement layer for Lightning transactions.
Since all transactions done via the payment channel are conducted independently of the Nakamoto consensus, both parties involved in transactions do not need to wait for network confirmation on transactions. Instead, transacting parties would pay transaction fees to Bitcoin miners only when they decide to close the channel.
One limitation to the Lightning Network is that it requires a person to be online in order for him to receive transactions attributing towards him. Another limitation in user experience could be that one needs to lock up some funds every time he wishes to open a payment channel, and is only able to use that fund within the channel.
However, this does not mean he needs to create new channels every time he wishes to transact with a different person on the Lightning Network. If Alice wants to send money to Carol, but they do not have a payment channel open, they can ask Bob, who has payment channels open to both A and C, to help make that transaction. Alice will be able to send funds to Bob, and Bob to Carol. Hence, the number of “payment hubs” (i.e., Bob in the previous example) correlates with both the convenience and the usability of the Lightning Network for real-world applications.
MimbleWimble as a privacy feature (in implementation)
MimbleWimble is a data storage and transaction structure that aims to enhance privacy and fungibility while reducing network bloating and improving scalability. The Mimblewimble design was introduced in 2016 by pseudonymous Tom Elvis Jedusor. As of April 2020, MimbleWimble’s main stand-alone implementations are Grin (GRIN) and Beam (BEAM).
MimbleWimble is based on the UTXO model. However, in MimbleWimble there are no addresses, and UTXO values are encrypted by the "blinding factors". Blinding factors are private keys which are only known to the UTXO owner. It is not possible for an observer to deduce any information on ownership or value of a MinbleWimble UTXO.
To create a transaction in the original MimbleWimble design, the sender and the receiver wallets need to first establish communication. Once the communication is established, the sender provides the transaction inputs, and both sender and receiver create their respective outputs with range proofs attesting that the values are non-negative. Both parties sign the transaction before sending out to the nodes.
Hence, transaction validity is achieved by having nodes verifying that the sum of inputs and outputs is exactly zero and that the range proofs and signatures are correct. Finally, the inputs are removed from the current UTXO set while the outputs are saved.
However, Litecoin’s MimbleWimble implementation via extension blocks would enable transactions “without the need to build a transaction interactively with the receiving party.” Specifically, Litecoin aims to achieve a similar result with Diffie-Hellman Key Exchange.
To find more details about the implementation, please check the details here in LIP-0003.
3. Economics and supply distribution
Litecoin utilizes the Nakamoto consensus, and nodes validate blocks via Proof-of-Work mining.
Litecoin was not pre-mined, and has a maximum supply of 84 million, exactly 4 times that of Bitcoin. The initial reward for a block is 50 litecoins, and halves every 840,000 blocks. Since the target time for block production on the Litecoin blockchain is 2.5 minutes, it implies that Litecoin block reward halving will take place every 4 years.
4. Project team
Litecoin’s development was initiated by Charlie Lee, and has been maintained by core developers and contributors from the community.
All development activities can be found here.
In addition, the Litecoin Foundation is actively involved in the development and the promotion of Litecoin use-cases across the globe.
The table below shows some of the most prominent members from the Litecoin Foundation.
5. Additional resources
Jedusor, T. E. (2016). Mimblewimble
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System
Unlike Bitcoin, it leads to an adjustment of the difficulty on average every 3.5 days (as block time targets are 4 times shorter than Bitcoin’s)↩
https://www.coindesk.com/litecoin-successfully-activates-long-debated-segwit-upgrade↩