In the current implementation of the Raiden protocol, when a payment routing fails after some transfers, the already made hash time locks are left there until they expire. This consumed the channel capacity for quite some time. (The situation doesn't change whether or not RefundTransfer messages are sent.)

I think it's possible to free the channel capacity immediately (e.g. by adding removed lockhashes in the other side of the channel state). Is there a reason behind the current design?


It's a consequence of two things:

  • backtracking.
  • The split of the channel state, were each node can update only its own half of the channel state.

Consider the following topology:

      - C -
A - B       E
      - D -

If the channel C-E does not have enough capacity, the resulting route with backtracking would be A->B->C->B->D->E.

Knowing that, assume that C and D are actually controlled by an attacker. If the message from C->B is not a transfer, then the attacker could lie to B saying that there is no capacity on the channel C-E, and use the secret learned by D to unlock on-chain. To protected B from this, the message C->B has to be a transfer, which guarantees that if B->C happens, than C->B will also happen, effectively nullifying the attack.

Here is a proposal that would fix this problem: https://github.com/raiden-network/raiden-contracts/issues/1216 . Effectively, this proposal would make refund a shared value among the two participants.

  • The message from C->B can be also something that blocks the unlock of B->C. – yhirai Sep 4 '19 at 12:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.