PayJoin (P2EP) in Grin

If every tx spent all utxos to create a single one, I think you’d end up with 2-2 txs because both Alice and Bob would use all their inputs and they would have only 1 input each since they must have been merged before. PayJoin on its own is not enough to prevent replays, what prevents them in my proposal is PayJoin in combination with the anchor output.

With regards to privacy, PayJoin is a different tradeoff and not a strict decrease in privacy. The downside for Bob is that he contributes an input so 1 out of 2 inputs belongs to him. But it comes with a benefit for the sender because he gains privacy now since you can no longer tell which of the 2 inputs is the sender. We have this same property with 1-2 transactions but only on the new outputs. PayJoin has it equal on both sides. So on the inputs side of privacy, the sender benefits and the receiver loses a bit, but I think in the same way that is done right now on the outputs side. There is another benefit I believe which is that backtracing becomes hard. If you give me an output on the chain and I logged all the mempool txs, if it was just 1-2 transactions it must be a linear chain to traverse backwards to the coinbase output. With PayJoin it becomes an exponential graph if you want to follow either the sender or receiver so it might be beneficial to make chain analysis harder (I don’t really know, it’s just what I imagine). Another possible obfuscation in PayJoin case could using 2-2 txs instead of 1-2 by making the sender add additional input. This way you can’t know if a tx is a regular send or a PayJoin so this also makes it a bit more confusing/hard.

1 Like