The signature: what a receipt proves and what it leaves open

Why it matters

Every published brief on Kitalpha has a receipt on the public ledger. The receipt for the newest FOMC brief carries a ledger id beginning 951dae65, a content hash beginning eef0adc82fbb… and a signing key beginning 49326fb2fc3e…, and the ledger page re-checks the signature against the published key every time it is opened. Suppose that check passes. Does a passing check mean the decision the brief describes is correctly reported, or that the figures in it are right? The honest answer is narrower than most readers expect, and knowing exactly how narrow is the whole of this lesson.

The concept

A hash is a fingerprint of a piece of text. A hash function takes any input, from one sentence to a whole book, and produces a short string of fixed length called a digest. The same input gives the same digest every time; a different input, even one that differs by a single character, gives a digest that looks unrelated to the first; and there is no way to run the function backwards and recover the text from its digest. Kitalpha’s receipts use SHA-256, whose digest is 256 bits long and is written as 64 hexadecimal characters. Hexadecimal is counting in base sixteen with the symbols 0 to 9 and a to f, so each character stands for four bits. The hash is computed over the brief’s canonical text, meaning the text in one agreed form, so that anyone who hashes the same brief gets the same digest.

A hash is often mistaken for encryption, and the two are opposites in the way that matters here. Encryption scrambles text so that only the holder of a key can read it, and it is reversible with that key. A hash hides nothing: the brief stays public beside its hash, no key is involved in computing it, and nothing reverses it. Its job is comparison. With a text and a digest both in hand, recomputing the digest and comparing tells whether the text is the one that was fingerprinted.

A digital signature adds the question of who. A signature scheme uses a pair of keys: a private key, kept by the signer, and a public key, published for everyone. The signer runs the private key over the content to be signed and gets a signature, another short string. Anyone holding the public key, the content and the signature can check whether the three fit together. The check fails if any character of the content differs from what was signed, and it fails if the signature was made with a different private key. Kitalpha signs with Ed25519, a widely used scheme whose public keys are 32 bytes, written as 64 hexadecimal characters, and it publishes its public key at a fixed address that every receipt links.

Put the two together and a passing check establishes exactly two things. Origin: the signature was made by whoever holds the private key matching the published public key. Integrity: the signed content, which carries the brief’s hash and so pins down the brief’s text, is unaltered since it was signed. That is the entire claim.

What the check leaves open is truth. Signing reads no figure, opens no source and compares nothing with the world. A brief with a mistyped number signs exactly as well as a correct one, and the signature would faithfully attest that the mistaken text is what was published. Whether the figures are right is answered at other layers: the evidence spans that tie each claim to a quoted source, the brief’s own groundedness figure, and the live source check the ledger page runs, which the next lesson takes up. The comparison below sets the two lines side by side for the live FOMC receipt; look for how short the third row is next to everything a reader might wish it covered.

Worked example

Take the FOMC receipt, which signs the brief titled "FOMC Raises Federal Funds Rate to 3-3/4 to 4 Percent in Unanimous 12-0 Vote" and sits on the ledger under the id beginning 951dae65. The ledger page prints the content hash and the public key in full. The steps below count the characters of each as printed, convert the counts into bits and bytes, and read the number of cited sources the receipt lists. The two character counts are stated in the step labels rather than computed from the record, because they are fixed by the algorithms and can be checked by counting on the page.

Three things to read off the steps. The hash is the same few dozen bytes for every brief, however long the text, which is the mark of a fingerprint rather than a copy. The public key is the same size again: a signature scheme works on these small fixed-length objects, never on the brief directly. And the sources line shows what else the signature covers: the list of cited addresses and each one’s status at signing. Nothing in any step read a figure inside the brief, and nothing in the signing process did either.

Faded example

Now the second record: the WPSR receipt, which signs the brief titled "EIA Weekly Petroleum Status Report — Week Ending September 11, 2026" and carries a content hash beginning cbe0ea6389ee…. WPSR is the Weekly Petroleum Status Report, a weekly release of the U.S. Energy Information Administration, so this brief is on a different subject and has a different length from the FOMC one. The first two steps are given. Complete the last: how many bits long is this receipt’s hash?

Retrieval check

Mark your confidence before each answer. Every option carries an explanation; read the ones you rejected too, since two of the distractors are the exact errors this lesson targets.

Your summary