bitcoindevkit / bdk / 21327282333

79%

push

github

Merge bitcoindevkit/bdk#2037: Add median-time-past (MTP) calculation to CheckPoint

b6235360e feat(core): add median-time-past calculation to CheckPoint (志宇)

Pull request description:

  ## Description

  This PR adds the ability to calculate median-time-past (MTP) for `CheckPoint` structures, implementing the functionality described in #2036.

  ## Notes to the reviewers

  `CheckPoint::median_time_past` calculates the MTP value by looking at the previous 11 blocks (including the current block).

  ### Why `ToBlockTime` is a separate trait from `ToBlockHash`

  `ToBlockTime` is intentionally kept as a separate trait with a non-optional return type (`fn to_blocktime(&self) -> u32`).

  For operations like MTP calculation, block times are either fully available or the calculation is meaningless — there's no useful "partial" or "best-effort" result. By using a separate trait, we get compile-time guarantees: methods like `median_time_past()` use `where D: ToBlockTime` bounds, making it explicit which checkpoint data types support time-based operations. Types without block time data (e.g., `BlockHash`, `BlockId`) simply don't implement the trait.

  #### How this differs from `prev_blockhash`

  In contrast, `prev_blockhash() -> Option<BlockHash>` is a method on `ToBlockHash` rather than a separate trait. The `Option` return serves a different purpose — it allows graceful degradation. A `CheckPoint<BlockId>` chain is still useful even without hash linkage validation; callers can simply skip verification when `None` is returned. Additionally, `None` at genesis is semantically meaningful (it marks the chain root), not an error condition.

  For MTP, there's no equivalent "skip if unavailable" — you either have all 11 timestamps or the calculation fails. This binary requirement is better expressed as a trait bound than runtime `Option` handling.

  ## Changelog notice

  ### Added
  - Introduced `ToBlockTime` trait for types t... (continued)

378 of 512 branches covered (73.83%)

Branch coverage included in aggregate %.

15 of 18 new or added lines in 1 file covered. (83.33%)

4254 of 5352 relevant lines covered (79.48%)

3344.56 hits per line