phantom/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-01-24 18:23:26 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Merge bitcoin/bitcoin#30647: Move maximum timewarp attack threshold back to 600s from 7200s
Some checks failed
CI / test each commit (push) Has been cancelled
Details
CI / macOS 13 native, x86_64, no depends, sqlite only, gui (push) Has been cancelled
Details
CI / Win64 native, VS 2022 (push) Has been cancelled
Details
CI / ASan + LSan + UBSan + integer, no depends, USDT (push) Has been cancelled
Details

Browse source 
16e95bda86 Move maximum timewarp attack threshold back to 600s from 7200s (Matt Corallo)

Pull request description:

  In 6bfa26048d the testnet4 timewarp attack fix block time variation was increased from the Great Consensus Cleanup value of 600s to 7200s on the thesis that this allows miners to always create blocks with the current time. Sadly, doing so does allow for some nonzero inflation, even if not a huge amount.

  While it could be that some hardware ignores the timestamp provided to it over Stratum and forces the block header timestamp to the current time, I'm not aware of any such hardware, and it would also likely suffer from random invalid blocks due to relying on NTP anyway, making its existence highly unlikely.

  This leaves the only concern being pools, but most of those rely on work generated by Bitcoin Core (in one way or another, though when spy mining possibly not), and it seems likely that they will also not suffer any lost work. While its possible that a pool does generate invalid work due to spy mining or otherwise custom logic, it seems unlikely that a substantial portion of hashrate would do so, making the difference somewhat academic (any pool that screws this up will only do so once and the network would come out just fine).

  Further, while we may end up deciding these assumptions were invalid and we should instead use 7200s, it seems prudent to try with the value we "want" on testnet4, giving us the ability to learn if the compatibility concerns are an issue before we go to mainnet.

ACKs for top commit:
  fjahr:
    tACK 16e95bda86
  achow101:
    ACK 16e95bda86
  murchandamus:
    crACK 16e95bda86

Tree-SHA512: ae46d03b728b6e23cb6ace64c9813bc01c01e38dd7f159cf0fab53b331ef84b3b811edab225453ccdfedb53b242f55b0efd69829782657490fe393d24dacbeb2
This commit is contained in:
Ava Chow 2024-08-19 15:15:02 -04:00
commit d79ea809d2
No known key found for this signature in database
GPG key ID: 17565732E08E5E41
1 changed files with 1 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
src/validation.cpp
View file

@ -112,15 +112,7 @@ static constexpr int PRUNE_LOCK_BUFFER{10};
* block of a difficulty adjustment period is allowed to
* be earlier than the last block of the previous period (BIP94).
*/
static constexpr int64_t MAX_TIMEWARP{MAX_FUTURE_BLOCK_TIME};
/**
* If the timestamp of the last block in a difficulty period is set
* MAX_FUTURE_BLOCK_TIME seconds in the future, an honest miner should
* be able to mine the first block using the current time. This is not
* a consensus rule, but changing MAX_TIMEWARP should be done with caution.
*/
static_assert(MAX_FUTURE_BLOCK_TIME <= MAX_TIMEWARP);
static constexpr int64_t MAX_TIMEWARP = 600;
GlobalMutex g_best_block_mutex;
std::condition_variable g_best_block_cv;