<p>The incompatibility comes down to 2 main factors:</p>

<ul>
<li>Pruning: an important addition of the mimblewimble proposal is the ability to merge transactions across blocks. If transactions include scripts, merging becomes impossible as the script behavior is unknown. While for simple spends, it's fairly straightforward to eliminate matching amounts.</li>
<li>No address: in mimblewimble the equivalent of bitcoin addresses (hash of a public key) don't really exist. There may be a way to still be able to send money for a contract but it'd be difficult for a contract to send money to anyone.</li>
</ul>

CC BY-SA 3.0
2016-08-27T18:35:14.217Z
2016-08-27T18:35:14.217Z
Matthieu
<p>Scripts are used in Bitcoin to prove authorization to spend the inputs in a transaction. Mimblewimble uses a quirk of CT such that only the owner of a set of inputs can create the transaction in the first place. The resulting transactions have enough structure that they can be merged and cut-through, and as @Matthieu says, after cut-through any scripts that may have been present are gone and unverifiable.</p>

<p>To answer your specific questions:</p>

<ol>
<li>For multisig, n-of-n the parties create an output by summing public keys and then adding <code>vH</code> to get a Pedersen commitment. They then interactively produce a rangeproof. Doing a m-of-n version is a little more involved (the summing is replaced by some higher-degree polynomial) but essentially the same.</li>
<li>For locktimes, the transaction "excess", which needs to stay in the blockchain forever, can simply sign a minimum blockheight at which it's allowed to appear.</li>
<li>Atomic swaps, hash timelocked contracts, zk-contingent payments, Tumblebit, and a pile of other things require outputs that can only be spent by explicitly revealing some secret value (as opposed to proving knowledge of a secret value without revealing it at all, as signatures do). It's an open problem to construct a MimbleWimble output which has this property.</li>
</ol>

<p>Note that you can get payment channels with just (1) and (2); hash preimages are only needed for HTLC Lightning channels, which are more efficient and have some other nice properties.</p>

CC BY-SA 3.0
2016-11-11T15:36:34.173Z
2016-11-11T15:36:34.173Z
Andrew Poelstra
<p>What is the compatibility problem between script and mimblewimble usage on the main chain?</p>

<p>Is there a way that Bitcoin can adapt to allow both mimblewimble and features like multi sig, atomic swaps and time-lock transactions?</p>

CC BY-SA 3.0
2016-08-27T22:52:21.340Z
Note that threshold transactions ("m-of-n") are still possible, just not through scripts... but by the keyholders negotiating the transaction with each other.
Pieter Wuille
<script><mimblewimble>
Why does script need to be purged from transactions for mimblewimble to work?
Game Changer
# Why does script need to be purged from transactions for mimblewimble to work?

(Asked by: username_0 on 2016-08-13)

What is the compatibility problem between script and mimblewimble usage on the main chain?

Is there a way that Bitcoin can adapt to allow both mimblewimble and features like multi sig, atomic swaps and time-lock transactions?

**Tags:** script, mimblewimble

> **Comments:**
> **username_1**: Note that threshold transactions ("m-of-n") are still possible, just not through scripts... but by the keyholders negotiating the transaction with each other.  

---

## 2 answers

### Answer by username_3 on 2016-11-11. Score: 7 | Accepted answer

Scripts are used in Bitcoin to prove authorization to spend the inputs in a transaction. Mimblewimble uses a quirk of CT such that only the owner of a set of inputs can create the transaction in the first place. The resulting transactions have enough structure that they can be merged and cut-through, and as @username_2 says, after cut-through any scripts that may have been present are gone and unverifiable.

To answer your specific questions:

1. For multisig, n-of-n the parties create an output by summing public keys and then adding `vH` to get a Pedersen commitment. They then interactively produce a rangeproof. Doing a m-of-n version is a little more involved (the summing is replaced by some higher-degree polynomial) but essentially the same.
2. For locktimes, the transaction "excess", which needs to stay in the blockchain forever, can simply sign a minimum blockheight at which it's allowed to appear.
3. Atomic swaps, hash timelocked contracts, zk-contingent payments, Tumblebit, and a pile of other things require outputs that can only be spent by explicitly revealing some secret value (as opposed to proving knowledge of a secret value without revealing it at all, as signatures do). It's an open problem to construct a MimbleWimble output which has this property.

Note that you can get payment channels with just (1) and (2); hash preimages are only needed for HTLC Lightning channels, which are more efficient and have some other nice properties.


---

### Answer by username_2 on 2016-08-27. Score: 7

The incompatibility comes down to 2 main factors:

* Pruning: an important addition of the mimblewimble proposal is the ability to merge transactions across blocks. If transactions include scripts, merging becomes impossible as the script behavior is unknown. While for simple spends, it's fairly straightforward to eliminate matching amounts.
* No address: in mimblewimble the equivalent of bitcoin addresses (hash of a public key) don't really exist. There may be a way to still be able to send money for a contract but it'd be difficult for a contract to send money to anyone.


---

