The reliability of application of Mimble-Wimble on LBTC
By: LBTC (Lightning Bitcoin) Developer
The recent Mimble-Wimble protocol has sparked a wave in the blockchain and cryptocurrency space, and people are discussing new projects (such as Grin) and existing projects that may apply the protocol (such as LTC).
Today, a developer from the LBTC core developer team want to share with the community about how to explain the Mimble-Wimble protocol in a simple way and discuss whether it is possible for LBTC to adopt the protocol. This article will focus on the technical principles, but also try to maintain a language style that is easy for everyone to understand.
Before talking about Mimble-Wimble protocol, it’s quite necessary to mention bitcoin’s UTXO Model and understand why this matters in our discussion.
As is well known, bitcoin adopts a special transaction topology called UTXO, which is short for Unspent Transaction Output. Haven’t heard about UTXO? Sorry I’d say this article is not for you. UTXO is an extremely foundational concept in the space of blockchain, and you really have to understand UTXO before you could get a better idea about bitcoin and LBTC.
The UTXO Model is highly different from the more traditional (and also more intuitive and easier to understand) Account/Balance Model. In bitcoin, every transaction refers to one or more UTXO(s) from previous transactions, which acts as the input of the current transaction. That being said, the input of the current transaction refers to the unspent outputs from the previous ones, and the unspent output of the current transaction is ‘available to be referred’ by the following transactions’ inputs, if there is any. In this way, these UTXOs are processed continuously and build stable links between logically connected transactions in the bitcoin data topology.
What if we wanna add some privacy features in the bitcoin protocol? Take a look at UTXO Model and look for some entry points to this problem:
1) Conceal addresses from tx input?
2) Conceal addresses from tx output?
3) Conceal the transaction amount of bitcoin?
This is the point I wish to emphasize: LBTC adopts a UTXO Model, which is exactly the same as the bitcoin’s (and of course, litecoin’s) UTXO Model. What’s different is that LBTC innovatively combines UTXO Model with a much more efficient dPoS consensus mechanics. When we talk about how we can add some privacy features on BTC and LTC, it’s worth to notice that it also holds true for LBTC.
2.1 What is MimbleWimble?
Simply put, Mimble-Wimble is a blockchain consensus that provides excellent privacy but still keep its scalability at an acceptable level. Mimble-Wimble protocol is a robust solution, based on its special cryptographic design. Generally, the protocol shows some very good privacy features because it re-defines its transaction format, block structure and adopts specific encryption algorithms that conceal the complete information from the on-chain data.
2.2 A Brief Encryption Analogy
A typical Mimble-Wimble (MW) transaction also adopts a UTXO Model, yet varies from the bitcoin model in its specially designed input/output format.
In the bitcoin UTXO Model, inputs are displayed and put together converting into a single output:
Thus, we have I1+I2=O1.
However, in MW’s UTXO Model, the inputs and outputs will be both processed by ECC (Elliptic Curve Cryptography). Thanks to the commutative law of multiplication of the ECC algorithm, technically we could have the input/output logic stay unchanged and intact even they are both encrypted by ECC:
I1 * H + I2 * H = O1 * H
H stands for ECC processes.
What a nice feature! In this way the ECC algorithm has successfully concealed the input/output information.
It is known to all that ECC algorithm is extremely safe, being computationally difficult to work out the reverse process in a reasonably finite period of time. In this M-W model, introducing a ‘Confuse Factor’ into the ECC process even strengthens the algorithm.
(ri1 * G + I1 * H) + (ri2 * G + I2 * H) = (ro1 * G + O1 * H)
The Confuse Factor functions like this:
r is the private key of the sender;
G is another ECC curve chosen by the model;
r * G stands for the corresponding public key for the private key r within curve G.
Why the Confuse Factor matters in the whole encryption process? In a typical encryption process, highly predictable inputs for a specific encryption algorithm are very, very vulnerable, especially given that the encryption algorithm is shown public. In this case, an attacker is well able to calculate the encryption outcomes for highly predictable inputs or frequently used contents in bitcoin transactions. This is the well-known ‘Rainbow Table Attack’ in the hacker term.
The next problem is how to verify the transaction without knowing the exact plaintext? Here’s an illustration:
First we have the equation as discussed above:
(ri1 * G + I1 * H) + (ri2 * G + I2 * H) = (ro1 * G + O1 * H)
Given the equation as discussed above:
I1 * H + I2 * H = O1 * H
Then make some simple transformation:
ro1 * G – ri1 * G – ri2 * G = (ro1 – ri1 – ri2) * G ···(1)
A transaction sender should calculate (ro1 – ri1 – ri2) and attach the outcome in the transaction content. This outcome for (ro1 – ri1 – ri2) is called Kernel Excess. When the verifier sees the transaction: If and only if the equation is true, the transaction is valid.
The very special part of this M-W algorithm is that there is no need for ‘Address’ any more. That is because, the sender’s private key act as a confuse factor, and only when the sender sign the kernel excess with his private key in a valid manner, could he ‘spend’ the output from the specific transaction.
We can even ‘merge’ some mutually independent transactions into one. Here’s an example, for the given four transactions 1,2,3,4:
After the merge:
The merge process brings two excellent features for the transaction data structure:
1) the intermediate outputs are totally moved from the transaction data structure, greatly enhancing the privacy of the system.
2) the merge process shrinks the space occupation of the block data package, as a consequence making the sync process in the P2P network faster.
3 LBTC supports Mimble-Wimble
As is discussed, Mimble-Wimble also adopts UTXO Model, which means that BTC, LTC and LBTC are technically capable of implementing the protocol.
Because of the special-designed features of the M-W protocol, several adjustments and re-constructions should be necessary to make it possible to implement the protocol on LBTC.
1) Develop the encryption algorithm of M-W protocol;
2) Adjust the UTXO format so that the LBTC UTXO is compatible with the M-W one;
3) Apply the M-W algorithm in the processs of transaction validation and verification;
4) Adjust the storage scheme for the M-W UTXO data, including historical data and state data;
5) Achieve the transaction generation scheme within M-W protocol, as the transaction generation logic is totally different between the M-W style and traditional style.
3.3 Technical Issues
3.3.1 Semi-Private TX
Semi-Private TX means that the M-W UTXO and the LBTC UTXO transactions co-exist on the blockchain. Obviously, all of the existing transactions on the LBTC blockchain is not private, so there should be a conversion processs that make those transaction private. Key processs: convert txs in plaintext form into the kernel excess.
There is one problem concerning the spectacular Mimble-Wimble algorithm: it is too computationally costly. The reason is simple, the encryption and the corresponding validation processes consume too much computation power.
LBTC adopts UTXO-based dPoS, and produces blocks in a fixed 3s period of time. The current mechanics cannot support the initial scalability under an average performance level if all the txs are based on M-W protocol. The possible solution is that we set a maximum bar for the M-W style txs that one certain LBTC block is able to contain.
3.3.3 Transaction Merge
Transaction merge is meaningful when there are bunches of M-W based transactions in the total pool. For example, in bitcoin, we have to wait 10 minutes to produce a block, thus highly merged transactions would greatly reduce the pressure of processing transactions during the period. LBTC produces blocks every 3 seconds, making it not that valuable to merge transactions as much as we could.
After all, transaction merge is a very good feature that we put it in our watching list.
1) Mimble-Wimble protocol conceals the input/output adderss and the amount of the transaction so that it shows very good and robust privacy feature.
2)Mimble-Wimble protocol is based on UTXO Model. LBTC adopts UTXO Model as well as BTC and LTC, so it is technically possible to add this new feature.
3)There are still some issue we need to talk about in the future, including the conversion from existing txs, efficiency problem and whether we should merge txs to lighten the data package.