> 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 -- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
