<p>Commenting on the overall security model is a much more complex answer as many moving parts are involved, from initial blockchain syncing to cut-through. But to answer your specific questions:</p>

<h2>Quantum computing</h2>

<p>MimbleWimble is not very well prepared for quantum computing as it's intricately tied to Elliptic Curve Cryptography (ECC). But the full picture is a little more complex.</p>

<p>First, one has to define "quantum computing" further. <a href="https://en.wikipedia.org/wiki/Shor%27s_algorithm" rel="nofollow noreferrer">Shor's algorithm</a> would require several hundreds of qubits to break ECC. Modern quantum computers with higher qubit counts rely on quantum annealing, which is a different "kind" of quantum computer much more limited in function, and can't implement Shor's algorithm.</p>

<p>Second, there's early indication that quantum-resistant algorithms may exist with properties similar to ECC that could be used for MimbleWimble. They're mostly untested in the field, so it will required some time, but the above points shows we do have some time.</p>

<p>Overall, quantum computers that can break ECDSA are still years away. So starting with ECC which is well proven and migrating to quantum resistant algorithms when they're mature seems like a good approach.</p>

<h2>Miners trust and "Classic" Bitcoin attacks</h2>

<p>MimbleWimble has the same miner trust model as Bitcoin, and the same exposure to 51% attacks and DDOS (although in the case of DDOS resistance is more implementation specific than algorithmic). MimbleWimble is more resistant to Sybil attacks than Bitcoin because it's impossible to fake the current chain state.</p>

<h2>Light Clients</h2>

<p>At this point, light clients are completely unspecified. However assuming a UTXO set commitment in the header and a few other sane measures, tricking a client into trusting an invalid transaction would be extremely hard.</p>

CC BY-SA 3.0
2017-09-03T22:23:37.140Z
Can you elaborate and/or give references for quantum resistant algorithms? If I understand correctly the required properties are partially homomorphic encryption, and zk range proofs to constrain the additive property, but these two witness values don't need to be based on the same crypto, right?
nothingmuch
CC BY-SA 3.0
2017-09-03T22:49:43.330Z
Apparently the answer to my question is yes: according to Andrew Poelstra, the rangeproofs are the tricky bit (maybe): https://youtu.be/aHTRlbCaUyM?t=29m19s
nothingmuch
CC BY-SA 3.0
2016-12-08T19:41:59.387Z
2016-12-08T19:41:59.387Z
Igno Peverell
<p>In addition to scaling, privacy, and scripting differences Mimblewimble also differs in its security model.  How does Mimblewimble's security model compare to Bitcoin's?  Specifically:</p>

<ul>
<li>How well will Mimblewimble function in the age of quantum computing?</li>
<li>What trust is placed in miners?</li>
<li>Are possible attacks similar to Bitcoin? (51%, Sybil attacks, DDOS)</li>
<li>Is it possible to trick light clients into trusting an invalid transaction?</li>
</ul>

<quantum-computing><mimblewimble>
How does Mimblewimble's security model compare to Bitcoin's?
nate
# How does Mimblewimble's security model compare to Bitcoin's?

(Asked by: username_0 on 2016-11-11)

In addition to scaling, privacy, and scripting differences Mimblewimble also differs in its security model. How does Mimblewimble's security model compare to Bitcoin's? Specifically:

* How well will Mimblewimble function in the age of quantum computing?
* What trust is placed in miners?
* Are possible attacks similar to Bitcoin? (51%, Sybil attacks, DDOS)
* Is it possible to trick light clients into trusting an invalid transaction?

**Tags:** quantum-computing, mimblewimble


---

## 1 answers

### Answer by username_1 on 2016-12-08. Score: 3 | Accepted answer

Commenting on the overall security model is a much more complex answer as many moving parts are involved, from initial blockchain syncing to cut-through. But to answer your specific questions:

## Quantum computing

MimbleWimble is not very well prepared for quantum computing as it's intricately tied to Elliptic Curve Cryptography (ECC). But the full picture is a little more complex.

First, one has to define "quantum computing" further. [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) would require several hundreds of qubits to break ECC. Modern quantum computers with higher qubit counts rely on quantum annealing, which is a different "kind" of quantum computer much more limited in function, and can't implement Shor's algorithm.

Second, there's early indication that quantum-resistant algorithms may exist with properties similar to ECC that could be used for MimbleWimble. They're mostly untested in the field, so it will required some time, but the above points shows we do have some time.

Overall, quantum computers that can break ECDSA are still years away. So starting with ECC which is well proven and migrating to quantum resistant algorithms when they're mature seems like a good approach.

## Miners trust and "Classic" Bitcoin attacks

MimbleWimble has the same miner trust model as Bitcoin, and the same exposure to 51% attacks and DDOS (although in the case of DDOS resistance is more implementation specific than algorithmic). MimbleWimble is more resistant to Sybil attacks than Bitcoin because it's impossible to fake the current chain state.

## Light Clients

At this point, light clients are completely unspecified. However assuming a UTXO set commitment in the header and a few other sane measures, tricking a client into trusting an invalid transaction would be extremely hard.

> **Comments:**
> **username_2**: Can you elaborate and/or give references for quantum resistant algorithms? If I understand correctly the required properties are partially homomorphic encryption, and zk range proofs to constrain the additive property, but these two witness values don't need to be based on the same crypto, right?  
> **username_2**: Apparently the answer to my question is yes: according to Andrew Poelstra, the rangeproofs are the tricky bit (maybe): https://youtu.be/aHTRlbCaUyM?t=29m19s  

---

