MD-14 #14
MD-14 #14
Conversation
| 4. Remove dependency of the Bridge Relayer on processing the desired timelock. | ||
|
|
||
| ### D1: Initiator Contract Timelock is a constant or a modifiable state with a minimum time | ||
| **User Journey**: Whenever Timelock is consumed, it is consumed as `timelock * 2`. If a modifiable state, it should be at least 12 hours. |
There was a problem hiding this comment.
So, the idea here is to not relay any timestamp information in, right?
Instead we simply assume the bridge relay has sent the time-lock information over as quickly as it can and use the timestamp from the destination chain when the relay transaction is received.
This removes the trust on any clock in the bridge service, thus making it harder to manipulate.
The tradeoff is perhaps that the attacker can now attack by forcing delays on the bridge. But, these could be easier to detect than lock manipulations.
There was a problem hiding this comment.
This is one reason why we need a minimum time bound. Maybe an upper bound might be necessary just so that a user couldn't have funds stuck in the bridge for type(uint).max time
There was a problem hiding this comment.
As in the difference between the reported timestamp and the timestamp at the time the relay transaction is received?
There was a problem hiding this comment.
timelock = 20
initiator receiving a bridge at time 0
counterparty lock is called at 5
initiator completes at 10
counterparty completes at 15
It would be an issue if:
iinitiator receiving a bridge at time 0
counterparty lock is called at 21
counterparty completes at 40
initiator cancels at 41
This is already an issue with the current implementation if the Bridge Relayer fails at some certain levels.
There was a problem hiding this comment.
minimum time bound
Only makes sense when you have quite short timelocks and the actual act of calling over the network could cause them to expire incorrectly.
|
For D1 and D2, you want to essentially make an assumption about the liveness of the bridge as opposed to the infallibility of the relayed time-lock, right? |
@0xPrimata this would not be call for an MIP though. This would be an issue with the current implementation as opposed to the proposed design. |
Well, both make an assumption about the liveness of the bridge, I'm just removing the infallibility of the relayed time-lock |
Not really. If you make an assumption about the relayed timestamp being trustworthy, then that timestamp will always reflect the correct time from which to offset the lock s.t. will have enough time for the counterparty to claim. If you don't have that timestamp, you're assuming that the bridge relayed the lock quickly s.t. the counterparty has enough time to claim. |
Summary
MD-14