You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
Activity
loredanacirstea commentedon Aug 17, 2018
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 commentedon Aug 17, 2018
I don't recall, this is what I can say about the expiration:
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 commentedon Aug 18, 2018
@hackaugusto
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 commentedon Aug 18, 2018
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:
se, wheree > sxblocks after the settlement window is over, we havee - (s + x)blocks to register the secret, if the secret is registered in that window then the payment from B will go to A2