Skip to content

consensus: make difficulty retarget windows contiguous (timewarp hardfork) - #442

Draft
kwsantiago wants to merge 4 commits into
bitcoinknots:29.x-knotsfrom
privkeyio:hf-timewarp
Draft

kwsantiago wants to merge 4 commits into
bitcoinknots:29.x-knotsfrom
privkeyio:hf-timewarp

Conversation

@kwsantiago

Copy link
Copy Markdown

Draft, for review. No activation height is set on any network, so this is inert as it stands.

The retarget at R measures time(R-1) - time(R-2016): 2016 blocks, 2015 intervals. The interval between R-1 and R is measured by nothing, and that gap is what the timewarp attack spends.

Two rules, on a new unscheduled buried deployment:

  • the retarget at R measures time(R-1) - time(R-2017), so consecutive windows share an endpoint
  • a block closing a period must satisfy time(H) >= time(H-2016)

Both are needed. Contiguous windows alone leave the Murch-Zawy residual: a negative span is credited as nPowTargetTimespan/4, and that 4x rise pays for two 4x drops. Alone, the schedule reaches 0.0156x of starting difficulty over 31 seconds of chain time; with both, 336 days.

The floor is BIP-54's non-negative-duration rule re-anchored to the corrected window. BIP-54's other rule becomes unnecessary, which drops its 7200s grace.

Enforced in ContextualCheckBlockHeaderVolatile so ConnectBlock re-runs it, and re-derived at startup by FindInheritedInvalidBlocks, as the BLAKE2b fork already does.

Hardfork: old nodes compute different nBits and split at activation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant