Module blocktrail 

Blocktrails trails as a verifier reads them.

A trail is an ordered list of states, each committed to by one mark: a Bitcoin output whose key is the trail’s base key tweaked by every state so far (Blocktrails Core, “the rule as it is”, blocktrails/spec ef54a08). The marks spend one another in order, so the trail is anchored: each state is timestamped by the block that confirms its mark, and nobody can rewrite the history without spending a mark again.

This module holds three things:

• Blocktrail: the blocktrails.json shape, as the git-mark profile (blocktrails/spec, profiles/gitmark §5.2) and blocktrails/git-mark b852d7d trail() write it: @type, version, profile, pubkeyBase, chain, states, and txo, a list of TXO URIs. It also reads the earlier shape this crate wrote (@id, genesis and txo entries of the form {outpoint, blockheight}), and writes such entries back unchanged, so no file already on disk is rewritten.
• BlocktrailTxo: one TXO URI, txo:<chain>:<txid>:<vout>?amount=<sats>&commit=<hash>[&pubkey=<x>], parsed and formatted as blocktrails/git-mark parseTxoUri / formatTxoUri do.
• With feature mrc20, the per-link verification blocktrails/verify 043e7af runs: every mark’s output key is recomputed from the base key and the states (walk_blocktrail); then each mark’s transaction must exist, carry the recomputed key, be confirmed, match its recorded amount and spend the previous mark (verify_blocktrail). The verdict is verified when every commitment was checked and holds, confirmed when the marks are on-chain but the commitments could not be checked (no base key, say), and partial otherwise. verify_anchor_chain runs the same checks from a single head outpoint backwards, for trails that keep only their head (the MRC20 trails this crate issues).

Every link is checked, not the head alone. A head UTXO at the derived address shows only that someone paid that key; it says nothing about the marks before it, which could be missing, pay other keys, or not be spent in order. Only the walk shows that each state was committed, and timestamped, when its mark was made.

Structs

Blocktrail

A trail as blocktrails.json carries it: what a verifier reads.

BlocktrailTxo

One mark of a trail: the output that commits to a state.

MarkReport

What a verifier found for one mark, with the evidence behind its status.

TrailReport

The result of verifying a trail: one MarkReport per mark and a TrailVerdict.

TxoUriError

A TXO URI that could not be read.

Enums

MarkStatus

What a verifier found for one mark.

TrailVerdict

The summary verdict over a whole trail.

Constants

BLOCKTRAIL_TYPE

The @type every trail carries.

BLOCKTRAIL_VERSION

The version blocktrails/git-mark b852d7d writes in blocktrails.json.

DEFAULT_PROFILE

The profile a trail with no profile is read as (blocktrails/verify).

GITMARK_NETWORK

The network name whose addresses use the gm human-readable part: the sidestr git-mark chain (NETWORK_CHAIN.gitmark = 'sidestr:gitmark' in blocktrails/git-mark b852d7d).

GITMARK_PROFILE

The git-mark profile: each state is a git commit hash, hashed as its text.

Functions

is_gitmark_commit

Whether commit is a git commit hash a git-mark trail accepts as a state: 40 lowercase hex characters (blocktrails/git-mark validateCommitHash), or 64 for a repository using SHA-256 object names (and for an epoch Merkle root this crate anchors in a commit’s place).

network_for_txo_chain

The network name (as mrc20::bt_address takes it) for a TXO URI chain token; the inverse of txo_chain_for_network.

txo_chain_for_network

The chain token a TXO URI uses for one of this crate’s network names.