Check a passport against the Bitcoin blockchain

The specification

Frozen under the name dpplive-anchor-v1. Any change to it gets a new name, and proofs already issued keep verifying under the old one.

What is committed

Not the raw document hash. The full published version contains fields the public view strips (chemical detail, supplier chain, importer EORI), so an outsider could never recompute that hash — a proof nobody can check is worth nothing. Instead each version commits to a small manifest binding both views:

manifest = {
  "alg":           "dpplive-anchor-v1",
  "full_sha256":   sha256(canonicalJson(full published version)),
  "public_sha256": sha256(canonicalJson(public projection)),
  "published_at":  "YYYY-MM-DD HH:MM:SS",   // UTC, verbatim from the database
  "upid":          "...",
  "version":       n
}

commitment = sha256(canonicalJson(manifest))

A buyer hashes the public JSON they can actually see, matches public_sha256, and walks the rest. full_sha256 rides along so the unredacted document can still be proven later in a dispute — against a commitment made before the dispute existed. The manifest itself leaks nothing: two hashes, an identifier, a version, a date.

The public projection is frozen at anchor time and served back verbatim at /anchor/<UPID>/manifest.json’s sibling field public_json. It has to be: the list of fields DPPLive publishes changes as the regulation and our own review of it change, and re-deriving the hash from today’s list would make every older proof read as “does not match” — a false accusation against a passport nobody touched. So this page hashes the frozen copy, then separately compares it against the live passport and tells you which of the two kinds of difference it found: a changed value (the record moved — a real problem) or only a changed set of visible fields (we changed what we publish).

Past versions are not enumerable. Asking for ?v=N requires also presenting that version’s commitment, which anyone holding the proof already has. Without that, this endpoint would hand out every passport’s complete edit timeline to anyone who counted upwards.

canonicalJson

canonicalJson(v) = JSON.stringify(sort(v))
  sort(array)  = array.map(sort)                       // order preserved
  sort(object) = keys sorted ascending (UTF-16 code units), values sorted recursively
  sort(other)  = unchanged

Merkle tree

leaf(c)    = SHA256( 0x00 || c )          c = 32-byte commitment
node(l, r) = SHA256( 0x01 || l || r )
odd node   = promoted unchanged to the next level (never duplicated)
leaf order = commitments sorted ascending as lowercase hex
root of one leaf = that leaf

The 0x00/0x01 prefixes stop an internal node being passed off as a leaf (the standard second-preimage attack on naive Merkle trees). Promoting the odd node instead of duplicating it avoids Bitcoin’s own CVE-2012-2459 ambiguity, where two different trees can produce one root.

A path step records where the sibling sits: {"d":"l","h":…} → next = node(h, cur); {"d":"r","h":…} → next = node(cur, h).

Anchoring

The root is submitted to four independent OpenTimestamps calendars every six hours. They aggregate it with everyone else’s digests into a single Bitcoin transaction and pay for it themselves — there is no wallet, no gas, and no private key anywhere in this system. Once the transaction confirms (typically 1–6 hours) we upgrade the pending proof into a permanent one and stop depending on the calendars at all.