Skip to content

Commit

Permalink
Merge pull request #14 from Credshields/main
Browse files Browse the repository at this point in the history
Updated Timestamp_dependence
  • Loading branch information
jinsonvarghese authored Jun 11, 2024
2 parents 13dd9a7 + 48081c0 commit f429ca6
Showing 1 changed file with 33 additions and 10 deletions.
43 changes: 33 additions & 10 deletions 2023/en/src/SC03-timestamp-dependence.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,37 @@
# Timestamp Dependence
## Vulnerability: Timestamp Dependence

### Description
Contracts that depend on block timestamps for critical operations are susceptible to manipulation, as miners can slightly adjust the timestamps.
### Description:
Smart contracts on Ethereum often rely on block.timestamp for time-sensitive functions such as auctions, lotteries, and token vesting. However, block.timestamp is not entirely immutable because it can be adjusted slightly by the miner who mines the block, within a window of approximately 15 seconds according to Ethereum protocol implementations. This creates a vulnerability where a miner could manipulate the timestamp to their advantage. For instance, in a decentralized auction, a miner who is also a bidder could alter the timestamp to prematurely end the auction when they are the highest bidder, thereby securing an unfair win.

### Impact
This can lead to unfair advantages in games, easier puzzle solutions, and flawed randomness, all of which an attacker can exploit.
### Example:
```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
### Steps to Fix
1. Avoid reliance on `block.timestamp` or `now` for crucial contract functionalities.
2. Use `block.number` for time-keeping if needed, as it is harder to manipulate.
contract DiceRoll {
uint256 public lastBlockTime;
### Example
In a betting smart contract, if the outcome depends on a timestamp (like an even or odd timestamp deciding the winner), a miner could potentially manipulate the timestamp to affect the result.
constructor() payable {}
function rollDice() external payable {
require(msg.value == 5 ether, "Must send 5 ether to play"); // Player must send 5 ether to play
require(block.timestamp != lastBlockTime, "Only 1 transaction per block allowed"); // Ensures only 1 transaction per block
lastBlockTime = block.timestamp;
// Player wins if the last digit of the block timestamp is less than 5
if (block.timestamp % 10 < 5) {
(bool sent,) = msg.sender.call{value: address(this).balance}("");
require(sent, "Failed to send Ether");
}
}
}
```
### Impact:
- Smart contracts that use block timestamps for essential operations, such as timed executions, are susceptible to manipulation. Attackers can alter timestamps to trigger functions either prematurely or with delays, disrupting the intended outcomes. This can lead to issues like rewards being issued too early or necessary updates being postponed, destabilizing the contract's operations.
- By modifying block timestamps, attackers can exploit time-based mechanisms within contracts. For instance, in a lottery game, an attacker could adjust the timestamp to match specific conditions, increasing their chances of winning. Additionally, they could repeatedly execute functions in quick succession, potentially draining the contract's resources or gaining unfair advantages.
- Timestamp manipulation can facilitate front-running, where attackers execute transactions at strategically advantageous times before others. This predictability, influenced by their controlled timestamps, is particularly damaging in financial contexts. Such actions can result in significant losses for other participants while providing unfair gains to the attacker.

### Remediation:
- To mitigate the risks of timestamp manipulation and improve the accuracy and security of smart contracts, it is recommended to use trusted external time sources or multiple time sources. This approach can help ensure more reliable timing.
- If you need to use block.timestamp, consider adding a time buffer. For example, you could set a rule that an auction will only end when block.timestamp is greater than the auction end time plus an additional minute. This grace period makes it harder for miners to manipulate the end time, providing a fairer outcome for participants.

0 comments on commit f429ca6

Please sign in to comment.