Thanks for posting this! Funny, when I saw the blockstream announcement yesterday, I was actually wondering about the same, whether it could be used in Grin, and why it’s never been discussed, the PayJoin concept has been around for a while after all.
Is there any reason Bob would not want to consolidate with an existing output (assuming this was not done naively)?
The only thing I could think of, is that by adding an extra input Ib into the mix, Alice now can identify Ib as belonging to Bob. Depending on the input, that might not be something Bob wants. This however, seems like a pretty low cost to pay for the benefit of having the rest of the world unable to follow the transaction graph as well.
What would happen if Ib is of amount 0
here, i.e. a complete dummy, generated as part of some self-spend transaction perhaps, and is then spent at some point in the future alongside real outputs?
It does not appear to be a significant change to the process if we were to allow Bob to (optionally) add this additional input.
If it’s optional, it makes it easier to intersect (equally balanced) transactions as PayJoins, but if all transactions are like that, it’s much harder to do. So let me take that a step further and ask why this should not become a mandatory requirement for transacting in Grin?
This would result in a minimal increase in the size of a transaction (one additional input) and in fact a reduction in the transaction fee due to output consolidation.
Side-point, but we ought to take a pass on the transaction fee logic before HF4 to ensure that whatever formula we end up having is not only encouraging output consolidation, but also tx graph obfuscation.