Restrict timestamp when mining a diff-adjustment block to prev-600#15481
Restrict timestamp when mining a diff-adjustment block to prev-600#15481TheBlueMatt wants to merge 1 commit intobitcoin:masterfrom
Conversation
TheBlueMatt
force-pushed
the
2019-02-600s-gbt
branch
4 times, most recently
from
0cc366b to
93359e5
Compare
|
Concept ACK. Travis failure looks like some kind of timeout. |
TheBlueMatt
force-pushed
the
2019-02-600s-gbt
branch
from
93359e5 to
1d72dd8
Compare
| def run_test(self): | ||
| self.log.info('Create some old blocks') | ||
| block_1 = self.nodes[0].generate(1)[0] | ||
| for i in range(2013): |
There was a problem hiding this comment.
Nit: for _ in range(2013) is more idiomatic when the index is unused :-)
There was a problem hiding this comment.
Any reason not to generate all blocks with a singe call here: self.nodes[0].generate(nblocks=2013)?
TheBlueMatt
force-pushed
the
2019-02-600s-gbt
branch
from
1d72dd8 to
bdb4372
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
|
Travis failures are wholly unrelated to this PR, it seems. |
There was a problem hiding this comment.
Why restart node here? Is this just to reset mocktime? Can you call setmocktime(0)?
There was a problem hiding this comment.
Its just easier than trying to figure out what the current time is and then make sure that its correct?
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.
TheBlueMatt
force-pushed
the
2019-02-600s-gbt
branch
from
bdb4372 to
584a7d4
Compare
|
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. |
7 participants
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.