Transaction Obfuscator

oryhp · October 12, 2020, 7:20pm

I’ve tried to describe what I refer to as a transaction obfuscator which I tried to describe a few times on the keybase chat. I believe this path is worth debating and researching further.
Aggregator+Obfuscator could be a good privacy combination. The reason I’m bringing it up now is because the early payment proofs might make the idea of output swapping unfeasible, so we should perhaps take some time to explore this path before we discard it.

gist.github.com

https://gist.github.com/phyro/22be7833265a4448eb3815ff8ae8c4de

tx_obfuscator.md

# Transaction functions

We are all familiar with transaction aggregation, it's a process of taking two transactions and aggregating them to create a new transaction. Given a transaction `T1` and a transaction `T2`, we can apply an aggregate function on them `aggregate(T1, T2) -> T3` to obtain a new transaction `T3`. The good property it has is that `T3` has a higher anonymity set which is what we want to achieve. What it does not do however, is that if you have seen `T1` or `T2`, then you still know which outputs are linked together. Aggregation can't unlink previously obtained knowledge regarding output links.

## Mimblewimble flexible transactions

There is a possible way to potentially unlink previously seen links between the outputs. We will use a property that is unique to Mimblewimble which is that transactions don't commit to inputs and outputs, but rather only on the difference of their sums. This means that our inputs and outputs are never really sealed. Given a transaction `T` where we own and input `I1` and an output `O2`, we can replace both of them with arbitrary many inputs and outputs (including none). We can do that by calculating the difference between the blinding factors that is needed in order to keep the transaction valid and we do that by adjusting the kernel offset accordingly. I've been referring to this as output swapping. It doesn't seem useful at all because only the owner can do it. Moreover, if the owner shares the information on how to swap the output with others, they know what was swapped so it seems as if it can't be used at all.

## Tx Obfuscator

This file has been truncated. show original

tromp · October 12, 2020, 10:10pm

I fail to see how early payment proofs conflict with output swapping, as the latter doesn’t need to change the public excess.

vegycslol · October 12, 2020, 10:14pm

aren’t payment proofs proved by providing the signature of the receiver? so they commit to the excess of the receiver, which doesn’t contain the offset. So the receiver needs to keep the same private excess for the payment proof to remain valid or not?

tromp · October 13, 2020, 7:17am

Yes, the receiver cannot change their excess, which equals
their outputs minus their inputs minus their offset times G.
So they can make any changes that keeps this equation balanced.

vegycslol · October 13, 2020, 8:36am

i see, i forgot how offset is applied. If it’s embedded in the Xr then output swapping still works

oryhp · October 13, 2020, 6:29pm

It seems to have been a false alarm regarding the breaking of output swapping idea, my bad.

Topic		Replies	Views
Mimblewimble 'shapeshifting' transactions Research	6	627	August 1, 2020
ObscuroJoin transaction Research	8	1255	May 19, 2020
Daily Aggregator (Partial Transactions) Research	21	2234	January 28, 2021
Improvement Proposal: Confidential Assets Development and Technical Discussion	8	767	December 30, 2019
My full response to The Block's questions	8	1760	November 28, 2019

Transaction Obfuscator

Related topics