Add Bridge Counterparty Hash Verification

[Primata]

Summary

• RFCs: Link to RFC, Link to RFC, or $\emptyset$.
• Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

counterparty has to hash the bridgeTransferId components to check if its produced by the correct parameters For that to happen two things have to be added. One is the nonce on initiator has to be emitted and used as a parameter in lock call Two the initiate block.timestamp has to be emitted and used as a parameter in lock call With that we can produce the same hash on both sides

Changelog

Added the requirements above.

Testing

Not tested

Outstanding issues

Testing

[franck44]

I am not a reviewer but I an arguing against this PR:

• first, the issue is not clearly described: counterparty has to hash the bridgeTransferId components to check if its produced by the correct parameters. What does that mean? What is the problem exactly?
• second, the changes in the Solidity code are not justified.
• third, producing the same hash on both sides (I don't even understand exactly what that is, but I guess: the contracts on the Move side, correct?) would require both sides to sync on the values of the nonces., which is not guaranteed.

Overall, these unjustified changes do not improve the security of the bridge but rather create more problems (sync of the nonces).

[Primata]

@franck44 see that this PR accompanies a PR to aptos-core, it would also update the bridge move modules.

1. By hashing the same values, Counterparty can verify that the lockBridgeTransfer call is using the correct parameters. This prevents bugs where the Relayer inputs incorrect values.
2. I can improve on why they should be implemented.
3. Sides of the bridge are initiator and counterparty. The nonce is emitted by the initiator as is to be used on the counterparty. Same thing for the initiateTimestamp.
4. By also using initiateTimestamp in the keccak256, lock sets time_lock to a point in where it prevents the exploit I described yesterday that we discussed. It pairs initiator and counterparty starting time.

[franck44]

@franck44 see that this PR accompanies a PR to aptos-core, it would also update the bridge move modules.

1. By hashing the same values, Counterparty can verify that the lockBridgeTransfer call is using the correct parameters. This prevents bugs where the Relayer inputs incorrect values.
2. I can improve on why they should be implemented.
3. Sides of the bridge are initiator and counterparty. The nonce is emitted by the initiator as is to be used on the counterparty. Same thing for the initiateTimestamp.
4. By also using initiateTimestamp in the keccak256, lock sets time_lock to a point in where it prevents the exploit I described yesterday that we discussed. It pairs initiator and counterparty starting time.

@0xPrimata A PR for this potential problem is premature and we may move this discussion into an issue to discuss the impact of the changes first.

[andyjsbell]

Agreed, please create issue @0xPrimata

I would also vote on closing this PR until we have consensus on this in the issue