← Back to team overview

mimblewimble team mailing list archive

Re: Potentional method of hardforking MimbleWimble via freaky invalid to valid block transitions


John beat me to it, I was writing a very similar reply. One meaningful addition is that in that reply, I coined the term frankenblock. I don't think I'll have a lot of opportunities to reuse it so thought it had to be shared :P

And thanks Ethan for thinking about this and sharing!

- Igno

-------- Original Message --------
Subject: Re: [Mimblewimble] Potentional method of hardforking MimbleWimble via freaky invalid to valid block transitions
Local Time: March 15, 2017 8:01 PM
UTC Time: March 16, 2017 3:01 AM
From: john.tromp@xxxxxxxxx
To: Ethan Heilman <ethan.r.heilman@xxxxxxxxx>
Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>, Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>, mimblewimble@xxxxxxxxxxxxxxxxxxx

Answers below according to my understanding...

> What is MimbleWimble default behavior in the event that a block
> contains a doublespend? Is the block invalid like in Bitcoin?

Yes, every input must be an unspent output, and can appear at most once
in a block.

> 1. An attacker computes a block B1 with a doublespend transaction Tx1
> that has kernel K1,
> 2. The network will treat this block B1 as invalid,

B1 might thus as well not exist.

> 3. The attacker when deletes Tx1 from B1 as if has been cut-through
> even though it hasn't been spent. This block will still not validate
> because the kernel K1 inflates the number of coins.
> 4. The attacker adds transaction Tx2 with kernel K2 using the blinding
> factors from K1 such that K1+K2 no longer inflates the currency. Note
> that Tx2 does NOT spend Tx1.
> 5. The attack includes Tx2 and K2 in block B2 and aggregates B2 with
> B1 where Tx1 has been deleted.

This constructs a valid B2, which like any other valid block,
can be seen as a slight modification of an invalid block.

> The block B1 will now be treated as valid by a node if and only if it
> is sent as an aggregate of B1+B2.

I'm not sure what you mean by an aggregate block.
What is the header, and in particular, the proof of work of this
aggregate block? How do they fit into the definition of
most-cumulative-difficulty chain?

For verification purposes, I imagine one needs to always verify all kernels
from all blocks in the MCD chain, so if, following the block header,
the block body starts with all bock kernels, then we need to read at
least that initial
part of every block. The remaining transaction data could then be
compressed by cut-through and verified with help of committed merkle
roots, but I don't
see how that itself can form a block.


Follow ups