- reduce fee overhead
- Usher in tangible privacy benefit
- Keep maintenance burden low
- Separate concerns (i.e. encapsulation)
example where output 1 is the swap
Reverse swaps only have 1 output to the user. If they were to payjoin, a third party (Like the boltz server) would have to add an input and output. Their nature as sweeps make their counterpart, which look more similar to typical 1-input-2-output transactions, better candidates for a payjoin deployment.
example where the spend of output 0 is the claim
Standard swaps swap from on-chain to lightning funds. Typically, only the boltz customer funds them. We can use payjoin so that Boltz's LND also funds the transaction. Payjoin gives both boltz, their customers, and all bitcoin users better privacy because it busts a whole class of heuristic chain analysis.
The two complex bits to make it work with the payjoin sdk are
- checking that the payjoin server only responds to requests paying Boltz recipient output HTLC addresses
- keeping track of inputs that have been seen before to prevent probing attacks
There is also a question of whether to use a wasm or node-api payjoin sdk binding in boltz-backend or web hooks to an independent payjoin daemon. Channel open swaps could also use payjoin to skip one transaction I believe.
both the rust payjoin-client + bitcoind CLI library example and nolooking independent daemon with http interface for LND were shared as PoC examples.