# Is MimbleWimble cut-through actually useful for pruning chain state? **URL:** \ **Category:** Research\ **Created:** [July 8, 2023, 4:04am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623 "2023-07-08T04:04:05Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 8, 2023, 4:04am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/1 "2023-07-08T04:04:05Z")
First, I love Grin and MimbleWimble, but at risk of sounding cynical, I want to ask a few critical questions: I keep reading that MW cut-through is magical for allowing a node to prune transaction history while still maintaining a fully verifiable ledger: [source1](https://github.com/mimblewimble/grin/blob/master/doc/pruning.md), [source2](https://tlu.tarilabs.com/protocols/grin-protocol-overview#cut-through-and-pruning) Specifically, the Grin documentation from source1 gives a concrete example: > Assuming a blockchain of a million blocks, 10 million transactions (2 inputs, 2.5 outputs average) and 100,000 unspent outputs, we get the following approximate sizes with a full chain (no pruning, no cut-through): > > - 128GB of transaction data (inputs and outputs). > - 1 GB of transaction proof data. > - 250MB of block headers. > - Total chain size around 130GB. > - Total chain size, after cut-through (but incl. headers) of 1.8GB. > - UTXO size of 520MB. > - Total chain size, without range proofs of 4GB. > - UTXO size, without range proofs of 3.3MB. This is touted as providing the following advantages, which I’d like to challenge: 1. the node doesn’t need to store much data to stay in consensus 2. a new node can join the network and only download the reduced set of data to participate 3. it makes block sizes smaller by removing self referencing transactions To point no.1: this is also practically possible for non-MW blockchains like Bitcoin. Once a node has sync’d the chain and validated the ledger, there is no need for a Bitcoin node to keep the entire chain history. He only needs to keep the UTXO set to process new blocks with new transactions. **So point number 1 is not a real advantage.** To point no.2: A new node cannot trust the cut-through dataset, due to key cancellation attacks. So, for a node to _trustlessly_ join the network, it must download and process the full chain. **This too is the same as Bitcoin.** See key cancellation example: > [@Is blockwise kernel aggregation possible?](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/4): > > Utilising this naive scheme introduces a straightforward attack that can steal funds by using the _key cancellation attack_ without the attacker needing to know any private keys. > _Example_: > Say that _Alice_ transfer 5 coins to _Bob_. She does **not** know the _private-key_ under which they are stored; however, she knows the amount. > Say that _Alice_ mines a block before _Bob_ have spent the funds. She can then generate two **fake** transactions; > One using the funds she sent to _Bob_ as an input, and an output with the same amount (5 coins) but a _private-key_ picked by _Alice_ herself. > And another transaction by _Alice_, where she adds an additional output with 0 coins, but a _private-key_ that ‘offsets’ the excess. > Looking at the transactions individually, they will **fail** but summed they can create a valid signature that they will satisfy. To point no.3: This is the only point that holds water, IMO, but I’m still not sure its significant. How often do blocks have self referencing transactions? Is there some study that shows that at scale blocks will have many self referencing transactions, so that cut-through becomes a significant benefit? **So, what is the real value-add for MimbleWimble cut-through?** ---
**Author:** ![Trinitron](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/trinitron/32/4990_2.png) [@Trinitron](https://forum.grin.mw/u/Trinitron)\ **Post date:** [July 8, 2023, 4:31am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/2 "2023-07-08T04:31:41Z")
I don’t think you have #2 correct, because a node can download and trust the cut through chain. But I don’t know the cryptography, so we will see what the experts say. I think the answer lies somewhere in why we keep all kernels forever. You can see the post you linked is about whether kernels could be aggregated, but they are not aggregated in Grin for any type of node. ---
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 8, 2023, 5:34am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/3 "2023-07-08T05:34:05Z")
> [@Trinitron](#): > > I don’t think you have #2 correct, because a node can download and trust the cut through chain If you trust the reduced chain you’re given, you’re trusting that no key cancellation attack happened within the kernel set they’re given. You can check the total values balance out, but you can’t check that coins were moved with permission of the appropriate key holders. This is the same as Bitcoin. You can download only the UTXO set, and know that the total set doesn’t exceed 21MM coins or whatever, but you can’t know that coins were only moved with permission of the appropriate key holders. So, MW provides no advantage over Bitcoin here, as I see it. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 8, 2023, 7:15am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/4 "2023-07-08T07:15:50Z")
> [@AceKaplin](#): > > See key cancellation example: There is no such attack, as you can see from my reply in that thread. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [July 8, 2023, 8:20am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/5 "2023-07-08T08:20:46Z")
> [@AceKaplin](#): > > To point no.1: > this is also practically possible for non-MW blockchains like Bitcoin. Once a node has sync’d the chain and validated the ledger, there is no need for a Bitcoin node to keep the entire chain history. He only needs to keep the UTXO set to process new blocks with new transactions. **So point number 1 is not a real advantage.** > [@AceKaplin](#): > > To point no.2: > A new node cannot trust the cut-through dataset, due to key cancellation attacks. So, for a node to _trustlessly_ join the network, it must download and process the full chain. **This too is the same as Bitcoin.** See key cancellation example: It is a real advantage since you do not need to download all historic transactions, only kernels from spend transactions. This is the difference between archive node which is 13GB data at time of writing versus 4.5 GB or so. In other words, it provides currently an approximately 3X space saving. It is not only the storage, but also the innitial amount of sync data that is compact so the innitial sync of any node is quicker. I would call that highly significant! That space saving is on top of grins blockchain already being very compact especially if you consider grin has all transactions blinded. I call that magic 🪄 Another cool thing is that because of cutthrough if you receive a transaction, you can directly spend that transaction in the same block and there will be no trace on the blockchain. Only those who store and analyse the mempool will know. I think hardly anyone does this but it is still cool and can be used to save space and transaction costs. Correct me if I am wrong @tromp 😉 ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 8, 2023, 8:35am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/6 "2023-07-08T08:35:54Z")
> [@Anynomous](#): > > if you receive a transaction, you can directly spend that transaction in the same block and there will be no trace on the blockchain. You’d have to spend from a transaction that’s still in the mempool; while possible in theory, I don’t think any wallets currently support that. > [@Anynomous](#): > > save space and transaction costs. I don’t see how you’d save any transaction costs. You cannot fill the mempool with a chain of transactions each spending the previous one’s output unless you pay increasing transaction fees. Otherwise that would constitute some sort of DoS attack where the network has to relay arbitrarily large amounts of data for only a negligible fee. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [July 8, 2023, 8:40am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/7 "2023-07-08T08:40:55Z")
> [@tromp](#): > > I don’t see how you’d save any transaction costs. Now that I think about, I think I am wrong in the sence that it does not even have to be seen in the mempool or ever broadcasted. Is it possible for Alice to send to Bob RSR and then for Bob to send to Carol, meaning you directly transfer ownership or break up an UTXO you were about to receive. I thought it was possible🤔. So basically modify a transaction in building or in the mempool to skip ever receiving an output on chain. I do not see the use case yet appart from saving some transaction fee but probably there are other use cases. ---
**Author:** ![vegycslol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/vegycslol/32/3340_2.png) [@vegycslol](https://forum.grin.mw/u/vegycslol)\ **Post date:** [July 8, 2023, 8:47am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/8 "2023-07-08T08:47:37Z")
> [@AceKaplin](#): > > He only needs to keep the UTXO set to process new blocks with new transactions. I think that would only be true if reorgs were not possible. Since they are you need to store full data of at least some previous blocks (depending on how big reorg you want to be able to handle). > [@AceKaplin](#): > > How often do blocks have self referencing transactions? I don’t think they need to be self referencing, if in block height X utxo1 is created and in block height X+N utxo1 is spent then you can modify both blocks to not contain this data (at least for your local chain, wouldn’t be able to bootstrap others probably) ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [July 8, 2023, 8:56am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/9 "2023-07-08T08:56:52Z")
> [@tromp](#): > > I don’t see how you’d save any transaction costs. You cannot fill the mempool with a chain of transactions each spending the previous one’s output unless you pay increasing transaction fees. I forgot about the need to increase the fee. However, if you would receive an TXO and send it to many (more than one), it could save transaction costs for that single TXO since a miner would rather include the transaction with multiple outputs than the original transaction in the pool with a single output. Am I just describing a CoinJoin… (not really since you replace an output with other outputs)😅 ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 8, 2023, 9:08am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/10 "2023-07-08T09:08:42Z")
> [@Anynomous](#): > > Is it possible for Alice to send to Bob RSR and then for Bob to send to Carol, Yes, if Alice and Bob together constructed an A-\>B transaction that has not been published yet, then Bob could construct a B-\>C transaction with Carol and cut it through with A-\>B before publishing. So this cut-through is something you can do to unpublished transactions. But it comes with some restrictions. The Alice to Bob payment would need to be RSR, and Bob to Carol SRS, so that Bob is the final publisher of both. Also, Carol (or Alice) needs to commit to a non-standard fee in their kernel signature, if you are to save on any fees, which current wallet software may be unable to do. To do the equivalent in Bitcoin would require all of Alice, Bob, and Carol interacting. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [July 8, 2023, 10:54am UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/11 "2023-07-08T10:54:23Z")
Good questions. > [@AceKaplin](#): > > To point no.1: Bitcoin can certainly store minimal data and stay in consensus, but it’s unable to bootstrap new nodes if it prunes old blocks. Mimblewimble and Grin can help new nodes join the network while dropping most of the history. > [@AceKaplin](#): > > To point no.2: Others have already provided an answer as to why #2 is incorrect. > [@AceKaplin](#): > > To point no.3: > How often do blocks have self referencing transactions? I made a [high level visual explanation of MWixnet](https://twitter.com/phyrooo/status/1677393282207195147) yesterday. It’s not detailed, but should help understand the main idea. As you can see, the whole MWixnet is a giant transaction (or transaction graph) that gets reduced to a much smaller one by using the noninteractive cut-through. I think that’s one example where cut-through saves bandwidth and onchain space. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [July 8, 2023, 3:04pm UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/13 "2023-07-08T15:04:42Z")
Works fine for me. You have to be logged in to see the whole thread of tweets though. I’ll get them here in case you don’t use twitter: > > > > > > ---
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 8, 2023, 3:16pm UTC](https://forum.grin.mw/t/is-mimblewimble-cut-through-actually-useful-for-pruning-chain-state/10623/14 "2023-07-08T15:16:33Z")
Thanks all. @tromp corrected my misunderstanding on the other thread. Key cancellation attacks are only possible with a naive linear schnorr aggregation which Grin does not allow. I thought it was possible to have a kernel set which committed to a different tx history while yielding the same final output set… obviously that was wrong and I feel stupid for not thinking about it that way before. Since that is not possible, then my confused criticisms above are not relevant anymore. Sorry for wasting everyone’s time 😅