There was a discussion on keybase regarding transaction interactivity so I’ve decided to explain my concerns here as well. From my understanding, Grin transactions require interactivity only at the “wallet address exchange” level. Once this step is done, the actual transaction building process does not require interactivity (except if you’re exchanging slatepack strings).
Disclaimer: I could be misusing the terminology, but I think that the points still stand and this should be discussed.
PayJoin transactions open an attack vector where the sender could perform a UTXO spoofing attack on the receiver. This means that the sender could ask the receiver to contribute an input, but then never publish the transaction. This could be done
N times and the sender could find out all the outputs that the receiver owns.
There’s another variant of a UTXO spoofing attack that is possible today which is a dusting attack. This is done by the sender spamming small value outputs to the receiver. If such a spam is successful then the sender could learn the receiver’s outputs over time because they get used with other real outputs - which is why I say it’s a variant of UTXO spoofing attack.
So a PayJoin on its own only makes it simpler, it doesn’t introduce something that is impossible right now. The underlying issue to me seems the fact that the receiver has no control over what they are receiving. As soon as the interactive step of exchanging the wallet address is done, they trust the sender with everything that follows because the steps are automated.
My opinion is that the receiver should have complete control over what they receive in their wallet. This means that they should not only control from whom they receive but also what they receive. This seems only possible by having a manual confirmation step for the values they are receiving - which to my knowledge is not possible at this stage (except for slatepack strings). We would of course need a way to somehow support receive-only wallets to allow users to have donation addresses and similar.
I don’t see this as horrible as some other people do. This is very similar to how we use cash today - we count the coins we receive and the coins we give out.
TLDR; UTXO spoofing seems a problem that is not inherent to PayJoin transactions. It’s present in the current transaction scheme, payjoins just make it simpler. We might want to address this vector to avoid having these attacks possible.
P.S.: @Paouky pointed out that if the wallet address becomes public at some point, it’s possible that they can’t even control from whom they receive.
P.S.2: Another possible mitigation might be if a wallet blocked a receive from the same wallet address twice