Enable transaction cut-through

[spacebear21]

Background: https://bitcointalk.org/index.php?topic=281848.0

To enable transaction cut-through, receivers should be able to completely replace the Original PSBT output(s) paying them with one or more new outputs, as long as they can provide inputs that cover the new output amount + fees.

A discussion was started in #277, on how this might look in the payjoin API. It would be great to determine the specific API changes required to support transaction cut-through and get them implemented ahead of a 1.0 release.

[DanGould]

259 is a sort of mirror to this I'd like to mention alongside this cut-through topology enhancement. While cut-through is a complication, allowing contributions to sweeps provides some fee savings with a simplification.

This is also related to #69

[spacebear21]

Thinking about the input contribution step more...

The way input selection currently works:

• Receiver selects one (and only one) input to contribute. It can be for ~any amount (UIH privacy selection aside).
• Receiver adds the value of that input to their output (new output amount = amount sent by sender + amount contributed by receiver). The receiver output effectively acts as a change output and destination output.

With tx cut-through, things are more complicated:

• Receiver substitutes their original output with an arbitrary number of outputs with arbitrary values.
• Receiver selects one or more inputs, with at least enough cumulative value to cover (total receiver output amounts - amount received from sender) + (maybe tx fee contribution).
• Any excess input amount needs to be added as change, but which output would that be?
  • E.g. if receiver is forwarding funds, change amount must be added to an output belonging to the receiver, not to the forwarded payee.
  • Maybe one output from the first step must be flagged as "change output"? Similar to the current approach but mark the target output in step 1.
  • Or should this step just add a new receiver change output? Are there special privacy considerations here?

[spacebear21]

Also, it would be very helpful to have a list of concrete examples/test cases that cover realistic use cases for tx cut-through, e.g. opening lightning channels, utxo consolidation, forwarding payments (this could be many things, such as paying an invoice or an exchange processing a withdrawal batch)... any others?

Knowing exactly what we're building for makes it much easier to design a nice usable interface. And each use case might have different privacy requirements or other constraints.

[DanGould]

It does seem like the ProvisionalProposal typestate will need to be split. The common flow as you mention seems to be defining outputs and then selecting inputs to cover them, and finally handling change. The Payjoin state machines identify a "payee" output which assumes the receiver is the final payee. If replaced, a "receiver change" output needs to be identified if the payee address has change and completely replaces the payee output. I think your gut to identify a change output manually is good enough for a first draft. After we have a draft and practice on some integrations, a better interface is likely to appear for us if it is to be found.

Are there special privacy considerations here?

There are privacy considerations regarding Unnecessary Input Heuristic (UIH). I have notes on the academic research as I understand it, but my notes ignore subsets of inputs, which would need to be understood in order to avoid conforming to this heuristic. See the notes' footnotes to read state of the art research.

As far as I understand, some software does produce UIH variants without payjoin just to consolidate or to do other sorts of batching. We probably need to collect more data and study to find out which ones and how to concern ourselves with them.

My gut tells me that 1. defeating Common Input Heuristic (CIH) is more important, since that's the foundational privacy leak from the Satoshi paper and 2. Those Payjoin implementers focused on cost-savings won't concern themselves as much with UIH avoidance. Since first-class cut-through support breaks CIH and promotes wider adoption, I'm inclined to proceed with a limited understanding of subset UIH and support cut-through transactions for the time being.

Some Concrete examples

• opening lightning channels in nolooking
  • Including substituting a swap-in-potentiam address with a channel open contract in Payjoin-in-Potentiam
• utxo consolidation is already implemented
• forwarding value: to cold storage, an exchange, a merchant, another payee, a swap-in-potentiam address (not directly to a lightning channel),
• replacing an e.g. Boltz atomic swap contract with the swap payout in an interactive happy case
• Liana Vault automatic timelock refresh

[DanGould]

Output augmentation where a receiver adds outputs paid for exclusively in amounts exceeding the payment output is possible even with payment output substitution disabled. Our API should be able to make transactions like this as well. This is related to the API but not strictly output substitution.

[DanGould]

closed by #332