BIP94: Change timewarp delta to 7200 seconds #1658

pull fjahr wants to merge 1 commits into bitcoin:master from fjahr:bip94-timewarp-delta changing 1 files +1 −1
  1. fjahr commented at 9:12 pm on August 5, 2024: contributor

    This aligns the BIP with the Bitcoin Core pull request and sets the allowed delta between the first block of the new difficulty period and the previous block to 7200 seconds (2 hours) instead of 600 seconds.

    See also the discussion in the PR: https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1704428831

  2. achow101 commented at 9:14 pm on August 5, 2024: member
    2 hours is 7200, not 720.
  3. fjahr force-pushed on Aug 5, 2024
  4. fjahr force-pushed on Aug 5, 2024
  5. Change BIP 94 timewarp delta to 7200 seconds 0c2a2172f7
  6. fjahr force-pushed on Aug 5, 2024
  7. fjahr commented at 9:36 pm on August 5, 2024: contributor

    2 hours is 7200, not 720.

    Fixed, also slightly changed the wording and added some additional explanation.

  8. fjahr renamed this:
    BIP94: Change timewarp delta to 720 seconds
    BIP94: Change timewarp delta to 7200 seconds
    on Aug 5, 2024
  9. murchandamus approved
  10. murchandamus commented at 5:41 pm on August 6, 2024: contributor
    LGTM
  11. murchandamus merged this on Aug 7, 2024
  12. murchandamus closed this on Aug 7, 2024

  13. Sjors commented at 9:40 am on August 8, 2024: member

    I’m curious about the original author’s take on this, @TheBlueMatt.

    Although we can always change the number later if this is proposed for mainnet, that would either complicate the consensus code with another if branch, or require us to drop / fork testnet4 (or hope we never hit an edge case).

    There’s two additional reasons that make the number 600 nice:

    1. When maximally exploited, it neatly offsets the off-by-one error in Satoshi’s code so that blocks actually happen every 10 minutes. See footnote [1] in the original BIP.

    2. “we limit the attack scenario to about a 0.1% inflation rate, much smaller than the historical inflation rate due to rapid hashrate growth” - what happens to that rate with this new value?

    Looking around a bit more, there’s a mailinglist post from 2018 Johnson Lau who called this number t:

    0 <= t <= infinity. With a bigger t, the fix is less effective but also less likely to cause intentional/unintentional split.

    He then considered that even “t=86400 (one day)” would probably be safe enough, so the choice of 7200 should be fine here.

    All that said, I think it makes sense to make it safe for honest miners to just use their system time when producing a block. Though even with this change I’m not sure if that’s really safe behavior.

    Our own code does the following (miner.cpp):

     0pblock->nTime = TicksSinceEpoch<std::chrono::seconds>(NodeClock::now());
     1...
     2UpdateTime(pblock, ...)
     3
     4
     5int64_t UpdateTime(CBlockHeader* pblock, ...)
     6{
     7    int64_t nOldTime = pblock->nTime;
     8    int64_t nNewTime{std::max<int64_t>(pindexPrev->GetMedianTimePast() + 1, TicksSinceEpoch<std::chrono::seconds>(NodeClock::now()))};
     9
    10    if (nOldTime < nNewTime) {
    11        pblock->nTime = nNewTime;
    12    }
    

    In other words, we pick the system time, and if needed bump it to MTP + 1.

    I think this would indeed get us in trouble under the timewarp rule if t=600, when the previous block is > 600 seconds in the future.

  14. TheBlueMatt commented at 4:14 pm on August 8, 2024: contributor
    I don’t think there’s much reason to care about miners being able to mine at their system time. Mining devices generally don’t have clocks that are robust anyway, they just roll nTime from where the mining work producer told them to start. And, indeed, like @Sjors points out, its nice to maximally restrict here.
  15. fjahr commented at 9:08 pm on August 8, 2024: contributor

    I don’t think there’s much reason to care about miners being able to mine at their system time. Mining devices generally don’t have clocks that are robust anyway, they just roll nTime from where the mining work producer told them to start.

    This seemed like a good idea to me at the time but I can’t really judge this since I don’t know the mining landscape enough. What time do the honest pools usually use then? I would have assumed they just use the easiest thing.

    We could still make the switch to 600 if there is a preference for it. There don’t seem to be any shenanigans on the network so far, I could sync fine with the 600 delta.

  16. Sjors commented at 7:08 am on August 9, 2024: member
    Maybe we should hash this out (haha) in a Delving or mailinglist post.
  17. TheBlueMatt commented at 5:36 pm on August 10, 2024: contributor
    If we even maybe want to use 600 on mainnet we should use testnet to test whether anyone’s stuff breaks :)
  18. murchandamus commented at 3:26 pm on August 15, 2024: contributor
    I find @TheBlueMatt’s points convincing, and must admit, that I have little insight into miners’ setups. My concern regarding the timestamp being limited 2h in the future and therefore honest miners potentially running out of a 10 minute range was a shot from the hip, and it would be better for miners to run into this concern on testnet than eventually on mainnet.
  19. murchandamus commented at 5:25 pm on August 15, 2024: contributor
    Nevermind, I just realized that #1660 was already opened ahead of my comment.

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-02 14:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me