Bitcoin and MimbleWimble

[garlonicon]

I'll assume you can somehow construct a rangeproof noninteractively

I thought about MimbleWimble without range proof, where all amounts are known.

Given a commitment P = v*H + r*G

You have Taproot address as "P", it is just some public key. You know "H", because it is some public key, where nobody knows the private key. You also know "v", because you know the amount of coins assigned to some Taproot address. You spend by TapScript, so you reveal "v*H". Then, your "r*G" is inside your TapScript. So, in the current design, you are "almost there".

If all people would want to withdraw their coins, then they need to reveal "v*H" and "spend by Taproot" that could satisfy "r". If someone would want to take only some coins, then that person would take w-coins by pushing "w*H" and satisfying "spend by Taproot" for "q*G", leaving "v-w" coins on "(v-w)*H+(r-q)*G". You would then never know if one person left with "w" coins, or maybe there were five people joining their Schnorr signatures? Also imagine interactions between many Taproot addresses, you could have two Taproot addresses as inputs and two as outputs. You would never know, how many people were inside each address, also people could store different amounts on different keys, so one person could use 10 keys with 10 different amounts and spend all of them, some of them, or just one of them.

[Wind_FURY]

I believe it actually can, if there's a minimal need to settle onchain/the offchain layer becomes a "regular" network on its own, and with the units of Bitcoin from that offchain network is accepted everywhere. What would be the purpose of the Lightning Network if users open then close their channels after a transaction?

Well, the idea is that we are going to have more adoption which means more people opening channels which means more on-chain transactions on its own. So the main chain has to be able to handle the increased number of transactions too. Besides not all transactions happen on LN, there is always going to be on-chain transactions, which will continue to go up with adoption.

But Lightning adoption can't be if I simply set up a Lightning wallet through BlueWallet, and a Lightning user can send the Bitcoins in my invoice like a simple onchain transaction? I believe that should be the way, after OG users have boot-strapped the network altruistically. Exchanges should start adopting it too by allowing any user to withdraw Bitcoin through Lightning.

[Shymaa-Arafat]

I remember someone found a flaw in this protocol so it never gained much popularity with Bitcoin developers, and I don't consider Litecoin devs serious according to their very low github activity.

Are you referring to misleading article which claim Grin MimbleWimble is broken[1]? While some of details is true, it's misleading article[2][3].

Even with MimbleWimble, Bitcoin can't beat Monero in terms of privacy. Bitcoin would need to implement additional technology such as Ring Confidential Transaction (RingCT) with Bulletproof or zkSNACKs and make it mandatory. But since it require hard fork and massively increase transaction size, i doubt anyone would support it.

[1] https://medium.com/dragonfly-research/breaking-mimblewimble-privacy-model-84bcd67bfe52
[2] https://medium.com/grin-mimblewimble/factual-inaccuracies-of-breaking-mimblewimbles-privacy-model-8063371839b9
[3] https://github.com/mimblewimble/docs/wiki/Grin-Privacy-Primer

I can't open the medium article u r referring too, doesn't upload don't know why, but for me that's where I read about an 2019 flaw on mimblewimble:
https://news.bitcoin.com/researcher-breaks-mimblewimble-deanonymizing-96-of-grin-transactions/

Maybe they fixed it later in a modified version, I didn't follow up.
By the way, is it implemented in Monero?or u just referring to it as the privacy first priority cryptocurrency?

[oryhp]

I thought about MimbleWimble without range proof, where all amounts are known.

Oops, I misunderstood which one we're talking about. I'd have to think more about the transparent version and check Taproot to have an opinion on that.

Maybe they fixed it later in a modified version, I didn't follow up.

This was never addressed on the protocol level at Grin, I'd say mostly because there was no change proposed that would be considered a good tradeoff.

Regarding the "breaking" of Mimblewimble and the supposedly necessary "fix", I think it's important to describe things accurately.

There are 3 main privacy vectors: amounts, addresses and the transaction graph. Mimblewimble solves the first two and doesn't address the transaction graph leak much - the fact
that the whole block is just a header and a single transaction doesn't help much if people can observe deaggregated transactions in the mempool.
However, it comes with two great tools that can help immensely namely noninteractive coinjoin and transaction cut-through. It's rather obvious how Coinjoin helps with privacy,
but the cut-through can also be used for that purpose because it makes some transaction information disappear. A great example of how to combine these two properties to
achieve some interesting mixing service is the Mimblewimble CoinSwap proposal [1]. Given that Mimblewimble is a design and does not address the transaction graph on its own,
I'd argue there's nothing to "fix" here. It's simply how it works. There could be other similar designs that do a better obfuscation of the transaction graph on the protocol level,
but the Mimblewimble as described does not and it never did. Developers have been transparent/honest about it which is why the linked article doesn't "break" Mimblewimble.
I think the author misunderstood what Mimblewimble is and what it is not.

By the way, is it implemented in Monero?

They use the same technology to blind the amounts (CT), but apart from that are quite different.
Mimblewimble is CT + No addresses + Non-interactive coinjoin + Non-interactive cut-through of the whole transaction graph (scalability) + multi-sig only transactions.
Monero is CT+ Stealth addresses + Ringsigs (decoys on the input side of the transaction).

If you're interested to learn more how the two differ, there's this table available [2].

[1] https://lists.launchpad.net/mimblewimble/msg00637.html
[2] https://phyro.github.io/grinvestigation/why_grin.html