Restrict timestamp when mining a diff-adjustment block to prev-600 #15481

1. 
   TheBlueMatt commented at 11:08 pm on February 25, 2019: member

   This prepares us for a potential future timewarp-fixing softfork by ensuring that we always refuse to mine blocks which refuse to exploit timewarp, no matter the behavior of other miners. Note that we allow timestamp to go backwards by 600 seconds on the difficulty-adjustment blocks to avoid bricking any existing hardware which relies on the ability to roll nTime by up to 600 seconds.

   Note that it is possible that the eventual softfork to fix timewarp has a looser resetriction than the 600 seconds enforced here, however it seems unlikely we will apply a tighter one, and its fine if we restrict things further on the mining end than in consensus.

2. fanquake added the label Mining on Feb 25, 2019
3. TheBlueMatt force-pushed on Feb 25, 2019
4. TheBlueMatt force-pushed on Feb 25, 2019
5. TheBlueMatt force-pushed on Feb 26, 2019
6. TheBlueMatt force-pushed on Feb 26, 2019
7. 
   gmaxwell commented at 9:57 am on February 26, 2019: contributor

   Concept ACK.

   Travis failure looks like some kind of timeout.

8. TheBlueMatt force-pushed on Feb 26, 2019
9. in test/functional/test_runner.py:182 in 1d72dd8b2d outdated

   160@@ -161,6 +161,7 @@
   161     'rpc_bind.py --ipv6',
   162     'rpc_bind.py --nonloopback',
   163     'mining_basic.py',
   164+    'mining_timewarp_fork.py',
   

   ---

   ---

   

   MarcoFalke commented at 9:51 pm on February 26, 2019:

   The test takes a long time, so better move it up to approx where mining_getblocktemplate_longpoll is
10. in test/functional/mining_timewarp_fork.py:29 in 1d72dd8b2d outdated

    24+        self.setup_clean_chain = True
    25+
    26+    def run_test(self):
    27+        self.log.info('Create some old blocks')
    28+        block_1 = self.nodes[0].generate(1)[0]
    29+        for i in range(2013):
    

    ---

    ---

    

    practicalswift commented at 10:05 pm on February 26, 2019:

    Nit: for _ in range(2013) is more idiomatic when the index is unused :-)

    ---

    

    jnewbery commented at 4:36 pm on February 27, 2019:

    Any reason not to generate all blocks with a singe call here: self.nodes[0].generate(nblocks=2013)?
11. TheBlueMatt force-pushed on Feb 27, 2019
12. 
    DrahtBot commented at 7:04 pm on February 27, 2019: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    No conflicts as of last run.

13. 
    TheBlueMatt commented at 2:04 pm on June 6, 2019: member

    Travis failures are wholly unrelated to this PR, it seems.
14. in test/functional/mining_timewarp_fork.py:29 in bdb43723ca outdated

    24+        self.setup_clean_chain = True
    25+
    26+    def run_test(self):
    27+        self.log.info('Create some old blocks')
    28+        block_1 = self.nodes[0].generate(1)[0]
    29+        for _ in range(2013):
    

    ---

    ---

    

    jnewbery commented at 2:11 pm on June 6, 2019:

    Any reason not to generate all blocks with a singe call here: self.nodes[0].generate(nblocks=2013)?

    ---

    

    TheBlueMatt commented at 2:29 pm on June 6, 2019:

    The call times out if you do that.
15. fanquake added this to the "Chasing Concept ACK" column in a project

    ---

16. in test/functional/mining_timewarp_fork.py:43 in bdb43723ca outdated

    38+        mining_info = self.nodes[0].getmininginfo()
    39+        assert_equal(mining_info['blocks'], 2015)
    40+        assert_equal(mining_info['currentblocktx'], 0)
    41+        assert_equal(mining_info['currentblockweight'], 4000)
    42+
    43+        self.restart_node(0)
    

    ---

    ---

    

    jnewbery commented at 2:55 pm on June 18, 2019:

    Why restart node here? Is this just to reset mocktime? Can you call setmocktime(0)?

    ---

    

    TheBlueMatt commented at 7:32 pm on December 4, 2019:

    Its just easier than trying to figure out what the current time is and then make sure that its correct?
17. DrahtBot added the label Needs rebase on Sep 17, 2019
18. Restrict timestamp when mining a diff-adjustment block to prev-600

    This prepares us for a potential future timewarp-fixing softfork by
    ensuring that we always refuse to mine blocks which refuse to
    exploit timewarp, no matter the behavior of other miners. Note that
    we allow timestamp to go backwards by 600 seconds on the
    difficulty-adjustment blocks to avoid bricking any existing
    hardware which relies on the ability to roll nTime by up to 600
    seconds.
    
    Note that it is possible that the eventual softfork to fix timewarp
    has a looser resetriction than the 600 seconds enforced here,
    however it seems unlikely we will apply a tighter one, and its fine
    if we restrict things further on the mining end than in consensus.

    584a7d459c
19. TheBlueMatt force-pushed on Dec 4, 2019
20. DrahtBot removed the label Needs rebase on Dec 4, 2019
21. 
    TheBlueMatt commented at 3:40 am on July 29, 2020: member

    I haven’t worked on any consensus cleanup logic in some time, and it seems unlikely to be picked back up. Until there’s a direction there, this probably doesn’t make sense.
22. TheBlueMatt closed this on Jul 29, 2020

    ---

23. fanquake deleted a comment on Jul 29, 2020
24. jnewbery removed this from the "Chasing Concept ACK" column in a project

    ---

25. DrahtBot locked this on Feb 15, 2022

Contributors
TheBlueMatt gmaxwell MarcoFalke practicalswift jnewbery DrahtBot

Labels
Mining