Future of refunds

[karlb]

• Summarize the result of the discussion
• Create followup issues, if necessary

[ulope]

Refund discussion summary

There was a discussion with Heiko about removing refunds.

Current situation

We went over the state of and problems with refunds.
Both on the current implementation:

• No more backtracking due to source routing
• Not properly working since the initiator doesn't handle them
• Increased complexity in mediation / state machine code

As well as conceptual:

• Is there capacity for the refund along the reverse route in the first place?
• If another route than the exact return path should be used:
  • Who pays the PFS fees
  • Who pays the mediation fees
  • What happens if that transfer fails
• Will payments fail often enough to warrant the "burden" introduced by refunds

Concerns raised

His main concerns were that removing refunds might negatively impact Raiden's utility for some use-cases.

1. Loss of liquidity for large Raiden nodes (payment hubs, exchanges, etc.) if many payments fail (e.g. when a big "trunk" connection fails) / concerns about "blocking" channels with many pending transfers.
2. User annoyance with "hanging" payments
3. Attack potential (e.g. AttackerA -> Victim -> AttackerB -> ..., AttackerB doesn't process mediated transfers from Victim, thereby depriving them of liquidity)

Counter arguments that came up in discussion:

1. • Refunds are only useful in the case where a node's capacity / availability changes unexpectedly anyway. In normal operation most transfers should succeed.
   • How big is the average transfer / a node can theoretically implement policies to prevent overly large payments.
   • In the current implementation a single channel between two nodes supports up to 160 pending payments.
2. This can most likely be better solved by multi-path payments and / or retrying stalling payments early
3. If an attacker can control the forward direction of a payment it isn't unlikely that they could do the same for the return path and therefore equally block a refund.

Outcome

In principle we are free to remove refunds, however Heiko would like to have a short analysis about the impact removing them has on each of the major use-cases that are seen as relevant for Raiden (e.g. payment hubs, exchanges, defi "backbone", lending, regular user payments, etc.).

[GataKamsky]

@ulope don't forget to make and document your decision here.

[ulope]

After more internal discussions I got assigned the task of deciding on this.

For all the reasons listed above the decision is to remove the current refunds implementation and all the complexity it brings with it.

If at some point we do discover a use case that would have a significant benefit from refunds we can think about a less intrusive implementation at that point (there's no obvious candidate for such a use-case at this point).