Can Bitcoin use the MimbleWimble protocol? That's what Pieter Wuille and Charlie Lee say

"Can Bitcoin's privacy benefit from the EB MimbleWimble proposal used by Litecoin?"

Someone asked such a question on the / r / Bitcoin forum today.

45

Note: The MimbleWimble protocol was originally proposed by anonymous cryptographer "Tom Elvis Jedusor" based on technologies such as confidential transaction (CT) and Coin Join. The Litecoin integration of the MimbleWimble protocol was carried out by Grin developer David Burkett. Wright Coin's MW protocol is not directly applied to its main chain, but is completed through Extension Blocks.

About the extended block (EB): The extended block (or auxiliary block) technical solution was originally proposed by Bitcoin developer Johnson Lau in 2013. The extended block (EB) aims to provide effective network Block size and capacity, and deployed by means of soft forks (that is, no network division). This also means that if users don't want to use an extended block (EB), they will not be forced to use it.

Create an extended block (EB) for each block on the blockchain . It looks like an ordinary block, but without a header. The Merkle roots from the extended block (EB) will be included in the coinbase of the main block and connect them together.

Regarding the extended block scheme, its original author described it like this:

"All upgraded nodes will check if Bitcoin is correctly transmitted from the main chain to the auxiliary chain.

One can transfer the auxiliary chain bitcoin as in the main chain, and miners can also use the same mechanism as the main chain to charge fees in the auxiliary chain. The only difference is that no reward is generated in the auxiliary chain.

-Johnson Lau

" But this is not the focus of this article. Pieter Wuille, the maintainer of the Bitcoin core protocol, gave a wonderful answer to this question. He said this:

"It's not that simple.

I personally hope to see the application of confidential transaction (CT) technology to Bitcoin. By default, hiding the transaction amount (instead of a separate privacy silver bullet) will make CoinJoin even more powerful. I think it's fair to say that it may help achieve a level of privacy that is difficult to achieve with existing on-chain technologies.

However, confidential transactions (CT) will fundamentally change the way transactions work, because current transactions are expected to have clear text amounts without a (very aggressive) hard fork, a change that cannot be achieved. Even if they were suddenly allowed, no one could force an existing wallet to adopt them suddenly. Doing so breaks compatibility and violates the fundamental expectation that existing non-broadcast transactions will not be invalidated. Such a successful change may mean that Bitcoin will lose some of its most valuable features. Therefore, confidential transaction (CT) or any form of hidden amount technology must be opt-in, not the default.

But opt-in does not mean that every transaction needs to be selected. The extended block (EB) effectively does this: by having two clearly divided edges and requiring a clear, possibly slow / expensive operation between them, you create a confidential transaction (CT) by default A world that may even be cheaper than the other side. Of course, people can still choose to use the legacy side (or main chain), and for a long time, due to compatibility reasons, they may choose to use the legacy side, but in the long run, this may mean Every transaction using CT will have better privacy.

It turns out that the confidential transaction (CT) applied in the extended block (EB) is much simpler and more efficient than trying to insert it into the existing transaction structure.

Therefore, I believe Extended Block (EB) is the only possible hope for introducing confidential transaction (CT) technology to Bitcoin.

However, there are many questions that need to be asked:

  1. CT transactions are computationally more expensive than current transactions, and much larger than current transactions. It would be very unfortunate if the choice of a private transaction ultimately led to higher usage costs;
  2. CT trading introduces a stronger cryptographic assumption than we have. You can't just run the UTXO set, add these values ​​and see if it exceeds the expected subsidy;
  3. In fact, CT transactions essentially must either set privacy conditions based on cryptographic assumptions, or they must be soundness (ie, print money). Bitcoin currently relies on the ECDLP (Elliptic Curve Discrete Logarithm Problem) hypothesis to defend against theft, but it can be upgraded to another hypothesis (for example because we believe that the foundation of ECDLP is unstable, then quantum computing …). With CT, this is not so easy, because this assumption now also covers the amount;
  4. This is a considerable change, which requires huge demand from the ecosystem to succeed;
  5. All the same problems apply to the MimbleWimble protocol, and even more problems are encountered. MimbleWimble is a more advanced form of CT that has a more intrusive impact on basic data structures and may not be able to be completed without an extended block (EB) at all, as it is compatible with Bitcoin's current blockchain There is a fundamental difference (the MimbleWimble blockchain will shrink over time!) It also removes Script scripts and even removes the ability to have script-like scripts.

Let me return to point (3) above. Zero-knowledge proof technology has a very basic result, that is, you cannot have unconditional privacy and unconditional reliability at the same time, so there is a design trade-off here.

  1. CT with unconditional privacy but computational soundness is the most common choice. This means that if ECDLP is threatened in some way (mathematical breakthrough, accidental structure of secp256k1, or quantum computing), someone may perform unsuspecting additional Coin operations, but privacy of past (and future) transactions Will not be affected. As far as I know, this mode is used by Monero, ZCash and Grin.
  2. CT has unconditional reliability, but computational privacy is also possible. This means that if ECDLP is cracked, it will not allow anyone to conduct additional transactions, but the privacy of future (and past) transactions will be at risk. Unfortunately, this option is much less efficient and few systems use it.

Given that Bitcoin's design focuses on controlling inflation, I expect that if a choice needs to be made, many people will prefer the second model over the first . However, there is one point that needs to be explained. If ECDLP is cracked, the future of the system will inevitably be at risk, but we may not want to give up the privacy of the past when this happens, and this is beneficial to the first model.

The advantage (or terrible thing …) of CT design based on extended blocks is that we can have both, without directly affecting the value of the main chain. You need to explicitly move the coins to the CT side. If unexpected inflation occurs on the CT side, not all coins can be moved back to the main chain.

When this unexpected situation occurs, if the public's security trust on one side is seriously affected, this may actually mean that the exchange rates of the two currencies will be different. In response, Litecoin founder Charlie Lee replied:

"Pieter, do you think of using Switch Commitments (https://eprint.iacr.org/2017/237.pdf) to alleviate this dilemma of perfect binding vs perfect hiding? Apply this scheme Later, basically we are currently at the beginning of perfect concealment and computational binding, and then when quantum computing becomes a reality, we switch to perfect binding and computational concealment. Transactions before conversion will not show their amount, and quantum computers (QC) cannot Increase the total supply of coins after conversion.

This is the solution that Grin is currently implementing, and I think it gives us a good escape hatch and time to come up with a CT commitment scheme that resists quantum computing.

" Translator's comment: As Pieter Wuille said, extending the block (EB) is the only possibility to introduce confidential transaction (CT) technology into Bitcoin, but this possibility is still very small, and the possibility of MimbleWimble applied to Bitcoin Sex is even more trivial, but the most important thing discussed by Pieter Wuille and Charlie Lee this time is the trade-off between privacy and security. In this regard, Bitcoin, Litecoin, and Grin are different.

Reference: https://medium.com/@LitecoinDotCom/litecoin-core-developers-investigating-mimblewimble-and-extension-blocks-technologies-da51077c2174

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

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Blockchain

The pace of competition is accelerating, how can the new exchange break with the finer operations?

The cryptocurrency exchange is still a good business. Recently, the Currency Exchange announced the eighth BNB quarte...

Market

Latest Interview with Zhao Changpeng: Being "Under the Microscope" of Regulation, Market is Recovering in Bearish Period

On May 29th, Binance CEO Changpeng Zhao gave an interview to Bankless discussing his views on the current state of th...

Blockchain

Market Weekly | The market is in a consolidation period, and the exchange has picked up

Weekly summary Last week, the average daily market value of global digital currency assets was 326.973 billion US dol...

Blockchain

Coinbase's effect on the currency is not strong, mainly because the market is at work.

Coinbase is one of the most influential compliance exchanges in the world, providing multiple French currency channel...

Market

Bitcoin stays stable at $30,000, is this a signal of a bull market?

Since 2023, the Bitcoin market has maintained a continuous growth trend, recently rebounding to over $31,000 in the p...

Policy

BlockFi Emerges from Bankruptcy, Ready to Pay Back Creditors and Recover Assets

In November, popular crypto lending platform BlockFi made headlines for their bankruptcy filing caused by the FTX con...