Evidence records and fingerprints
How every answer from a source is recorded and fingerprinted, and how the whole set is sealed with one digest.
#Plain languageIn plain terms
Anyone can make a claim about a blockchain. What makes a claim checkable is the record behind it. For every question Forensia asks a source, it keeps exactly what was asked and a fingerprint of exactly what came back.
A fingerprint is a short code computed from the response. Change one character of the response and the fingerprint changes completely. Then all the records are sealed together under one fingerprint for the whole lookup. If any record is altered later, the seal no longer matches.
#How it worksHow it works
- Write out the request exactly as it will be sent, and fingerprint it.
- Send it and read the response within the size limit.
- Fingerprint the response bytes exactly as received.
- Store a record: what was asked, who answered, the status, the sizes, and both fingerprints.
- Sort all records, write them out in a fixed form, and fingerprint that. This is the snapshot fingerprint.
#Technical detailThe exact rules
Fingerprints are SHA-256, written in hex. The response is hashed as received. It is not reformatted or re-serialised first, so the fingerprint matches the provider's bytes.
| Field in a capture | Meaning |
|---|---|
transport | json-rpc or http-get |
endpointHost | The host that actually answered, including a fallback |
operation | The method name. A batch joins its methods with + |
request, requestDigest, requestBytes | The request text, its SHA-256 and its size |
responseBytes, httpStatus, mediaType | Size, status and content type of the response |
preservation | sha256-manifest |
Record identifiers are built from the fingerprints, so two different responses can never share an identifier.
rpc:<method>:<first 8 of request digest>:<first 12 of response digest>
source:bitcoin:<method>:<first 12 of response digest>
rpc:network_resolution:<network>:<first 12 of response digest>
rpc-miss:<method>:<24 hex characters>:<first 12 of response digest>An rpc-miss record is an earlier "no record" answer to a transaction or receipt lookup by hash, kept when another configured source was then asked. Its 24 hex characters are a hash of the network, the request, the answering host, the capture time and its position, so identical "no record" bytes from two sources still get separate records. A miss kept during network detection and one kept during the main lookup get different identifiers. These records are part of the snapshot fingerprint like any other. They show what one source said, not that the transaction is absent.
The snapshot fingerprint
- Sort the records by identifier.
- Write each as an object with its fields in a fixed order: id, method, digest, retrievedAt, status, detail, capture.
- Serialise the list as JSON with no extra whitespace.
- Take the SHA-256 of that text.
The manifest format is versioned as chainproof.evidence-manifest.v2. The browser recomputes the same digest independently before it saves or exports anything.
Failed requests are recorded too. An error response gets a fingerprint and a record marked unavailable. A request that never gets a response, such as a timeout or a dropped connection, has no bytes to fingerprint and leaves no capture. The provider's own error text is never shown, because providers sometimes echo credentials in error messages.
#LimitsWhat it does not tell you
- There is no digital signature or trusted timestamp on the snapshot. The digest shows internal consistency, not who created it or when.
- A fingerprint cannot recover a response. If the raw bytes were not kept, they are gone.
- A later request to the same source may return different content, and that is normal on a moving chain.