nist-inject timestamps beacons so Bitcoin blocks get a two sided date

The script concatenates a beacon with block hashes and timestamps the file

The operation is narrow. Every few minutes the script grabs the latest NIST random beacon and a few block hashes from various chains, concatenates them, and timestamps the resulting file with OpenTimestamps.

Concatenation is what makes the timestamp meaningful for both chains at once. A beacon is a published random value whose own timing is anchored to NIST's process; block hashes are the identifiers of blocks that already exist. Binding them into a single document and timestamping that document means the timestamp attests to the pair, so the beacon's contents and the block identifiers are fixed at the same moment.

The chains involved are named in the repository description as the ETH, LTC and ZEC beacons alongside NIST, which is how the script has several chains to draw block hashes from rather than one.

The two directions are stated as a numbered pair

The README gives the purpose as exactly two claims, and the wording matters:

1. Timestamps the random beacons, proving they existed prior to a Bitcoin
   block.
2. Injects a commitment to the beacons into the Bitcoin chain, proving that
   Bitcoin blocks were created after the beacons.

The first direction runs from the beacons to the block: the timestamp shows the beacon file existed before the Bitcoin block that carries the commitment. The second runs from the block back to the beacons: the on-chain commitment shows those blocks were created after the beacons in question.

Neither direction is a clock reading. Both are ordering claims between published artifacts, which is the distinction that makes a beacon useful here rather than merely being a source of entropy.

Restamp supplies the other side of the bound

The bidirectional property is not achieved by this repository alone. The README states that in conjunction with the Restamp Project, hosted at github.com/opentimestamps/restamp, the result is evidence that can constrain when Bitcoin blocks were created both forwards and backwards in time.

So the division of labour is by direction: nist-inject pushes the timestamp and the on-chain commitment, and Restamp handles the reverse anchoring. Evaluating what this proves requires both, or at least an understanding of which side Restamp covers.

Both projects sit under the opentimestamps organisation, which is where the link in the README points. Nothing in the README describes Restamp's own mechanism, so the backward constraint has to be read at its source rather than inferred from here.

Four top level entries, one of which is the script

The repository is small enough that the layout is itself documentation. Top level entries are LICENSE, README.md, db/ and inject.sh.

`inject.sh` is the entire implementation. The README calls the project a simple script or bot, and that description holds at the file level: there is no package manifest, no language runtime dependency, no test directory and no configuration file. This is a shell script with a data directory beside it.

`db/` is where state lives. The README does not describe its contents or the format inside, so whether it holds previously fetched beacons, cached block hashes, or timestamp receipts is something you can only learn from the script itself. LICENSE is present and the repository is under the Unlicense, which places the code in the public domain rather than under a conventional license grant.

There is no documented cron line, so the cadence stays yours to verify

The README describes the script as running every few minutes but names no schedule, no unit of time and no configuration value for it. There is no crontab example, no systemd timer and no flag for the interval anywhere in the documentation.

That gap is not unusual for a script this size, but it means the period over which the evidence accumulates is set by whatever schedules the script rather than by the project. For a construction whose value comes from repeated timestamps across many Bitcoin blocks, the interval is a meaningful parameter, and it is one you set.

Similarly, the README does not document retry behaviour when the NIST beacon is unreachable, when a chain's API is unavailable, or when the timestamping service declines a request. How the script behaves in those cases is determined by the code in inject.sh.

No releases and no documentation of the timestamp format

There are no GitHub releases for this repository, so there is no version to pin and no changelog to consult. The repository is not archived, and the default branch is master rather than main.

The README is 93 words long and covers the mechanism, the two claims, and the Restamp link. It does not document the format of the timestamp file, the structure of the concatenated document, the ordering of the block hashes, or how the commitment is encoded into the Bitcoin transaction. It also does not state which API endpoints the script calls for each chain.

What this means for use is concrete: you can read the intent of the project in a minute, but you cannot configure or audit it from the README. Reading inject.sh is the only route to the specifics, and the surrounding evidence chain depends on those specifics being right.

Editorial conclusion

Read this as one half of a two part construction rather than a timestamping tool on its own. It only bounds when a Bitcoin block was created when paired with something that constrains the beacon side, which the project names as the Restamp Project. The repository is four entries, one script, one data directory, a license file and the README, and the README does not document how to configure the chain list, what file format the database holds, or what the exact timestamp format is, so plan on reading inject.sh before automating it. Verify the cadence yourself as well, since the README only says every few minutes without naming a schedule.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases