Topic: Bitcoin and MimbleWimble (Read 814 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.

In your own opinion, would offchain layers be the best path forward for Bitcoin? The Core developers won't increase blockchain size cap because it would lead to blockchain bloat, centralizing the network, and weaken its ability to survive against an adversarial environment. But it's a tradeoff at the cost of wider adoption, and growth.

To make any change mandatory, you would need to at least make old transactions non-standard (not invalid, because you need a way to move old coins, close old channels and clean up the whole mess with some help from miners). Then, if making a private transaction would be standard and everything else would be non-standard, you would reach your "privacy by default".

But if you don't want to force users, then sidechains/federations/LN-like-channels is the way to go, where only some users will have that privacy. You cannot force everyone, because for example you cannot force everyone to use CryptoNote today (so, the set of anonymity is still limited by the number of altcoin users, no matter how good that altcoin is).

I know little from this topic, but I want to say my two sats' worth opinion.

If the change isn't mandatory, it won't reach a CryptoNote alt in terms of privacy. Privacy isn't protected solely from your activity; others must adopt it too. The more they do, the better the privacy for all. Monero achieves great privacy, because everyone's forced to use it in a private way. On the other hand, in Bitcoin there'll always be lots of careless users who'll end up harm the rest's privacy if not only theirs.

New quote from mailing list that can confirm that things like MimbleWimble are possible: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020072.html
And because MimbleWimble is "redefining checksig to allow spending by Pedersen Commitment", it is also applicable here. For example: every time you spend by script, you push some public key and some script. That can contain new opcode "OP_CHECK_PEDERSEN_COMMITMENT" and require a valid signature to meet that commitment, dependent on pushed keys.

If there are still some doubts, then you can ask someone from that mailing list directly about MimbleWimble in Taproot, but I think you will get similar answer.

Edit: Also, if it will be placed in SIGHASH, it will be even more straightforward. Instead of using SIGHASH_ALL, you could use SIGHASH_PEDERSEN_COMMITMENT|SIGHASH_ALL.

Mimblewimble has been the targeted privacy protocol since it was brought to the community's attention back in 2013.  I can't even imagine the amount of work that has gone into it since that time.  Other coins have taken advantage of this technology in the past with success, so I think it could be a huge step forward for Bitcoin progress and maybe even the biggest update we've had in 5 years as far as increasing value of the network.  I'm excited about this advancement and have been waiting for it for quite some time.  In 2016 it became clear that this was coming, but I'm always shocked at the amount of work that goes into these sorts of things before Bitcoin assimilates the tech. 

Actually, you can. Without consensus changes, you have a federation, so that only some people can mine. After implementing Drivechain BIP's, you can have any chain, including regular Proof of Work chains (with merged mining they are stronger than ever).

That's quite simple, any sidechain can have any rules, so you don't have to use 1:1 peg. You can use 1:1000 peg, you can change proportions in any possible way. Also you can have things like premine, because why not. Also, if you want to have a federation, you can do literally everything, because from the mainchain point of view, it is just some address shared by all validators that are moving Bitcoins from here to there.

Every sidechain is communicating with the mainchain once per three months (and doing a huge peg-in and peg-out every time). So, you have four travels per year, but for the rest of the time, the sidechain is living its own life. You can have one second per block, because why not. Everything will be consolidated and pushed to the mainchain once per three months, no matter what rules you have on your sidechain.

Also, the most important point is that some coins are federations, so they have validators. That means, they can be pegged into Bitcoin right here, right now. And they are not. Why?

You can't have arbitrary features on side-chains.
Most importantly, you cannot have a change in emission.
E.g. a fair one, like 1 per second forever.

Lightning Network basically update HTLC state on each transaction, so i don't see how it's possible to implement MimbleWimble, RingCT, or zKSNARKS. But it's possible if you implement in on side-chain or on-chain.

Or a Drivechain? https://www.drivechain.info/

Paul Sztorc, the developer, continues his campaign for it. https://twitter.com/Truthcoin

He has a theory that if Drivechain was implemented in Bitcoin, there would be no need for development in altcoins because different Drivechains will have different features, like all the different features in altcoins. I believe he started Drivechain during 2018.

That's not difficult to understand. What I described is exactly the same what you have in Grin, except that coin amounts are known. Just imagine a huge CoinJoin, where you have only public keys as inputs and only public keys as outputs: then you can simplify things just like in Grin. And because we have Taproot, you can always spend by key or spend by script, so you are not limited only by paying to public keys, you can pay to any TapScript.

There are some ongoing discussions on mailing lists, because it seems that enabling some features would also enable Drivechains (and as we know, sidechains can be used to enable any feature, so people are trying to handle this with care, just to not allow something strange by mistake).

Only small part is possible right now, without any consensus changes. But things like MimbleWimble can be reached by a soft-fork (even better: that could be Taproot-based soft-fork). For example, you can form any spendable TapScript and use some unspendable public key. Then, you can send coins to some Taproot address, where nobody can spend them by key, only spending by TapScript is possible.

Exactly. If you have a transaction with single Taproot input and single Taproot output that can handle the whole network of MimbleWimble users, it has the same size, no matter if you have one user or hundreds of users. Also, in this case you always know which input should be used, because it is the same input for all users, it is shared between all of them, the only catch is making a signature in a non-interactive way, just by collecting messages in P2P network and mixing everything into a small, single transaction, moving MimbleWimble sidechain forward, just by producing a valid signature. And only for that reason, a new opcode is needed (it would not be if we would have OP_AMOUNT constraint on destination and a huge MAST tree).

But that can be expressed as a single Taproot address that will handle the whole network of MimbleWimble users.

It is possible now in a signet-sidechain way (also called a federation). The main problem is the centralization of mining in such case. Introducing MimbleWimble on-chain can solve that, because then you no longer need any federation, just because each key of each user is used to form a shared key for the whole network. Basically, MimbleWimble is a huge 1-of-N multisig, where you can move only your coins and detach your key from that network. It is somewhat possible to implement MimbleWimble entirely off-chain right now (based on N-of-N multisig), but then the number of offchain transactions can explode exponentially, that's another reason why we have 2-of-2 multisig in LN (and also another reason why things like SIGHASH_ANYPREVOUT are needed).

So, to sum up: enabling some opcodes that are actively discussed on mailing lists can lead us to the situation where it would be possible to do more things that developers expected.

I'm wondering that as well since i'm only sure small part of it is possible.


It's not a lot if MimbleWimble use RingCT + bulletproof rather than Confidential Transaction (CT). Don't forget MimbleWimble also reduce bloat since it perform batching on all transaction on each block.


That's exactly my concern.

Ser, is it possible to implement one of MimbleWimble, RingCT, or zKSNARKS in an offchain layer to build a version of the Lightning Network that protects privacy? I believe Bitcoiners' freedom to transact will someday be threatened. We might need to be equipped more through software.

Monero's RingCT (and ZCash' zkSNARKs) scale poorly since you never know when outputs are spent, so you have to treat all outputs as your UTXO set.

Can anyone confirm if that's possible, or is it above our qualification/Bitcoin knowledge. Hahaha.

But let's pretend my stupid brain thought it understood all that, and thought it can confirm that all the information is correct, why isn't the network doing it? Because probably a Core developer would disagree?

I don't remember the exact source and I think was reading several reviews and watching videos that showed flaws in their protocol.
It's obvious that adding MimbleWimble or anything else would increase transaction size and that would increase transaction fees a lot.

I agree with that and I think there are much more potential for improving privacy of LightningNetwork than doing it for Bitcoin mainnet, however weird that may sound.
I don't really know who is working on MimbleWimble and I don't even know who to follow 

It depends. If you have pure Pedersen Commitments, just as ECDSA public keys in the above form, "r*G+v*H", then it actually leads to smaller transactions. You have single Taproot address as your output, so it is smaller. You can reveal some amount "v*H", subtract your "r*G", and then it would take the same size, no matter if there is a single person or hundreds of people moving funds from one key to another.

Range proofs are heavy, but we don't need to have it from the start. We can use explicit amounts in satoshis and make it first as a simplified CoinJoin that takes less space, then we can start thinking about hiding amounts if it would be needed (and then some tricks like zero satoshis would probably be needed anyway).

Also, you can take Taproot and Schnorr signatures as an example that it is possible to hide some things and you will have smaller transactions, because if something is "encrypted", there is no need to always "decrypt" everything.

Personally, I always appreciate any privacy improvements in any software. However, in Bitcoin it's tricky, because better privacy through encryption always leads to larger transactions, inherently. Even if you encrypt lots of things, transaction size or amounts already give away information. For complete security, every transaction would hence also need equal size, which is unviable. We already have issues with transactions size and block size.

After all, improved privacy was an essential idea of Bitcoin from the start. Whenever I see people receiving Bitcoin donations and getting their wallets confiscated, it definitely makes me think 'what did we do wrong', to be honest! The blockchain simply creates this dilemma between being easy to decentralize (run with small storage and computing power) but anonymous (need more storage).

For now, LN remains the simplest way to get (and retain) privacy; as both sender and receiver. However I'll follow MimbleWimble development and see where it leads to.

One Taproot address and a new opcode (that can be one of existing OP_SUCCESS opcodes) can solve that. For example: you can choose some H as some public key, where nobody knows the private key. Then, you can create "r*G+v*H" as your Taproot address. You can accumulate inputs by aggregating Taproot public keys. Later, you can spend by script and reveal your "v*H", then your script would be your "r*G". So, your v-value can be your amount in satoshis, and your r-value can be your public key (or even another Taproot address, if it would be possible to make it recursive somehow, we have MAST, so it may be possible).

So, you would send your coins to "r*G+v*H" Taproot address, you would reveal your "v*H", and "r*G" would be inside your TapScript.

Good point, in reality you're screwed up if you create non-standard transaction (unless you're owner of the pool or have connection to one).


But how would soft fork main backward compatibility when RingCT which use multiple input as decoy?

Nonstandard would be enough. In Segwit, you have uncompressed keys as nonstandard and almost nobody uses that.

There is no need for any hard fork. You would have new address type (or new opcodes in TapScript, that would be more likely). Then, when old transaction types would be nonstandard (or even more expensive, that could work as in Segwit), any typical user will vanish in a huge set of users, if there would be more people than in altcoins, it would be good enough, even if some miner could make a transaction in some old style.

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 believe it's currently released, and it's ready for signalling for activation by the miners.


Those other coins' developers are working for Bitcoin ser. The Core Developers will decide what implementations to use for the advancement of the protocol.

Not unless they want to make bitcoin the new monero.

I don't really have knowledge about MimbleWimble protocol but regarding it having flaws I have to say Grin[1] is an altcoin that was built using this protocol and has been running for about 2 years. I don't really see it added to Bitcoin though.

[1] https://github.com/mimblewimble/grin

I don't think we are ever going to see MimbleWimble implementation integrated into Bitcoin, even if it has better privacy than in current Bitcoin blockchain.
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.
That being said, I would love to see something similar that would improve Bitcoin privacy and kill all privacy altcoins, but I think it's not going to happen any time soon.

If we take into consideration that Litecoin was the first blockchain to experiment with and introduce improvements such as the Lightning Network or Segwit, we could see the same thing with MimbleWimble if and when it gets added. It's all just theory and doesn't have to mean anything, but I remember reading opinions of some Bitcoiners who said that Litecoin is nothing more than just a way to test new technologies that will eventually be introduced to Bitcoin if it goes well. And history often repeats itself.   

Here's short version of what i know, CMIIW.

1. There's no MimbleWimble implementation proposal on Bitcoin network[1].
2. Dandelion has some weakness and it's pull request was rejected[2] due to security concern[3]. Dandelion succeed by Dandelion++, but there aren't many serious discussion about implementing it[4].
3. PLTC (which aimed to replace HLTC by using Taproot) is still on early draft[5] and i don't expect it'll be ready in this year.
4. BIP 151[6] which aim to encrypt connection between nodes has been withdrawn and it's implementation on Bitcoin Core has been stopped[7]. It's successor (BIP 324) still in WIP[8].

[1] https://bitcoin.stackexchange.com/a/112302
[2] https://github.com/bitcoin/bitcoin/pull/13947#issuecomment-513858189
[3] https://bitcoin.stackexchange.com/a/81504
[4] https://github.com/bitcoin/bitcoin/issues/20203
[5] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003377.html
[6] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
[7] https://github.com/bitcoin/bitcoin/pull/14032#issuecomment-901069838
[8] https://github.com/bitcoin/bips/pull/1024

I recently came across an article about Litecoin implementing MimbleWimble which I believe was planned for BTC for a couple of years now.

So I'm curious, do you guys have any information about when to expect this upgrade and whether there are some other (maybe better) privacy protocols on the work?

And for those who are unfamiliar with MimbleWimble: