I’m going to describe how Mimblewimble transactions are different than the transactions we are used to and what this brings behind it.
Usually a transaction signature commits to everything that defines a transaction. In Bitcoin, a transaction signs the whole transaction structure which includes inputs and outputs. This makes the transaction static. You can’t change your inputs or outputs while keeping the same signature.
Mimblewimble does transaction signing a bit differently. It does not sign any input or output, instead it only signs the difference of the sum(outputs) - sum(inputs) so it only commits to this difference. This means that inputs and outputs are floating and can be replaced while keeping the same kernel signature. If a person sees transaction T in which they own an output O1, they could create a new output O2 that would hold the same v*H value but a different blinding factor r. This person can decide to replace O1 by O2 and still have a valid transaction if they adjust the kernel offset by the difference between the outputs blinding factors. They can even create 2 outputs out of 1 if they wanted to. Similarly, if they own an input in a transaction, they could replace it by another one while keeping the transaction valid. This seems useless at first because only the owners can do that, but this idea can be used in some ways to provide some nice privacy benefits.
If you’re wondering now how we can recognize a transaction if all the inputs and outputs have changed, we can do this by looking at the kernels it has because these can’t be replaced
One thing that we can do is that it doesn’t need to be us changing the outputs. If we provide a description to some random node of how to replace our output O1 by O2 and tell how the kernel offset must be adjusted, then they can do the swap as well. If we show this to the node that holds our stem transaction, it does not hurt our privacy, which means we can freely do that. Rangeproofs are
of course also communicated along with the outputs.
Now this also does not seem extra useful yet. Imagine now that we are passing a transaction regularly through dandelion in stem phase and everyone provides the descriptions how to swap the outputs. On top of that, each dandelion node only sees exactly one possible swap per output. This means that the whole output set of the transaction is getting replaced at each move forward.
To put more of a theoretical bound to this. Let’s say we have a transaction with 10 inputs and 10 outputs. If we send this transaction to a node along with the swap descriptions for every output which only this node can read, then assuming this node is honest and performs the swaps, the inputs become completely unlinked from its outputs because the whole output set gets replaced by a new output set. The same could be done for inputs which means the 10x10 transaction can completely change with no single input or output being the same just by the node applying the input/output swaps it sees described. This can make transaction aggregation even more powerful because aggregation alone preserves the outputs which have a history of being seen by the previous nodes. Doing output swaps gets rid of the output history that was observed prior to final aggregation.
I’m not saying that input swapping is a smart move, I don’t know yet. But the output swapping seems free of any risk - at least that’s my current view. I think this opens up new orthogonal possibilities to improve privacy on Mimblewimble.
An example of this strategy used with Objective-Dandelion was described here Objective-Dandelion
Edit: I’m still unsure if swapping inputs has value, but it is worth mentioning that performing an input swap as a sender has different consequences regarding how the replay protection is done. If we have kernel uniqueness check at a consensus level, then we should be protected from replay attacks. If we have protection through PayJoins, then Alice is not safe if she changes the inputs because Bob could ‘play’ the same kernel transaction with different inputs and get money.
