# Litecoin MWEB Audit Report ## Summary of MWEB MimbleWimble Extension Blocks (MWEB) is a sidechain running on the Litecoin (LTC) network. The Extension Block scheme (LIP-0002) allows for the creation of a sidechain whose blocks are produced alongside the canonical chain of LTC. MWEB (LIP-0003) is an implementation of LIP-0002 with the sidechain running MimbleWimble(MW). Funds can be moved from the canonical LTC chain to the MWEB chain through a Peg-In operation and they can be moved back via Peg-out. Funds from the LTC chain are kept in an Anyone-can-spend UTXO, this is done so that the total emission of the LTC stays constant and not reliant on the activity of the MWEB chain, as well as allowing miners to keep the balance correct as users Peg-In and Peg-Out. Peg-In transactions pay into this UTXO while Peg-Out transactions are paid out of this UTXO. Peg-In and Peg-Out transactions are combined with the Anyone-can-spend UTXO to form a single aggregated transaction called the: Integrating Transaction (HogEx). When a miner mines a LTC block, they will perform the usual process that is required from a miner for LTC. However, with the MWEB upgrade the miners will also have to construct a MWEB block. This block is not mined as the normal LTC block is, but this block is committed to inside of the HogEx. The miner claims all fees from the MWEB chain as part of his fees for mining the block. The fees the miner claims from the MWEB extension block are lumped on to the HogEx transaction as fees and claimed as normal. It is important to note that fees paid are effectively pegged out of the MWEB chain immediately and thus removed from the MWEB total supply. When a user Pegs-Out the funds are paid of the HogEx UTXO on the LTC chain, but on the MWEB side the UTXO that is pegging out is discarded and those funds are are removed from the total MWEB supply. ### Peg-In The Peg-in process consists of the following steps: 1. A wallet spends LTC funds to a newly defined type of Anyone-Can-Spend bech32 address which contains the kernel excess of the coinbase transaction (MW output + kernel) that will be included in the MWEB block to represent the creation of these funds on the MWEB chain. 2. The Miner will collect all these Peg-in transactions in the LTC block and the previous HogEx UTXO and combine them into a HogEx transaction containing a single new HogEx UTXO which will contain the total amount of funds currently contained in the MWEB chain. 3. The Miner will also include the fees from the MWEB block and spend them from the previous HogEx UTXO as fees to the miner and thus reduce the HogEx UTXO by the fee amount. 4. The Miner will commit via merkle roots, the MWEB block inside of the HogEx UTXO. ### Peg-Out The Peg-out process consists of the following steps: 1. A wallet will spend a UTXO it wants to Peg-Out to a new Peg-Out UTXO with a special kernel containing all the extra Peg-Out information. 2. A miner will collect all of these, remove them from the supply of the MWEB chain 3. For all these Peg-Out transactions a miner will spend the same amount from the HogEx UTXO to new Outputs defined in the kernel of the Peg-Out transactions. 4. The outputs created by the Peg_Out will be time-locked by the Miner for 6 blocks. ### One sided MWEB introduces the ability to do one-sided payments between peers on the MWEB chain but unlike vanilla MW, this can be done non interactively. To allow this MWEB introduces some extra fields to the vanilla MW inputs and outputs. #### Inputs 1. Input signature: This is signed with the receiver private key of the input, and sign the message: "MWEB" #### Outputs 1. Sender public key: This is a public key that is used in the verification of the owner offset with this transaction. 2. Receiver public key: This is used in the verification of the owner offset when this output is spent. 3. Encrypted data: Contains the value and the blinding factor of the UTXO and is encrypted using a Diffie-Hellman shared secret. 4. Sender signature: This is signed by the sender public key and signs all the metadata contained in side of the output. ## Example of Transaction ### Peg-In Alice creates her MW coinbase transaction with the funds to be created in MWEB. This only has an output (\\(v \cdot H + k \cdot G\\)) and a kernel signing that output as if this was a coinbase. Alice then proceeds to create a normal LTC transaction to spend the funds she wants to transfer to MWEB, to the Anyone-can-Spend bech32 address. But Alice encodes her kernel excess inside of the LTC transaction. Alice submits this LTC transactions with her MW output and MW kernel to be mined. When a miner mines a block he will construct the MWEB block, including in it Alice's output and kernel. He will also include all normal MWEB transactions in the block. The miner will then include all traditional LTC transactions into the LTC block. The miner will also construct the HogEx transaction for the block. This HogEx transaction will spend the previous HogEx UTXO, creating a new one and including Alice's output from her LTC transaction, effectively creating a zero-confirmation transaction to spend to the HogEx address. This HogEx UTXO will include with the MWEB block's header information. After mining the miner will transmit the mined block. Every node who receives the block will be able to verify the following: * Verify all standard LTC block rules. * For each LTC transaction to the new bech32 Anyone-can-Spend outputs in the block, there exists a matching kernel in the MWEB. * Verify all standard MW rules + LIP-0004 rules. * Verify that the emission of the MWEB block is exactly the same amount as the total new bech32 Anyone-can-Spend outputs. ### Peg-Out Alice creates a MW transaction containing one of her outputs, spending it to a new output. But this transaction has a special kernel including a LTC address, amount and Peg-Out flag. When a miner mines a block, he will construct the MWEB block and collect all the Peg-Out kernels, and create LTC transactions spending from the previous HogEx UTXO to the LTC addresses with the amount specified in the kernels. These LTC transactions will be spending the HogEx UTXO for the funds. He will then construct the LTC block with the extra transactions and update the MWEB block details. After mining the miner will transmit the mined block. Every node who recieves the block will be able to verify the following: * Verify all standard LTC block rules. * Verify all standard MW rules + LIP-0004 rules. * For every Peg-Out kernel, verify that a matching LTC transaction is created with the correct to address and amount with the correct timelock. * Verify that the emission of the MWEB block reduced by the exact same the Peg-Out transactions. ### One sided Alice wants to send Bob some funds but Bob's wallet is offline. We assume that Alice knows Bob's public key. Alice creates a full normal transactions as if spending the transaction to herself. She calculates a new private key using Diffie-Hellman to be the shared secret key. She uses the shared secret to encrypt the blinding factor and the value of the transaction. On the output she attaches the following information: * Sender public key(\\(K_{So}\\)) - a newly selected public key for this transaction, only known Alice knows the private key. * Receiver public key(\\(K_{Ro}\\)) - The public key obtained from Bob. Only Bob knows the private key. * Signature - This is a signature created by Alice using her sender private key (\\(k_{So}\\)). * Encrypted data - Using the shared secret she encrypts the blinding factor and value of the output here. On the input's she spends, she attaches the following information: * Signature - this is a signature signing the message "MWEB" proving Alice knows the receever public key of the input(\\(K_{Ri}\\)). Then Alice also calculates the owner offset of the transaction as: $$ \begin{aligned} \text{Owner_offset} = k_{So} - k_{Ri} \end{aligned} \tag{1} $$ This can be verified by: $$ \begin{aligned} K_{So} - K_{Ri} = \text{Owner_offset} \cdot G \end{aligned} \tag{2} $$ This is published with the transaction. Every node who receives the transaction can verify the following: * Verify all standard MW transaction balance and rules. * Verify that the owner_offset is correct by verifying that equation (2) holds. * Verify the signatures on the input and output. ## Open Questions 1. How are replay attacks handled? 2. Replace encrypted data with Bulletproof rewinding? 3. Rangeproof missing?