Gambit Network: Introduction
Introduction
Since Bitcoin, which was the first implementation of the idea of a peer to peer electronic cash system proposed by Satoshi Nakamoto back in 2008, the field of crypto currencies and blockchain based systems has exploded producing thousands of different projects, technologies and research papers. Today one can find such projects ranging from distributed computing to Enterprise solutions and applied to all fields from medicine to automotive industries. However, the basic need for people to store their money and transact in a secure way without relying on a centralized authority is still the main use case and the most important, which is one of the reasons why Bitcoin is still the top cryptocurrency and is as influential today as it was almost ten years ago. In Bitcoin, as in most crypto currencies since, your balance is represented by a series of transactions which can be traced back to the very beginning of a blockchain. In order to trust the system we need to make sure that each transaction in the chain is valid, and to do so without relying on a centralized entity, which is the main purpose of Bitcoin nodes and miners. All participants in the system must agree, or using more professional terms “reach consensus”, on an official version of the transaction history and be able to do so without trusting each other or anyone else. The ability of the system to do so is the true strength of the Bitcoin idea.
Failure of Anonymity and The Need for Confidentiality
Initially, transactions in the Bitcoin network were believed to be anonymous. By generating random private and public key pairs, and using the public part to form an address that could be used to receive and control transactions, many Bitcoin users assumed that nothing in that process could link to their real identity. They turned out to be wrong. Using blockchain analysis, research has shown that there are always data leaks. These can come from exchanges, merchants, OTC deals or even by collecting and clustering the blockchain data. It is then possible to deanonymize users, and since all data, including transaction amounts, is open and permanently stored in a public ledger, once users identity is known all their transactions past and future as well as their balance, become directly linked to them as a person. This situation is far from ideal. Both individuals and organizations would prefer that their transactions and balance remain confidential and could only be seen only by parties specifically authorized by them to do so. This would require limiting the visibility of transaction details, including transferred amounts and identities of the participants and keeping as little information as possible about the transactions in the public record to prevent future analysis and a potential disclosure.
Introducing Mimblewimble
In August 2016 a new protocol was published by an anonymous author, suggesting an elegant approach to the topic of efficient confidential blockchain. It is called Mimblewimble3, a reference to a spell from Harry Potter books, and it builds upon two concepts originally proposed by Greg Maxwell, namely Confidential Transactions and Transaction Cut — Through. The following is a high level explanation of the key principles of Mimblewimble. For more detailed explanation please read the original whitepaper. Confidential transactions are implemented by using cryptographic commitment scheme which has two basic properties: hiding and binding. It is similar to giving someone a closed safe box with some message inside that only you know the combination for. When the time comes you can reveal the key and the person can make sure that your commitment is valid (binding) while he can not know what is was before the key is received (hiding) . Mimblewimble utilizes a well known commitment scheme called Pedersen Commitment that achieves this using Elliptic Curve Cryptography and is of the form
C = r * G + v * H
Where r is a blinding factor, a secret key hiding the real value v and G and H are generator point on a specific elliptic curve.
Each input and output of a transaction is thus a linear combination of two factors: an actual value of the transaction and a blinding factor. In order to transfer ownership of a UTXO (Unspent Transaction Output) a sender needs to reveal its value and blinding factor to the receiver, which in turn needs to create a new output commitment using a different blinding factor, known only to him. Due to the linearity property of Pedersen Commitments, if we have two identical transactions: from A to B, and then from B to C, we can cut through the intermediate transaction, resulting in a merged transaction from A to C, which is a valid transaction in the system.
Since block is just a list of transactions, each with its list of inputs and outputs, a block can be seen as one large transaction as well, allowing us to “cut through” i.e merge all intermediate outputs both within a single block as well as across multiple blocks in the blockchain. Extending this approach to the entire chain, we get a system that only needs to store the current UTXO state, instead of entire transaction history. Validity of the history that brought us to this state can be confirmed by storing only the headers of the previous blocks which hold the proof of validity of previous states (using a structure called a Merkle tree) and Proof of Stake that allows to reach consensus on which of the header chains should be considered the correct one (in case of blockchain branching).
Since all that is needed to prove ownership of the UTXO is the value and the unique blinding factor, there is no need to store any addresses in the blockchain. After creating the transaction between two wallets, either online or using any other secure mechanism, only the commitment is recorded in the blockchain. This means that no matter the resources of the attacker, no personal information can be extracted from the blockchain.
In addition to Inputs, Outputs, Proofs and fees, each Mimblewimble transaction includes, the transaction kernel, which in its most basic form contains the difference between blinding factors of sender and receiver. Each transaction should also contain a non interactive zero knowledge range proof to ensure that transaction value is positive without revealing the actual value. It is important since allowing the user to create transactions with negative value would result in ability to arbitrarily create new coins which should be prohibited by the system. For this purpose we use Bulletproofs, a compact and highly computation efficient implementation of zero knowledge range proofs that are attached to every transaction and checked by the system during transaction validation.
Lelantus-MW
Mimblewimble achieves a limited amount of privacy by merging transactions
from the same block, effectively pulling together all transactions that were
submitted to the same block. This helps to achieve significant privacy improvements when compared with e.g. Bitcoin in which transactions are individually traceable and tumbling requires the use of a separate service. However, the degree of privacy that is offered is limited. While large blocks
offer better tumbling, the user has little way of ensuring that.
Lelantus uses a logarithmic-size proof of membership to effectively process merging across different blocks. This may be thought of as a large common
pool of value to which individuals can make deposits and withdrawals in private.
In next article we will explain how to implement this construction into Mimblewimble, while at the same time simplifying the protocol.
We will also describe how we can use Bulletproof protocol to
enable offline payments. With this functionality
in place, senders can send funds without needing to interact with recipients, as the recipients are able to extract the necessary information on their own.
