mimblewimble team mailing list archive

[Ethan Heilman <ethan.r.heilman@xxxxxxxxx>]

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

I can see how aggregate block is confusing terminology. I'm going to
avoid using it in the future.

What I meant was that the blocks B1+B2 are sent together and that
possible cut-throughs have already been applied in both blocks.
Furthermore the attacker deletes Tx1 from B1+B2. Thus someone who
receives B1+B2 in this compact representation will conclude that both
blocks are valid, whereas someone who is sent B1 without Tx1 deleted
will see the doublespend and treat B1 as if "B1 might thus as well not
exist." What is different about this case from the earlier examples is
that since Tx2 does not spend Tx1 no one but the attacker will know to
delete Tx1 to transform B1+B2 into a valid state.

These Frankenblocks (thanks Ignotus) can do some very strange but
perhaps useful things. You could have an input that spends an output
(although it can't actually spend that output) and then fix that
invalid block in a later block. Someone who doesn't understand the
particulars of frankenblocks would see that a blockheader which
contains a spend of that particular transaction output is in the valid
chain and thereby conclude that the output has been spent (despite the
fact that it has not been spent). Wallet implementers should be
particularly careful about this.

A block could have more kernels than transactions and still validate.
Are there any privacy benefits to throwing in an extra do-nothing
kernel?

I need to think about this more but I suspect that you can build
circuits out of attempting to satisfy a set of invalid kernels.

On Wed, Mar 15, 2017 at 11:10 PM, Ignotus Peverell
<igno.peverell@xxxxxxxxxxxxxx> wrote:
> 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.
>
> -John
>
>