Bitcoin and MimbleWimble

[OgNasty]

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:

Moreover, Mimblewimble combines cryptographic protocols such as Confidential Transactions (CTs), CoinJoin, Dandelion, and Cut-Through to achieve a higher level of security and anonymity. In general, these protocols help conceal transaction information.

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. 

[1714079143]

1714079143

[1714079143]

1714079143

[1714079143]

1714079143

[1714079143]

1714079143

[vjudeu]

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

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

"Redefining checksig to allow X" in taproot means "defining a new pubkey format that allows a new sighash that allows X", which, if it turns out to be necessary/useful, is entirely possible.

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.

[BlackHatCoiner]

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

There is no need for any hard fork. You would have new address type (or new opcodes in TapScript, that would be more likely).

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.

[garlonicon]

If the change isn't mandatory, it won't reach a CryptoNote alt in terms of privacy.

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).

[Wind_FURY]

If the change isn't mandatory, it won't reach a CryptoNote alt in terms of privacy.

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).

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.

[vjudeu]

In your own opinion, would offchain layers be the best path forward for Bitcoin?

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.

But it's a tradeoff at the cost of wider adoption, and growth.

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

[ABCbits]

In your own opinion, would offchain layers be the best path forward for Bitcoin?

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.

4) Use option 1 - 3 altogether

[oryhp]

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.

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.

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).

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

[garlonicon]

In your own opinion, would offchain layers be the best path forward for Bitcoin?

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++).

but I'm not convinced adding MW extension block on Bitcoin is a step in the right direction

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.

implementing MW is a huge update

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.

You also don't get privacy by default because people have to opt-in.

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.

I'd much rather see Bitcoin stay transparent and instead try to achieve privacy for its users on L2 in some way.

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.

We can add all the complexity we want on layers above the Bitcoin protocol to try to achieve that.

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?

[oryhp]

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.

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.

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.

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.

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?

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.

[Wind_FURY]

In your own opinion, would offchain layers be the best path forward for Bitcoin?

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.

4) Use option 1 - 3 altogether

"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.

[pooya87]

"1" is out, unless you can convince the community to go through another "war/debate" again.

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.

I don't know, I am the stupid one, ELI5. "2" is the only option.

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

[tromp]

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.

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

[1] https://bitcointalk.org/index.php?topic=281848.msg56034613#msg56034613

[ABCbits]

"1" is out, unless you can convince the community to go through another "war/debate" again.

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.

"3" is sidechains/Drivechains? That's out too

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.

"2" is the only option.

I'll just quote chapter 10 of LN paper.

If we presume that a decentralized payment network exists and one user will make 3 blockchain transactions per year on average, Bitcoin will be able 52 to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions/MB, or 500 bytes/Tx). This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin. A simple increase of the block size would be a hard fork, meaning all nodes will need to update their wallets if they wish to participate in the network with the larger blocks.
While it may appear as though this system will mitigate the block size increases in the short term, if it achieves global scale, it will necessitate a block size increase in the long term. Creating a credible tool to help prevent blockchain spam designed to encourage transactions to timeout becomes imperative.

[vjudeu]

"3" is sidechains/Drivechains? That's out too

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.

[Wind_FURY]

"1" is out, unless you can convince the community to go through another "war/debate" again.

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.

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

I don't know, I am the stupid one, ELI5. "2" is the only option.

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

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?

[pooya87]

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.

[oryhp]

I found this blog post[1] which discuss SNICKER (CoinJoin modification) which doesn't need coordinator. There are few different specification version[2], but each version have awkward trade-off.

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

[garlonicon]

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.

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.

[oryhp]

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

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.

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 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.