mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

On Thu, Mar 16, 2017 at 10:10:48AM -0400, Ethan Heilman wrote:
> >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.
>

I do think we want a standard term for the B1+B2 aggregate, which will
be a pair of blocks with partially pruned input and output sets. (Note
that in Igno's design for grin, partial pruning of these sets never
happens. We may want to rethink that in order to support this.)

I think supporting these aggregates is important, it gives MW a bit scaling
advantage because it enables operation of the form "sync the blockchain
every morning and download only the aggregate", saving significant bandwidth
and validation for users who don't care about having high time-resolution.

There remains the issue of what reorgs look like. It may be that B1+B2
needs to contain all the inputs and outputs of B1 and B2 (but without
some rangeproofs, which is still a big validation/download savings).

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

It obfuscates the total number of transactions.
 
> 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.
>

I think your thinking in terms of kernels is wrong; kernels have no
amounts and can't inflate or deflate the currency; they can't really
be "invalid" in this sense. Just looking at inputs and outputs is a
better way, leaving the kernels in the background to balance the
algebra and anchor things to blocks.


--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature