mimblewimble team mailing list archive

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

>You can not apply any changes to existing blocks, as that will invalidate their PoW.

The changes are not being applied to the block headers. Instead what
is being modified is which transactions are sent with a block. For
instance in Bitcoin if you delete a transaction when sending a block
people will treat that block as invalid until they have the complete
transaction set. However in MW cut-throughs means that there are
legitimate reasons for not sending the entire block. Thus I can send a
subset of the transaction set and everyone should be fine with it as
long as it validates according the MW rules.

>Can you show in detail what that final claimed utxo set looks like, how it is consistent with the set of kernels of valid blocks, but different from the result of processing all transactions from those blocks?

Invalid block B1
(Tx1.out)<--(Tx2.in,Tx2.out)
(Tx1.out)<--(Tx3.in,Tx3.out)

Tx3 is deleted from B1, Tx5 is added in a new block such that the
kernels balance out:

Valid Block B1
(Tx1.out)<--(Tx2.in,Tx2.out)

Valid Block B2
(Tx4.out)<--(Tx5.in, Tx5.out)

On Thu, Mar 16, 2017 at 10:45 AM, John Tromp <john.tromp@xxxxxxxxx> wrote:
> dear Ethan,
>
>> 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.
>
> You can not apply any changes to existing blocks, as that will
> invalidate their PoW.
> I think what you're trying to do is construct some set of kernels and utxo set
> that is claimed to summarize a valid block history when in actuality
> there was no such history.
>
> Can you show in detail what that final claimed utxo set looks like,
> how it is consistent with the set of kernels of valid blocks, but
> different from the result
> of processing all transactions from those blocks?
>
> Btw, one thing that confuses me in your argument is that you say that
> cut-through can eliminate double spending. I don't see how that happens.
> If tx1 double spends an output, then tx1 combined with later tx will still
> doublespend that output. And tc1 combined with earlier tx will result
> in earlier doublespends?!
>
> regards,
> -John