Don't allow unlocking of locks whose expiration crosses settlement timeout

[LefterisJP]

We should enforce this in the smart contracts.

So inside the unlock() function of the smart contracts we should not allow unlocking of locks whose expiration is crossing the settlement timeout.

[loredanacirstea]

We do not currently enforce this.
We actually allow locks with an expiration > settlement timout and have a test for it : https://github.com/raiden-network/raiden-contracts/blob/master/raiden_contracts/tests/test_channel_unlock.py#L904-L910

@hackaugusto , I remember this was an edge case that you explained some time ago.
Can you add some details as to why this was/is still needed?

[hackaugusto]

I remember this was an edge case that you explained some time ago.
Can you add some details as to why this was/is still needed?

I don't recall, this is what I can say about the expiration:

• For a mediator receiving a larger expiration from the payer is actually good, that means the mediator has more time to register the secret on-chain, if required. The only requirement is for the mediator to use a lock expiration lower than the payer's channel settlement window for the transfer sent to the payee.
• For a target, receiving a larger expiration is also good, there are no requirements since the target doesn't forward a transfer.
• For a initiator, sending a transfer with a large expiration is okay, he doesn't benefit from it, but may be trying to attack the first hop in the path by sending a transfer with a large expiration and closing the channel.
• For a mediator, sending a transfer to the payee with a large expiration is not acceptable, it means the payer channel can be settled and the payee transfer will be still valid, so the mediator may end up paying to the payee and not getting payed by the payer, the fix is describe above.

To actually enforce a small expiration on-chain, we would need to add the start block in the lock structure, otherwise we don't know how large the expiration window was. With the current lock structure it is possible to reject lock's which still have an expiration larger than the settlement window while the channel was closed, that would mean the mediators and target nodes must reject transfers with a large expiration.

[nkbai]

@hackaugusto

For a mediator, sending a transfer to the payee with a large expiration is not acceptable, it means the payer channel can be settled and the payee transfer will be still valid, so the mediator may end up paying to the payee and not getting payed by the payer, the fix is describe above.

because the mediator can still unlock this transfer after the payer channel is settled, it's safe to send a transfer to the payee with large expiration.

[hackaugusto]

it's safe to send a transfer to the payee with large expiration.

Not necessarily, we do have indeed changed the order, and now unlocks are allowed after the settlement, but the unlock may be called by anyone, and it's possible for this to happen:

• An attacker A controls two nodes, A1 and A2, B is an honest node
• Mediated transfers ->A1->B->A2->
• Channel A1-B has a settlement period s
• B is an honest but misbehaving node, which sends a lock to A2 with an expiration e, where e > s
• The attacker learns the secret through A2 and holds it
• The attacker closes A1-B
• After the settlement window is over, the attacker calls settle, and unlock for it's own balance proof. At this point the secret is not revealed, therefor B wont get the payment
• Assuming settle and unlock execute on x blocks after the settlement window is over, we have e - (s + x) blocks to register the secret, if the secret is registered in that window then the payment from B will go to A2