Topic: Bitcoin and MimbleWimble (Read 785 times)

The medium article opened fine on my end. You might want to try
1. Open it using different browser.
2. Use VPN/Tor.
3. Read the archived page[1][2]

1st medium article i mentioned and that bitcoin.com news refer to same "research". But 2nd medium article mentioned, it's misleading. However, i don't know if there are any effort to improve Grin privacy since that "research" is published.


MimbleWimble? No.


Yes, that's what i mean

---

[1] https://web.archive.org/web/20220227204423/https://medium.com/dragonfly-research/breaking-mimblewimble-privacy-model-84bcd67bfe52
[2] https://web.archive.org/web/2020*/https://medium.com/grin-mimblewimble/factual-inaccuracies-of-breaking-mimblewimbles-privacy-model-8063371839b9

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.


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.


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

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?

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.

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

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.

Sure, this would be nice, but unfortunately, I think it's a bit of a moot point today because such features are not really used. Hopefully they get more common in the future.

I may be missing some details about Taproot as I have not looked at it. I'll assume you can somehow construct a rangeproof noninteractively (you need to know both v and r to do that).
Given a commitment P = v*H + r*G, if you reveal the public key either by showing the blinding factor r or X = r*G, you end up with the information that is the same as v*H because you gave out the blinding part of the commitment so you can compute v*H = P - X.
From this, you could figure out v with brute-force by trying amount*H and seeing if you arrive at v*H. I don't see how you'd achieve TapScript or any other scripting capabilities in Grin without throwing away the most important feature of MW which is non-interactive cut-through of the whole history.
To retain the same security model/guarantees, you'd have to find a way to express the scripting language such that it supports algebraic cancelling e.g. create_script - spend_script = 0. Similarly how the secret keys get cancelled out. I may be entirely wrong on this though, haven't spent much time thinking in this direction.

It depends. Technically, you could have one new MimbleWimble Taproot address for N people, do Lightning-Network-like transactions off-chain, and then detach your coins if needed, leaving N-1 people still on some shared address. Because if spending by Pedersen Commitment would be possible, you could aggregate inputs, that could change a lot of things. You could know that 100 people are in some channel factory and own collectively 10 BTC, but without being in that group, you could have no idea who owns what on some second layer.

Also, even if you could deanonymize users actively, you could no longer do that passively or historically, because by analyzing the blockchain, you could only see aggregated addresses. Then, by looking at some single Taproot address, you could never be sure if it was a single person owning 1 BTC, was it some channel with two people owning 0.5 BTC each, or maybe there were 10 participants owning something around 0.1 BTC each?

Pedersen Commitments allow non-interactive public key and amount aggregation, that's why they are so important. And because we can always reveal public key for aggregation and spend by TapScript, that could be used to solve limited scripting abilities in Grin.

I believe the CoinJoin (or CoinSwap for that matter) are incredibly powerful ideas, but their effectiveness is severely hurt by the transparency of the amounts. Even if you achieved a MW-like non-interactive coinjoin for Bitcoin, you'd be able to deaggregate the joint transaction by trying amount combination sums of inputs and outputs.

There may be other ways of reducing the information a transaction gives us. This reminds me of something I've been thinking some time ago. Payjoin breaks the input ownership heuristic. There is however also output ownership information available in today's transactions, specifically the sender will always have an
output which will continue its "change output chain". Whether that's a heuristic worth breaking or not, I'm not sure, but I did document one way of potentially doing it here [1]. I had Grin in mind when I described the idea, but I think it's also applicable to Bitcoin. The main idea is to break the change output chain by
making it as short as possible. The sender essentially leaves the change output chain it was creating. This comes at a cost of another transaction and is not comparable to something like a coinjoin/coinswap. I'm not up to date with all the privacy improving attempts that were made and it's extremely likely this (or similar) strategy was already
discussed. In any case, it might be worth thinking about ways of improving privacy from an angle of reducing the sender's chain continuation pattern.

[1] https://gist.github.com/phyro/496286096cee144b7ff775d3f3b08f2f

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.

I believe the "1" ETFbitcoin was talking about is the kind of "1" that requires a hard fork.


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?

It depends which new opcodes will be introduced and which features will be present in next soft-forks. Drivechains can be enabled by mistake, that's why some people are cautious about new opcodes. For example, when thinking about OP_AMOUNT and designing that, you don't expect that some people would try doing "OP_AMOUNT OP_CHECKLOCKTIMEVERIFY", don't you?

On my list, "3" is quite general, because there are many different ideas and I think people's creativeness is potentially unlimited.

Block size increase isn't the only way for 1st option, although it's just matter of time before it's increased. Here's an example, Did you know bitcoin uses 6 different ways to represent integers.


If you include sidechain as 3rd option, there are many Bitcoin sidechain out there. The only problem is lack of adaption because no one bother promote it and lack of user friendly software.


I'll just quote chapter 10 of LN paper.

Such a transparent form of MW was first described in [1].

[1] https://bitcointalksearch.org/topic/m.56034613

We already did "1", twice. Once with SegWit soft-fork that improved on-chain capacity and with the recent Taproot soft-fork that has the potential to slightly improve it further.

"2" can't happen without "1".

"1" is out, unless you can convince the community to go through another "war/debate" again. "3" is sidechains/Drivechains? That's out too, Paul Sztorc has been proposing Drivechain since 2018, but the Core developers find it laughable because it requires the users in a Drivechain to trust the miners not to be dishonest. Paul Sztorc debates they will be honest because it incentivizes them like onchain. I don't know, I am the stupid one, ELI5. "2" is the only option.

You're right that the transparent "MW" may give some scalability improvements, but I don't find it nearly as appealing as the confidential version.


I think a more relevant question is, are users of a system required to opt-in into subsystem features to obtain privacy. Let's define it this way. Does there exist a user in the system which does not have a mask? In the extension block, the answer is yes, many. And yes, Taproot is a similar way to group users into their own anonymity set with a different, more transparent, mask.


I meant L2 and above e.g. can we have a safe shuffling construction on lightning? It's possible these already exist, I'm just not up to date with the research.

I am sure they will be created, because people will try to scale Bitcoin in every possible way, before doing that in the right way. But I don't know, what will be considered "the right way" in the future. I can only guess, design something, write some code, and try to make it real. But this task can take years to do it correctly, and I think it would be some kind of coordinated work of many people, I don't think there will be some single new Satoshi that will just write the solution "in Bitcoin" (in the same way as the old Satoshi wrote that in C++).

After reading more about Taproot, I think it can be better constructed than as a completely separated "extension block". Adding a new SIGHASH seems to be much better solution, as explained in the mailing list.

Only if you implement all of it. But you can just allow transaction joining and cut-through. Hiding coin amounts is a completely different story, I think we could handle that separately, because range proofs are too heavy.

People always have to opt-in. You can create the best altcoin in the world, then still you can hide only between users of that altcoin. It is not much different than hiding for example only between the users of Taproot. Of course you can force people, but then you put users in danger, because they never agreed to Segwit/Taproot/MimbleWimble by using legacy addresses, so they may be exposed to new cryptographical risks and implementation risks.

It is also possible. People can form channels and use homomorphic encryption to create new features off-chain and still make it compatible with on-chain consensus, without touching it.

You mean Layer Zero? Where Bitcoin will be the lower layer protocol than this new layer? I thought about that in decentralized mining, but it is still work in progress. Or is it simply Layer Two and I misunderstood above/below relations between layers?

You're talking about the article "Former Google AI researcher breaks Mimblewimble" that went viral when it was released. Long story short, it didn't show new attacks or break anything, it just goes to show how easy it is to fool people with misleading titles.


This is where Mimblewimble differs from other privacy improving techniques. It achieves better privacy while also reducing the storage requirements. If you're interested in learning how, I tried to give a simple non-technical explanation here [1] which also contains some comparison of some privacy techniques at the bottom.

Regarding Mimblewimble on Bitcoin. I think the main thing the Mimblewimble paper showed is a new (extremely simple and elegant) way of constructing a blockchain based on confidential transactions while also saving on space. I'm a big fan of Mimblewimble, but I'm not convinced adding MW extension block on Bitcoin is a step in the right direction.
You don't end up with a simple design, in fact, you complect it further (implementing MW is a huge update). You also don't get privacy by default because people have to opt-in. While that's not on a per transaction basis, you still have to manually put a mask on your face which makes you suspicious.
I'd much rather see Bitcoin stay transparent and instead try to achieve privacy for its users on L2 in some way. We can add all the complexity we want on layers above the Bitcoin protocol to try to achieve that. As more people get familiar with possible L2 constructions, it's not impossible that someone comes up with a clever way of achieving privacy with off-chain computations.
I think there's benefit in having a strong system with transparent supply around and Bitcoin is perfect for this.

[1] - https://phyro.github.io/what-is-grin/mimblewimble.html

4) Use option 1 - 3 altogether

Well, you have three options:

1) scale on-chain
2) scale off-chain
3) invent another way of scaling things

If #1 is not the way to go for BTC, then your only choice is #2, unless you have some idea for #3.

If MimbleWimble will be present on-chain, then you could use cut-through, so you could increase adoption without increasing block size.