The Litecoin Foundation mandated Quarkslab to audit the implementation of the MimbleWimble protocol in the Litecoin blockchain. This protocol acts as a sidechain in which privacy of the transactions is improved compared to the privacy on the classical chain.
Introduction
Since mid-2016 and the publication of the whitepapers about the MimbleWimble protocol (MW) [1] [2], the interest has grown as it offers a stronger transaction anonymity and a better network scalability. The name is inspired by a Harry Potter tongue-tying curse [3]. There is some literature about MW [4] and its underlying concepts like Scriptless scripts [5], [6]. Two implementations were proposed to make MW practicable in dedicated blockchains: GRiN and Beam.
The Litecoin foundation has decided to integrate such privacy features in Litecoin. However, Litecoin is a UTXO-based blockchain while the MW inner-workings are radically different. MW operations can nonetheless be integrated to a sidechain. Among existing sidechains for Bitcoin-based blockchain we can denote Lightning Network (LN) or Liquid. While LN is designed to scale-up the underlying chain, MWEB (MimbleWimble Extension Block) focuses primarily on privacy purposes.
The sidechain must adopt its own verification steps and the mainchain must verify that transactions to the sidechain are valid. The MWEB project [7] is expected to be deployed in the upcoming months.
The audit of the use of MW inside Litecoin was performed for a total duration of 45 days by two engineers (22.5 days per auditor). As usual, an audit does not prove the code to be bug-free but reflects the understanding and attack scenarios that can be put in practice in the allotted time. The focus was given on the implementation of the LIPs (Litecoin Improvement Proposals) describing the MW transactions validation and the interactions between the two chains. The full report of the assessment can be found here.
A sidechain for Litecoin
Extension Blocks
Instead of modifying Litecoin specifically for MW, the Litecoin foundation proposed in LIP002 [8] a general framework for implementing pegged sidechains [10] that could be activated through the standard BIP009 miner signaling mechanism of Bitcoin [9]. The two-way peg is the mechanism enabling locking coins on one side and releasing them on the other side and vice versa. That process ensure the 1-1 mapping of coins between the two chains.
In this mechanism, UTXOs can be pegged into the sidechain to make them usable on it or pegged-out to leave the sidechain and be released on the canonical chain. Such proposal requires the following two main components:
- an Integrating Transaction (ExtTxn) which is a dedicated transaction in the canonical chain performing peg-in, peg-out transactions with the sidechain. That transaction created by the miner is specifically the last of the block.
- an Extension Address (ExtAddr), an anyone-can-spend bech32 address acting as an interface with the extension block (EB). As such, at each block the address contains exactly the number of coins in the sidechain. Coins are pegged in this address and pegged out from that address. It changes at each block.
An EB update might also define additional consensus rules in order to accept a canonical block and its EB counterpart. These rules can only be more restrictive. In this framework, the miner is in charge of mining the whole set of blocks (canonical and EB). As part of the mining process the miner have to create ExtTxn linking both blocks.
MimbleWimble integration in Litecoin
MWEB (MimbleWimble Extension Block) is the integration of MW in Litecoin using the EB framework proposal. The integration is described in LIP003 [11] and further defines the handling of coins on the sidechain.
MW leverages Confidential Transactions [12] and Bulletproof [13] against Confidential Transactions alone or ZK-STARKs or ZK-SNARKs as it provides the most compact transactions and avoid a trusted setup.
Implemented as an EB, ExtTx are called HogEx for Hogwarts Express transaction, and ExtAddr are called HogAddr for Hogwarts Addresses. The later will use a new version (the version 9) of witness programs. The following schema shows a simplified view of a LTC block and its MW counterpart.
As shown on the figure, a peg-in transaction by a user indicates a commitment as recipient in the MWEB world (recorded in the MWEB block as a kernel). In the HogEx transaction, the miner spends those coins to the new HogAddr. Similarly, coins can be pegged-out by creating a peg-out on the MWEB side which indicates an amount and the LTC address to send coins to. This kernel is materialized on the canonical side as outputs from the previous HogAddr.
Transactions within the MWEB world (MW-to-MW) do not look like traditional Litecoin transactions but follow the same workflow. Indeed they will enter the mempool [14] but will be mined into the MWEB block rather than the LTC block.
More details about the MW Extension Block integration and modifications implied on the Litecoin codebase can be found in Section 4 of the report [15].
Cryptographic components in MW
MW extensively uses Pedersen commitments [16], Schnorr signatures [17] [18] and Bulletproofs [13]. One of the basis operations of all these schemes is based on secp256k1 [19], which allows to reuse parts of the underlying cryptographic library already included in Litecoin. However, these schemes are not (yet) included in the core cryptographic library of Litecoin: the new primitives are included in the secp256k1-zkp directory, close to this implementation. We reviewed in particular some elements of the LIP004 [20] and the API calls through the C++ wrappers in the code.
Also, some modifications were applied to the original MW protocol in order to make it more usable. For example, LIP004 [20] describes a way to make MW non-interactive, which is a way for the sender to build alone the transaction and transmit to the recipients the information, through stealth addresses [21], for spending the coins.
Section 5 of the report [15] contains more information about the review of the MW cryptography inside Litecoin.
Security audit
Auditing blockchains raises specific security concerns but adding sidechain features brings a whole range of new potential issues, e.g., consensus issues or assets amount discrepancies between chains. Thankfully, MWEB is a synchronized sidechain as they both generate a new block in a synchronized manner which reduces the scope of issues that can arise. This notably avoids fork related issues. Assessed security aspects are twofold, the sidechain security issues and the confidentiality aspects of MW implementation. Underlying security properties that should be preserved are the following:
- all consensus rules (policy) already defined in Litecoin must be preserved;
- new consensus rules need to be more restrictive on accepted blocks in order to be accepted through a soft-fork;
- at all times, the sum of pegged-in coins should equal the amount of coins on the sidechain;
- transaction amounts on MW sidechain should remain confidential between emitter and recipient.
As most blockchains, the threat model considers transaction and blocks produced by miners to be untrusted. The full audit report can be found here:
Findings
Multiple low-impact defects have been identified but a more significant security issue has been identified in the block validation process which impacts the consensus. As shown on the figure, well-known Bitcoin Core functions CheckBlock, CheckTransaction, AcceptBlock or ConnectBlock find their counterparts on the sidechain code.
Even if the code to perform the verification is implemented, the CheckBlock function on MW side has not been properly called from the canonical side. It theoretically enables subtle validation issues and consensus issues, allowing the acceptation of corrupted blocks. Thankfully, this issue can trivially be addressed. Issues mentioned in the report have carefully been fixed.
Conclusion
We would like to thank the Litecoin Foundation for making this assessment possible, and David Burkett for his commitment and responsiveness all along the audit.
| [1] | Tom Elvis Jedusor (anonymous), MIMBLEWIMBLE, 19 July 2016. https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt |
| [2] | Andrew Poelstra, Mimblewimble, 6 October 2016. https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf |
| [3] | Harry Potter fandom, Tongue-Tying Curse. https://harrypotter.fandom.com/wiki/Tongue-Tying_Curse |
| [4] | TariLabs, Mimblewimble Implementation. https://tlu.tarilabs.com/learning-paths/mimblewimble |
| [5] | Andrew Poelstra, Mimblewimble and Scriptless Scripts, RWC 2018. https://www.youtube.com/watch?v=ovCBT1gyk9c |
| [6] | TariLabs, Introduction to Scriptless Scripts. https://tlu.tarilabs.com/cryptography/introduction-to-scriptless-scripts |
| [7] | Litecoin Core integration/staging tree. https://github.com/ltc-mweb/litecoin |
| [8] | Andrew Yang, David Burkett and Charlie Lee, Extension Blocks (Consensus layer), 22 October 2019. https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki |
| [9] | Shaolin Fry and Luke Dashjr, Version bits with lock-in by height, 01 February 2017, https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki |
| [10] | Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón and Pieter Wuille, Enabling Blockchain Innovations with Pegged Sidechains, 22 October 2014. https://blockstream.com/sidechains.pdf |
| [11] | Andrew Yang, David Burkett and Charlie Lee, MimbleWimble via Extension Blocks (Consensus layer) 2021. https://github.com/DavidBurkett/lips/blob/master/lip-0003.mediawiki |
| [12] | Greg Maxwell, Confidential Transactions. http://diyhpl.us/wiki/transcripts/gmaxwell-confidential-transactions/ |
| [13] | (1, 2) Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille and Greg Maxwell, Bulletproofs: Short Proofs for Confidential Transactions and More, IEEE S&P 2018. https://crypto.stanford.edu/bulletproofs/ |
| [14] | temporary storage of transactions yet to be included in a block. |
| [15] | (1, 2) Full report of the assessment |
| [16] | Torben Pryds Pedersen, Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing, CRYPTO 1991. https://doi.org/10.1007/3-540-46766-1_9 |
| [17] | Claus-Peter Schnorr, Efficient Signature Generation by Smart Cards, Journal of Cryptology 4(3), pp 161-174. http://www.neven.org/papers/schnorr.pdf |
| [18] | Pieter Wuille, Jonas Nick and Tim Ruffing, Schnorr Signatures for secp256k1, 17 May 2021. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki |
| [19] | Daniel R. L. Brown, SEC 2: Recommended Elliptic Curve Domain Parameters, version 2.0, 27 January 2010. https://www.secg.org/sec2-v2.pdf |
| [20] | (1, 2) David Burkett, One-Sided Transactions in Mimblewimble, 28 December 2020. https://github.com/DavidBurkett/lips/blob/master/lip-0004.mediawiki |
| [21] | Peter Todd, [Bitcoin-development] Stealth Addresses, 6 January 2014. https://www.mail-archive.com/[email protected]/msg03613.html |