The purpose of this ticket is to collect improvements to receiver coin selection and output creation so that the resulting PayJoin transaction has a plausible trivial sub tx mapping and its more likely than other interpertations.
The current receiver strategy is:
- If output subsitution is allowed, add outputs / substitute output.
- Select a candidate input that avoids UIH2: the smallest input must exceed the smallest output
- Bump the payment output by exactly the receiver's input value (drain bump)
When no candidate passes the UIH2 check, the implementation falls back to selecting the first available candidate regardless. Technically this could be represented as a transient error and the implementation can decide wether to broadcast the fallback or produce a PJ with a UIH2 marker. UIH arguably is worse bc it definetly leaks idiosyncratic distribution.
An alternative raised during mob programming: split the receiver's outputs such that no single output is smaller than the receiver's input, simulating a batch payment and avoiding UIH2 without requiring a large input. How common is the peelchain-like structure in practice? Example Cake to BB tx. It seems like some data collection here is neccessary.
The cost is twofold. First, additional block space. Second and more importantly: the resulting outputs must never be spent together. Doing so reinstates CIH linkage and retroactively degrades the PayJoin.
What would the interface of this look like? Wallets today don't keep track of what UTXOs should NOT be spent together. Perhaps we have an oppurtunity to set the standard here.
Another observation: Input selection is not scored. The current loop returns the first UIH2-passing candidate. Among all passing candidates, those closest in magnitude to the sender's inputs are strictly preferable as they minimize value asymmetry, reduce the size signal UIH2 is a proxy for, and make the trivial mapping harder to distinguish from the two-party interpretation.
Perhaps another way of stating the problem and solution: input selection and output construction should be treated as a joint optimization. Given:
- Sender inputs $I_S$ and outputs $O_S$ (fixed)
- Receiver candidate UTXOs $\mathcal{C}$
- Outputs the receiver must create
- Outputs the receiver is willing to create (e.g. via splitting)
Select $I_R, O_R$ s.t the final transaction's value structure and behavioral fingerprints are consistent with a single rational party. The trivial mapping is arithmetically valid and no heuristic rules it out. Other valid mappings may exist and will likely exist as $|O_R|$ grows. Will need to workshop this definition a bit more.
Concrete tickets are TBD. First wanted to put my thoughts on paper
Related tickets: #460, #551
The purpose of this ticket is to collect improvements to receiver coin selection and output creation so that the resulting PayJoin transaction has a plausible trivial sub tx mapping and its more likely than other interpertations.
The current receiver strategy is:
When no candidate passes the UIH2 check, the implementation falls back to selecting the first available candidate regardless. Technically this could be represented as a transient error and the implementation can decide wether to broadcast the fallback or produce a PJ with a UIH2 marker. UIH arguably is worse bc it definetly leaks idiosyncratic distribution.
An alternative raised during mob programming: split the receiver's outputs such that no single output is smaller than the receiver's input, simulating a batch payment and avoiding UIH2 without requiring a large input. How common is the peelchain-like structure in practice? Example Cake to BB tx. It seems like some data collection here is neccessary.
The cost is twofold. First, additional block space. Second and more importantly: the resulting outputs must never be spent together. Doing so reinstates CIH linkage and retroactively degrades the PayJoin.
What would the interface of this look like? Wallets today don't keep track of what UTXOs should NOT be spent together. Perhaps we have an oppurtunity to set the standard here.
Another observation: Input selection is not scored. The current loop returns the first UIH2-passing candidate. Among all passing candidates, those closest in magnitude to the sender's inputs are strictly preferable as they minimize value asymmetry, reduce the size signal UIH2 is a proxy for, and make the trivial mapping harder to distinguish from the two-party interpretation.
Perhaps another way of stating the problem and solution: input selection and output construction should be treated as a joint optimization. Given:
Select$I_R, O_R$ s.t the final transaction's value structure and behavioral fingerprints are consistent with a single rational party. The trivial mapping is arithmetically valid and no heuristic rules it out. Other valid mappings may exist and will likely exist as $|O_R|$ grows. Will need to workshop this definition a bit more.
Concrete tickets are TBD. First wanted to put my thoughts on paper
Related tickets: #460, #551