mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

> Ok, so I think where we're headed is:
>
>   - We should generalize blocks to "frankenblocks" which are ranges of
>     consecutive blocks where cutthrough inputs and outputs are pruned
>
>   - We should have a better name for frankenblock :)

I somewhat disagree. We don't need new kinds of blocks.
We want to implement cut-through in some way that allow quicker
processing of existing blocks. Quoting my earlier remarks:

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

I t seems that the simplest way to represent the cut-through result is
as a  single transaction containing all inputs and outputs that
survive the cut-through.
This transaction does not need to act like a block though. It would be
the response
of a full node when receiving a query

"my last verified utxo is from block i, but i see the chain is now at block j.
  please send me a cut-through proof of intermediate transactions so
  i only need to process the blocks up to and including their kernels".

A full node can answer this query more efficiently (esp. in bandwidth) than
answering "pls give me all blocks from i through j".

-John