Audit of the MimbleWimble Integration Inside Litecoin

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

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.