Skip to content

Time-anchored attestations: sign a payload against a recent block hash, publish for an upper bound #470

Description

@Zyrtnin

A small primitive that keeps coming up whenever someone wants an off-chain fact to be verifiable later: "this was signed by key K, after block N, and before block M."

The mechanism

  1. Include a recent block hash in the signed payload. The hash was unpredictable before that block existed, so the signature provably postdates it. That is a real lower bound on time, obtained without trusting anyone's clock — including the signer's.
  2. Publish the attestation on-chain. Confirmation in block M gives the upper bound.

The result is a cryptographically bounded time window, rather than a self-reported timestamp from a clock the claimant controls. Radiant is well suited to it: blocks are frequent, and a Glyph is a natural carrier (a mutable NFT would let a series accrue under one identity).

Why it is worth a primitive rather than a recipe

The parts already exist — signing, block headers, Glyph minting — but the ordering is what makes it sound, and it is easy to get wrong:

  • signing a timestamp instead of a block hash proves nothing
  • using a block hash that is too old widens the window uselessly
  • omitting the payload hash from the signature lets the attestation be re-pointed at different content later

Bundling attest(payload, block_hash) -> signed bytes and verify(attestation, headers) -> (lower, upper) puts the ordering in one place with tests, the same argument as fee_sizing owning the fee rule.

Explicitly out of scope: location

Worth writing down, because it is the thing people expect this to do. A signature proves key custody, not position. If a key is extracted, attestations can be produced anywhere. Radio proximity does not fix it either — relay attacks defeat "the signal only carries a few km" exactly as they defeat keyless car entry, and distance-bounding needs nanosecond timing that low-bandwidth long-range radio cannot provide.

Location is attested by whoever holds the key and runs the site. That is a trust arrangement, not a proof, and the API should not imply otherwise.

Binding external evidence

The payload can include a hash of an external artifact (a photo, a log, a file). That binds the artifact to the attestation: it cannot be swapped or edited afterwards without breaking the signature, and it inherits the time window. A SHA-256 is 32 bytes, so this stays comfortably inside a single low-bandwidth frame — see #469 for why frame size matters on constrained transports.

Relationship to the offline case

Signing needs no network. Only two things do: obtaining a recent block hash, and publishing the result. Both are small enough to cross a constrained link, so a site with no internet can still produce attestations with a real time window — the same "transport, not trust" shape as #469.

Status

Design note only. No consumer has asked for it yet; per the WAVE precedent in docs/solutions/design-decisions/wave-protocol-deferred-until-consumer.md, the trigger for building it is a concrete caller, not the idea being good.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions