Use Bitcoin Median time and Height for expiry/sweeping

[Kukks]

Summary

Use Bitcoin's Median Time Past (MTP) and block height for expiry/sweeping calculations instead of relying on system time, improving security and consistency with Bitcoin consensus rules.

Context

• Repo: arkade-os/arkd
• Component: internal/infrastructure/scheduler/gocron/service.go, internal/core/application/service.go, internal/core/application/sweeper.go
• Protocol phase: sweep, expiry
• Related code:
  • internal/infrastructure/scheduler/gocron/service.go#L46 — TODO comment about using chain mediantime
  • internal/core/application/service.go — expiry timestamp calculation
  • pkg/arkd-wallet/core/infrastructure/nbxplorer/service.go — already fetches Mediantime

Background

Currently, arkd supports two scheduling modes for expiry/sweeping:

1. BlockHeight-based: Uses blockTimestamp.Height + batchExpiry
2. UnixTime-based: Uses blockTimestamp.Time + batchExpiry.Seconds()

For UnixTime mode, the scheduler compares against time.Now() (system time) instead of Bitcoin's Median Time Past (MTP). This is a security concern because:

• System time can be manipulated by the operator or via NTP attacks
• Bitcoin's MTP is consensus-critical and resistant to timestamp manipulation
• Using MTP aligns with Bitcoin's own time-based validation rules (BIP-113)

The wallet already fetches Mediantime from NBXplorer's blockchain info, but the scheduler doesn't use it.

Technical Approach

1. Modify the scheduler interface to accept chain context (MTP, current height)
2. Update AfterNow() in gocron/service.go to use chain MTP instead of time.Now()
3. Refactor expiry calculations in service.go and sweeper.go to:
   • For height mode: current_height + expiry_blocks
   • For time mode: chain_mtp + expiry_seconds
4. Add configuration option to choose between height-based and time-based expiry (defaulting to height for better security)

Acceptance Criteria

• Scheduler uses chain MTP instead of system time for time-based expiry
• Both height-based and time-based modes tested with edge cases
• No regression in sweep scheduling accuracy
• Documentation updated for operator config

Cross-Repo Impact

• ts-sdk/go-sdk/rust-sdk: May need updates if they expose expiry scheduling config
• wallet: No direct impact (uses SDK APIs)

Complexity Estimate

Medium (1-2 days) — Requires careful testing of time-based edge cases

Suggested Assignee

louisinger or altafan — both familiar with the scheduler and sweeper internals

Related

• internal/infrastructure/scheduler/gocron/service.go#L46 — Existing TODO
• Bitcoin BIP-113 (MTP for transaction lock-time)