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
Currently, HTLC timeout timestamps (for USDC and EUR) are not checked for whether they are in the past. This allows Fastspot to potentially steal the user's funds:
Fastspot creates his HTLC with a timeout timestamp in the past. The user then creates his HTLC with a correct time or block in the future.
Fastspot now claims his own HTLC back via the timeout, and afterwards also claims the user's HTLC by revealing the swap secret. The user however, can not redeem Fastspot's HTLC with the swap secret anymore, as it had been refunded, and was also not able to refund his own HTLC to mitigate the attack because of his timeout in the future.
Timestamps are easy to check against the user's clock. Blocks could only be verified by fetching the current block from a block explorer, which is more likely a task for the Hub. The verification for blocks could thus be in the Hub, or the Hub could pass the current block height, which for Nimiq is already happening effectively via the validity start height, which is also already checked against the timeout.
There should be a certain safety buffer that timeouts and blocks are not only not in the past, but also don't timeout in the next few minutes.
The text was updated successfully, but these errors were encountered:
Currently, HTLC timeout timestamps (for USDC and EUR) are not checked for whether they are in the past. This allows Fastspot to potentially steal the user's funds:
Fastspot creates his HTLC with a timeout timestamp in the past. The user then creates his HTLC with a correct time or block in the future.
Fastspot now claims his own HTLC back via the timeout, and afterwards also claims the user's HTLC by revealing the swap secret. The user however, can not redeem Fastspot's HTLC with the swap secret anymore, as it had been refunded, and was also not able to refund his own HTLC to mitigate the attack because of his timeout in the future.
Timestamps are easy to check against the user's clock. Blocks could only be verified by fetching the current block from a block explorer, which is more likely a task for the Hub. The verification for blocks could thus be in the Hub, or the Hub could pass the current block height, which for Nimiq is already happening effectively via the validity start height, which is also already checked against the timeout.
There should be a certain safety buffer that timeouts and blocks are not only not in the past, but also don't timeout in the next few minutes.
The text was updated successfully, but these errors were encountered: