Earlier today the long awaited proposal for the Litecoin Project’s MimbleWimble (MW) implementation was published to the organisations Github as new pull requests under the Litecoin Improvement Protocol (LIP) titles LIP 2 & LIP 3.
LIP 2 focuses on the Extension blocks (EB) Implementation, a method first described by bitcoin developer, Johnson Lau, that would allow for not only MimbleWimble but an effective blocksize increase to be added without any consensus rule changes to the network. Although the exact size is still up for debate as the team are yet unsure at what it should be set at and whatever is chosen will be fixed once accepted.
“More discussion must be had around what the extension block size should be.”
It will be up to the network to vote on the final code and whether or not to adopt the new technology, this is otherwise known as a soft fork. The Proposal writes the fork will be activated 1 year from the day the implementation is released and that miners will be able to activate it early with a 75% signaling threshold.
“Our primary motivation behind EB is to implement opt-in MimbleWimble. This is something that is currently not possible through a traditional soft-fork because MimbleWimble is not script-based. However, there is also an opportunity to lay the groundwork to implement alternative proposals using EB as well.”
These Extension Blocks will run parallel along side the main Litecoin blockchain. To differentiate the EB chain from the parent and ensure compatibility with existing rules a new witness program will be implemented. This new witness will use Bech32 (addresses starting with lc1) due to its efficiency over legacy (L) and standard segwit addresses (M), it will also mean lower transaction fees in comparison.
“An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.”
Notably the EB chain will also have to store its own set of Unspent Transaction Outputs (UTXO)in order to keep track of things.
EB is technically more complex as opposed to a straight forward hard fork of MW something the LIP does not mention, as such it may introduce new issues into the system if not properly scrutinised and tested beforehand. From a users UX/UI perspective on the otherhand it makes little difference and remains fairly simple.
“To transition coins from the canonical side into the EB, it must be pegged-in. Coins on the canonical side are sent to a specially marked anyone-can-spend address. This results in the redemption of the equivalent amount of MW coins inside the EB. Once inside, MW transactions can occur. Coins in the EB can also be pegged-out back to the canonical blockchain and will be sent out of this special address. This special address will hold all the coins that represents coins on the extension chain.”
As the parent Litecoin is stored in a special anyone can spend address it is critical a majority of the network is onboard with this change hence the 75% mining consensus, otherwise it could lead to potential chain splits, theft of EB coins or the minting of new coins as older nodes will be unable to see the new EB chain but still accept its activity as valid.
LIP 3 is the one that deals with the actual MW proposal and the teams motivation behind it.
“Due to the nature of a transparent ledger, transaction history can be publicly traced. This hinders Litecoin’s fungibility in several ways. Personal identifiable information collected from IP address, exchanges, or merchants can be leaked then tied to your addresses. Also services, such as chain analysis, provide risk-scores based on whether or not any addresses that they have blacklisted appear in its transactional history. This results in some businesses treating these coins as “tainted” and then sending them back to the owner, or worse yet, shutting down their account. This hinders Litecoin’s functional fungibility in a government regulated merchant world.”
“we concluded that MW was the ideal protocol to implement for private transactions. Not only does it hide the amount being sent, the transactional history is deleted from the ledger. This increases privacy by removing linked transactions as well as mitigating the growth in the size of the blockchain.”
MW will offer pseudo privacy as before this history gets deleted those monitoring the network will be able to store the chain state, meaning even if values are hidden it is still possible to track user activity and interactions, so while yes, this will help with fungibility it is by no means perfect.
The team have also prepared a contingency plan if the MW privacy commitment scheme is later broken by quantum computing. By adding a switch commitment for Elgamal it allows the network to switch to a more secure solution and drop the hidden transaction values if there is any fear they are insecure or that an attacker is secretly minting new coins into existence.
Now that the Full LIP details are public it is up to the community and other Litecoin Developers to review and offer feedback before coding begins and resources are committed to working on the implementation further.
