mimblewimble team mailing list archive

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

Hi Andrew,

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

Since half the network has AC they must provide AC or the AB half will
not consider the new fork valid. This would be similar to Bitcoin
where if I have the longest fork but refuse to share some of the
transactions in that fork, that form is considered invalid.

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

Good point.


On Thu, Mar 16, 2017 at 11:12 AM, Andrew Poelstra
<apoelstra@xxxxxxxxxxxxxx> wrote:
> 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
>