Dry goods | How does Mimblewimble guarantee the security of the transaction? What are its disadvantages?

This article introduces all aspects of MW from a technical point of view, dry goods are full, give you a good look~

Summary: This article introduces the implementation of Mimblewimble from the origin, technology application, advantages and disadvantages of Mimblewimble, and you must not miss the technology!

2017 and 2018 are two years of focus on expansion. For the fork and fork project, the term “forking” has become a hot topic. This debate has brought us solutions and told us that we are now The location meets current needs and plans for the future. The focus for the next few years will be on the large-scale application of anonymity and interchangeability.

• Mutual Chain Monthly Report | May Global Struggle Strengthening Illegal Financing Policy in Blockchain
• It’s worse than the explosion! 6/6 market analysis
• Uncovering the next big game of Wu Jihan

In a fast-growing Internet world, privacy has become an important topic of discussion. At present, we believe that the centralization company will protect our privacy, our password is very strong, and hackers are difficult to break. As we enter the new Internet era, everything is connected, and trust and privacy encryption must be the basis of contact. In the future, we are not only exposed to the risks of exposure of photos and credit card numbers, but also the risk of exposure of all data related to you.

To achieve privacy protection in a decentralized and trusted network environment, there are a number of challenges, such as finding a solution with broad applicability to meet the diversity and expansion needs of the ecosystem. At present, the Internet of Things field has begun to study the implementation of different privacy protocols in the network to meet the needs of anonymous transactions of the Internet of Things and the expansion of anonymous smart contracts.

Mimblewimble

Anonymous protocol Mimblewimble, a new implementation similar to elliptic curve cryptography, is the foundation of most encryption technologies.

In August 2016, an anonymous user posted a white paper link on the bitcoin-wizards IRC channel, claiming “enhanced bitcoin anonymity”. A blockchain proposal was then released. The transaction structure used in the proposal is very different from all the transaction architectures in the world. It is extremely elegantly applied to elliptic curve cryptography.

Although the ideas and theories presented in the proposal were established, there is a lack of detailed mathematical theory and safety analysis. After seeing the proposal, Andrew Poelstra, a mathematician and director of Blockstream research, began to analyze the advantages of the agreement, and two months later, he created a detailed white paper [poel16], which outlines the need to create a separate blockchain. Cryptography, basic theorems and protocols.

The agreement proposed by Andrew Poelstra hides the transaction value, eliminates the address, and solves the expansion problem.

Confidential transaction

Suppose you want to hide the amount sent, a method that is both known and fast is: hashing with hashes. Regardless of the input size, you can use hashes to generate a string of random characters of the same length, and you cannot use the output to calculate the input. So we can hash the amount of the transaction and put the hashed value into the transaction.

X = SHA256(amount)

Or 4A44DC15364204A80FE80E9039455CC1608281820FE2B24F1E5233ADE6AF1DD5 = SHA256(10)

But since the hash is ok, you need to calculate the hash of all the amounts before you can get the correct hash. Now let's get rid of this practice. Before hashing the amount, we multiply the amount by the full blind factor. If the blind factor is not published, it is impossible to know the internal hash value.

X = SHA256(blinding factor * amount)

Multiplying the full blind factor yields a value of commit, submits a value, but does not reveal it. If you don't change the promise, the amount will not change.

But how does the node use this promise value to verify the transaction? At least two conditions must be met: one has a full currency, and the other does not create a currency during the verification process. The vast majority of agreements verify transactions by calculating the transaction input (or multiple transaction inputs) and then creating an output that does not exceed the total value of the input. If the input and output are not equal, the currency is created out of thin air.

Input(commit(bf,10), Alice) -> output(commit(bf,9), BOB), outputchange(commit(bf,5), Alice)Orinput(4A44DC15364204A80FE80E9039455CC1608281820FE2B24F1E5233ADE6AF1DD5, Alice) ->output(19581E27DE7CED00FF1CE50B2047E7A567C76B1CBAEBABE5EF03F7C3017BB5B7, Bob) Output(EF2D127DE37B942BAAD06145E54B0C619A1F22327B2EBBCFBEC78F5564AFE39D, Alice)

As shown in the figure above, the last valid hash indicates that Alice created 4 coins and she made a deal to get the 4 coins. In any transaction, the total input must be equal to the total output. We have to use some mathematical methods to verify the hash value:

Commit(bf1,x) = commit(bf2,y1) + commit(bf3,y2)

If the transaction is valid, it will be:

Commit(bf1,x) – commit(bf2+bf3,y1+y2) = commit(bf1-(bf2+bf3),0)

Or only the full blind factor submitted.

It is impossible to prove by means of a hash algorithm. To prove, all blind factors and amounts must be published. If so, it is not anonymous. How do we expose a private value, and we can't reverse the value and still verify that the value is eligible? It sounds a bit like public key and private key cryptography.

Grin uses elliptic cryptography to define the number space, taking a point G of the elliptic curve and multiplying it by any value x to get a rms value P (also a point on the elliptic curve). The calculation results are very fast, but even if we know P and G, we still can't get the multiplier x. We can use P as the public key and x as the private key. Interestingly, these two numbers also have addition and communicative attributes.

If you take the point px•G and add the point qy•G, the resulting point W = P+ Q is equal to the combination of x+y to create a new point. and so:

So the product is also constant.

This homomorphism attribute helps us to operate with unknown numbers.

So instead of using the original amount * full blind factor = promise, we can multiply the amount and the full blind factor by a known point on an elliptic curve, so the promise becomes:

The post-change commitment is called Pedersen Commitment and is the core value of all confidential transactions.

Suppose the full blind factor r, the amount v, takes the H and G on the elliptic curve as the generation point (the Schnorr signatures are not drilled here). Bring these values ​​into the promise:

Use the communicative attribute:

If the transaction is valid, it is equal to:

Use ri, vi as the input value, ro, vo as the output value, Rco, and Vco as the changed output.

The difference obtained by the above formula is the excess blind factor, also known as commitment-to-zero (commitment to 0):

You can observe that in the case of selecting any full blind factor, commit-to-zero is a non-zero number, in fact, it is still a valid point on the elliptic curve (public key),

The private key is equal to the difference of the full blind factor.

Therefore, if the input total value minus the total value of the output, a valid public key can be generated on the elliptic curve, the residual is 0, no new currency is created, and if the difference is not equal to 0:

For some excess blind factors, they are not a valid public key on the elliptic curve, so this is not an equal transaction. To prove this, sign the transaction with this invalid public key, prove the transaction equal amount, all blind factors are known, and do not reveal any transaction-related data during the verification process (see [Arvan19] for the detailed process of signing the transaction).

All of the above formulas assume that the number is positive, and you can also create a valid transaction with a negative number. The user can create a new currency in each transaction. This method is called Range Proof. Each transaction must have a zero-knowledge proof to prove anonymous submission. The value matches the value in the subscription range. Mimblewimble, Monero, used BulletProof, a new way to calculate Range Proof, reducing transactions by 80%-90%.

* The average transaction size in the current network, the average transaction size of MW is 2.5kb for input 2kb output.

The current agreement between Mimblewimble and Monero is almost the same, the difference is the way the transaction is signed.

In Monero, there are two sets of keys/addresses, cost keys and a view key. The cost key is used to generate and sign the transaction, the key is used to "receive" the transaction, the ring signature is derived from the output of the expense, and the transaction is signed, verifying that the cost key belongs to a member of the key group. To verify, a private signature and a set of mixed signature baits from the previous transaction public key are used to merge to create a Schnorr signature. All signature baits are mathematically feasible and cannot be used to determine the true signature. Monero uses Pedersen Commitment to hide the address, but only for claiming transactions, signing transactions and generating full blindness factors.

Mimblewimble does not use any form of address. It is the shining point of the agreement. Jedusor demonstrates that the full blind factor and Pedersen Commit and commit-to-zero can generate a one-time public/private key pair to create and sign a transaction.

All the addresses of the public and private key pairs are generated by elliptic curve cryptography in the same way. Multiplying the G point on the elliptic curve by a large random number (k_priv) yields (K_pub) as another valid point on the curve.

This is the key to all address generation, is it familiar?

The promise we mentioned earlier:

Multiplying each full blind factor by G (red number) is equal to the address! r*G is the public key, r is the private key, so no address is needed, we can use these full blind factors to prove the input and output, and use them to sign the transaction.

This seems to change the linkability of the address, nor does it require scriptsig to verify the validity of the signature, and greatly simplifies the structure of the confidential transaction and reduces the size of the transaction. At the same time, it also means that during the transaction, both parties need to interact to generate a signature.

CoinJoin

Even if all the addresses and amounts are hidden now, some transaction information can still be derived. In the above trading formula, it is clear which outputs are applied and which are out of the transaction. The “transaction map” explains the owner information of the blind factor and the trading activity. To further hide and compress the information, Mimblewimble implemented Greg Maxwell's CoinJoin idea, which was originally developed for Bitcoin. Coinjoin combines the inputs and outputs of multiple transactions into one transaction in a de-trusted way. Mask the sender and receiver. To be implemented on Bitcoin, the user or wallet must interact in order to join the same amount of transactions, so it is not possible to distinguish which party the transaction came from. If you can combine signatures without sharing a private key, you can combine multiple transaction signatures (such as a ring signature) and are no longer subject to the same amount.

In CoinJoin, there are 4 outputs for 3 addresses, and it is impossible to know who is the real output.

In Mimblewimble, calculating one or more transaction amounts will still generate a valid commit-to-zero. What we have to do is merge the transaction and merge the signature. Mimblewimble is naturally adapted to merge signatures with commit-to-zero and Shnorr. With Unidirectional Aggregation Signature (OWAS), a node can combine multiple transactions into one transaction when creating a block. Mimblewimble efficiently converts all transactions in the block into a large transaction (including all inputs and outputs). This also confuses the transaction graph, removes the intermediate transaction calculations consumed when the block is released, reduces the block size, and thus reduces the block size.

Cut-through

Let's go one step further and verify this complete "connected" block. The node adds all the output commitments, subtracts all input commitments, and verifies that the difference is a valid commit-to-zero? In theory, we can merge two blocks, remove all transactions and expenses in both blocks, and become a valid transaction without spending a promise. We use this method to go back to the creation block and reduce the entire block to an unexpended promise. This method is called Cut-through. When using this method, we do not need to retain any rang proof that costs output. These rang proofs have been proven and can be deleted. The number of blocks from 0 (number of transactions) to 0 (number of outputs not consumed) can be greatly reduced.

To explain the advantages of Cut-through, assume that Bitcoin applied Mimblewimble from the beginning, to block 576,000, the blockchain reached 210GB, a total of 41.367 million transactions, and 55.4 million unspent output. Mimblewimble's trading output is about 5kb (including range proof~5kb and Pedersen commit~33 bytes), the transaction input is about 32 bytes, the transaction proof is about 105 bytes (commit-to-zero and signature), and the block header is 250 bytes (Merkel proof and PoW), non-confidential transactions are negligible. Adding all the appeals together, all the information in the sync blockchain is 5.3TB, and only 279GB is the unsuccessful transaction output. When using cut-through, we want to keep all transaction records, so keep all proof of trade, unspent output, and block headers. The block was reduced to 322GB, a reduction of 94%. The result is to retain the unconstrained consensus state and greatly reduce the synchronization time of the new node.

If Bulletproof is implemented, the range proof can be reduced from 5kb to 1kb, and the unspent output is reduced from 279GB to 57GB.

Based on the above assumptions and calculations

The PoS chain also has an interesting hidden meaning with a clear finalism. Once the final result, or any blockchain depth, is confirmed, there is no need to retain the range proof. In a verified transaction, the consensus state has been written to the blockchain, but these transactions still occupy a large amount of memory in the blockchain. If the finality is at the depth of 100 blocks, assuming that 10% of the unspent output has been pre-terminated, the blockchain will be reduced by another 250GB, and the full synchronization will only be 73GB, which is reduced by 98.6%. Imagine this is a 73GB blockchain that contains Bitcoin's anonymous transactions for 10 years, only 1/3 of the current Bitcoin blockchain.

Another point is that cut-throught does not affect anonymity and security. All nodes have the option of storing the entire chain without performing a cut-trought, the only added cost being the purchase of disk storage. Cut-through is purely a capacity expansion feature that reduces the bitcoin blockchain based on Mimblwimble to 1/3 and Monero by 50 times (even if it currently uses Bulletproof).

The inadequacies of Mimblewimble

The revolutionary nature of Mimblewimble also limits it. Almost all protocols, such as Bitcoin, Ethereum, etc., use the basic scripting language to call functions in real transactions, telling the verifier which script to validate. The simplest scenario is that the input calls "scriptSig" to get the transaction signature and public key. The output script checks the verifier for the right to spend the transaction with script signatures, transaction signatures, and public keys. The certifier hashes with the known public key, checks whether the value after the hash is the same as the hash value of the output, and if they are the same, checks whether the transaction signature is consistent with the input signature.

The Bitcoin network can add Mimblewimble, so the Bitcoin protocol can verify multiple signatures, lock transactions within a specified time, and complete some complex implementations. For example, bitcoin is locked in an account until it is unlocked.

In order to achieve the impact of a widely used public intelligence contract like Ethereum, you need to disclose the data or create a proof of proof to prove that you meet the smart contract conditions.

In Mimblewimble, the use of the full blind factor as a key pair greatly simplifies the signature verification process, so the underlying protocol does not need to write a normal script. Recorded on the blockchain is:

· Input used: calculation in old submission

· New output: published new submission

· Trading Core: Contains transaction signatures that exceed the full blind factor, transaction fee, and lock height.

The three are not related to each other and cannot use this value to calculate the other value.

Creatively compensates for the flaws of Mimblewimble through scriptless scripting, enabling multi-signature transactions and more complex transactions, such as cross-chain atomic swaps and even lightning-networked state channels, through Schnoll signatures. But this does not meet the requirements of the IoT smart contract.

The most important point is that implementing cut-through will remove the smart contract or rely on the contract transaction.

As you can see, MImblewimble successfully hides the amount and owner, but only for one-dimensional data points – quantity. And the transfer of things outside the scope of token ownership is beyond its capabilities.

Original | Grayblock

Translation | First Class Warehouse_Tracey

Original: https://medium.com/coinmonks/mimblewimble-in-iot-72cdec6bedec

Source: https://first.vip/shareNews?id=1694&uid=2

We will continue to update Blocking; if you have any questions or suggestions, please contact us!