<p>It's hard to make predictions about the future, but as of today, nobody has proposed adopting a similar MimbleWimble Extension Block in Bitcoin. Given the skepticism that previous extension block proposals were received with, I would be surprised if such a proposal got significant traction on Bitcoin.</p>
<hr />
<p>The way I understand the proposal, the MimbleWimble Extension Block (MWEB) is coupled to the on-chain transaction body via a pegging mechanism. Funds can be moved into the MWEB by paying a special on-chain address and withdrawn from the MWEB by effecting a payment from that address.</p>
<p>Inside the extension block, transactions are created via the MimbleWimble protocol. MimbleWimble transactions must be crafted interactively involving both the sender and receiver, but making use Pedersen commitments the values of inputs and outputs are hidden to anyone but the parties crafting the transaction. Immediately after construction, transaction inputs and outputs form a similar graph structure as on-chain Bitcoin transactions. However, the minimal MimbleWimble transactions are especially designed to allow for transaction cut-through: transactions can be aggregated non-interactively facilitated by some Elliptic Curve magic and due to Pedersen Commitments being homomorphic, which prunes any intermediate outputs that already got spent in the aggregate. (E.g. if there are two transactions (A1⇒B1+A2) and (A2⇒C1+A3) they could get aggregated to (A1⇒B1+C1+A3) pruning the creation and spending of output A2.) As MimbleWimble transactions can be aggregated even across blocks, the chainstate reduces to a remaining <em>kernel</em> per transaction, the peg-in inputs and the currently spendable outputs. On the downside, MimbleWimble transactions are very limited in their scripting capabilities.</p>
<p>In result, an attacker can learn more about the transaction graph by actively monitoring the transaction relay, but a passive monitor catching up later would effectively only see a huge coinjoin that is the aggregate effect of all previous transactions with hidden amounts.</p>
<hr />
<p>I only skimmed the MWEB proposal to brush up on details. I suggest verifying any information in this post if you have more than a passing interest.</p>

CC BY-SA 4.0
2022-02-07T21:57:21.163Z
2022-02-07T22:12:02.447Z
2022-02-07T22:12:02.447Z
Murch
<p>Whether Bitcoin would implement Mimblewimble can only be speculation at this moment, there are no proposals to do it.</p>
<p>Maybe the &quot;extension blocks&quot; part has a chance, just because there are no other options to increase block size limit as a soft fork, and Bitcoin pretty much has the soft fork upgrade strategy set in stone.</p>
<p>SegWit already segregated the maximum it could from the legacy 1 MB blocksize limit, and now only the minimal UTXO state transformation data (prevout refs and outputs) counts against the 1 MB limit while the witness (unlocking script) has been moved to the segregated 3 MB block space, and so in total the blocksize limit had been raised to 4 MB.</p>
<p>Further increase would require splitting individual UTXO balance(s) and tracking the split balance in some extended block data structure &amp; UTXO state. During block size limit debates, a <a href="https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md" rel="nofollow noreferrer">proposal</a> was presented to do exactly that:</p>
<blockquote>
<p>Extension blocks maintain their own UTXO set in order to avoid
interference with the existing UTXO set of non-upgraded nodes. This is
a tricky endeavor, requiring a <code>resolution</code> transaction to be present
at the end of every canonical block.</p>
<p>This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would
expect. Unfortunately, this requires a bit of extra book-keeping on
the upgraded node's side.</p>
</blockquote>

CC BY-SA 4.0
2024-11-08T13:30:13.530Z
2024-11-08T13:30:13.530Z
bca-0353f40e
<p>Litecoin is a good real world testcase for upgrades into Bitcoin. With the recent announcement of MimbleWimble extension blocks for privacy on LTC. Will Bitcoin adopt such a feature and what would that impact?</p>

CC BY-SA 4.0
2022-02-07T19:52:41.767Z
I'd suggest sticking to asking about the scaling, privacy impact rather speculating on adoption. None of us can tell you if and when a proposal will be merged into Bitcoin.
Michael Folkson
<litecoin><mimblewimble><mweb>
Litecoin implemented MimbleWimble extension blocks. Will Bitcoin adopt this privacy upgrade?
Patoshi パトシ
# Litecoin implemented MimbleWimble extension blocks. Will Bitcoin adopt this privacy upgrade?

(Asked by: username_0 on 2022-02-07)

Litecoin is a good real world testcase for upgrades into Bitcoin. With the recent announcement of MimbleWimble extension blocks for privacy on LTC. Will Bitcoin adopt such a feature and what would that impact?

**Tags:** litecoin, mimblewimble, mweb

> **Comments:**
> **username_1**: I'd suggest sticking to asking about the scaling, privacy impact rather speculating on adoption. None of us can tell you if and when a proposal will be merged into Bitcoin.  

---

## 2 answers

### Answer by username_2 on 2022-02-07. Score: 3

It's hard to make predictions about the future, but as of today, nobody has proposed adopting a similar MimbleWimble Extension Block in Bitcoin. Given the skepticism that previous extension block proposals were received with, I would be surprised if such a proposal got significant traction on Bitcoin.

---

The way I understand the proposal, the MimbleWimble Extension Block (MWEB) is coupled to the on-chain transaction body via a pegging mechanism. Funds can be moved into the MWEB by paying a special on-chain address and withdrawn from the MWEB by effecting a payment from that address.

Inside the extension block, transactions are created via the MimbleWimble protocol. MimbleWimble transactions must be crafted interactively involving both the sender and receiver, but making use Pedersen commitments the values of inputs and outputs are hidden to anyone but the parties crafting the transaction. Immediately after construction, transaction inputs and outputs form a similar graph structure as on-chain Bitcoin transactions. However, the minimal MimbleWimble transactions are especially designed to allow for transaction cut-through: transactions can be aggregated non-interactively facilitated by some Elliptic Curve magic and due to Pedersen Commitments being homomorphic, which prunes any intermediate outputs that already got spent in the aggregate. (E.g. if there are two transactions (A1⇒B1+A2) and (A2⇒C1+A3) they could get aggregated to (A1⇒B1+C1+A3) pruning the creation and spending of output A2.) As MimbleWimble transactions can be aggregated even across blocks, the chainstate reduces to a remaining *kernel* per transaction, the peg-in inputs and the currently spendable outputs. On the downside, MimbleWimble transactions are very limited in their scripting capabilities.

In result, an attacker can learn more about the transaction graph by actively monitoring the transaction relay, but a passive monitor catching up later would effectively only see a huge coinjoin that is the aggregate effect of all previous transactions with hidden amounts.

---

I only skimmed the MWEB proposal to brush up on details. I suggest verifying any information in this post if you have more than a passing interest.


---

### Answer by username_3 on 2024-11-08. Score: 1

Whether Bitcoin would implement Mimblewimble can only be speculation at this moment, there are no proposals to do it.

Maybe the "extension blocks" part has a chance, just because there are no other options to increase block size limit as a soft fork, and Bitcoin pretty much has the soft fork upgrade strategy set in stone.

SegWit already segregated the maximum it could from the legacy 1 MB blocksize limit, and now only the minimal UTXO state transformation data (prevout refs and outputs) counts against the 1 MB limit while the witness (unlocking script) has been moved to the segregated 3 MB block space, and so in total the blocksize limit had been raised to 4 MB.

Further increase would require splitting individual UTXO balance(s) and tracking the split balance in some extended block data structure & UTXO state. During block size limit debates, a [proposal](https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md) was presented to do exactly that:

> Extension blocks maintain their own UTXO set in order to avoid
> interference with the existing UTXO set of non-upgraded nodes. This is
> a tricky endeavor, requiring a `resolution` transaction to be present
> at the end of every canonical block.
>
> This specification prescribes a way of fooling non-upgraded nodes into
> believing the existing UTXO set is still behaving as they would
> expect. Unfortunately, this requires a bit of extra book-keeping on
> the upgraded node's side.


---

