Is MimbleWimble cut-through actually useful for pruning chain state?

Research
1

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, source2

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:

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?

2

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.

2 Likes
3

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.

4

There is no such attack, as you can see from my reply in that thread.

2 Likes
5

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 :magic_wand:

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 :wink:

1 Like
6

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.

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.

1 Like
7

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.

1 Like
8

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

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)

1 Like
9

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):sweat_smile:

1 Like
10

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.

4 Likes
11

Good questions.

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.

Others have already provided an answer as to why #2 is incorrect.

I made a high level visual explanation of MWixnet 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.

2 Likes
13

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:

4 Likes
14

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 :sweat_smile: