mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

On Wed, Mar 15, 2017 at 06:06:58PM -0400, Ethan Heilman wrote:
> >I've argued elsewhere that compact validation is not weaker than full validation, in the sense that it still guarantees the invariants of "no net inflation or theft".
> 
> I completely buy this argument which is why I don't understand why
> there would be a threshold for blocks to be compacted. I love the idea
> of the WimbleMimble blockchain being just a big evolving proof of no
> inflation or theft". What is the downside to having every peer
> cut-through transactions as they are spent? Am I missing an attack?
> 
> It seems like this would handle forks. As long as you never aggregate
> your UTXO set, if a competing fork wins you ask for the missing
> kernels in the other fork, diff the UTXO set changes and validate.
>

Igno points out that you can't noninteractively cutthrough in the mempool,
without creating problems with apparent double-spends whose origin can't be
detected, which sucks but I think is true. (Interactive cutthrough and
block-level cutthrough does not suffer this issue.)

As for validating every _block_ in the compact model..this is interesting.
I think you're correct, and the only problems here are that the code/logic
needs to be more complex than I had envisioned.

The rest of this post is me thinking out loud, so it's a little rambly.

* * *

This lets miners create chains of blocks that are valid, but whose subsets
are invalid, allowing the potential of delayed forks, but I think this is
exactly the same as a block withholding/selfish mining attack in Bitcoin
-- and similarly is not a concern until somebody has 33% of the hashpower.


The reason I am doubtful about this is because of the logistics in handling
reorgs. To rewind a block you need the individual block's data (which you
don't validate when doing compact validation), so if this is invalid or
missing then you have a problem.

Consider the following scenario. I am a very powerful miner and I create a
fork

         __ B
  A  <--<__ C

where both B and C are building off of A. Say that none of these blocks are
valid individually but the compactions AB and AC are valid. I post both to
the network, now everyone is split between the two, and the next block will
force a reorg.

Logistically, how does somebody who has AB in their blockchain switch to AC?


For that matter, how did anyone validate AB in the first place? Compact
validation of an entire chain is easy because you need no inputs, but compact
validation of partial chains is harder because you need a subset of each
blocks' inputs.


The last time I thought about this was before we realized we needed the TXO-set
commitments in blocks, and without those, this "subset of each blocks' inputs"
business could be used to fork the network. But I guess now that's not a issue.
The exact position (or presence) of inputs and outputs doesn't matter at all,
the kernels tie transactions to the blockchain at the appropriate height, and
the only purpose of the inputs and outputs is to allow validators to construct
UTXO set diffs. (And then the txoset commitments ensure that if they disagree
on the diffs they'll disagree on the chain, preventing consensus failures.)

Very interesting.


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