OpenTimestamps Client

Command-line tool to create and validate timestamp proofs with theOpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.Additionally this package provides timestamping of PGP signed Git commits, andverification of timestamps for both Git commits as a whole, and individualfiles within a Git repository.

Requirements

• Python3

While OpenTimestamps can create timestamps without a local Bitcoin node, toverify timestamps you need a local Bitcoin Core node (a pruned node is fine).

Installation

Either via PyPi:

$ pip3 install opentimestamps-client

or from source:

$ python3 setup.py install

On Debian (Stretch) you can install the necessary system dependencies with:

sudo apt-get install python3 python3-dev python3-pip python3-setuptools python3-wheel

Usage

Creating a timestamp:

$ ots stamp README.md
Submitting to remote calendar https://a.pool.opentimestamps.org
Submitting to remote calendar https://b.pool.opentimestamps.org
Submitting to remote calendar https://a.pool.eternitywall.com

You'll see that README.md.ots has been created with the aid of three remotecalendars. We can't verify it immediately however:

$ ots verify README.md.ots
Assuming target filename is 'README.md'
Calendar https://alice.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
Calendar https://bob.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
Calendar https://finney.calendar.eternitywall.com: Pending confirmation in Bitcoin blockchain

It takes a few hours for the timestamp to get confirmed by the Bitcoinblockchain; we're not doing one transaction per timestamp.

However, the client does come with a number of example timestamps which you cantry verifying immediately. Here's a complete timestamp that can be verifiedlocally:

$ ots verify examples/hello-world.txt.ots
Assuming target filename is 'examples/hello-world.txt'
Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST

You can specify JSON-RPC credentials (USER and PASS) for a local bitcoin node like so:

$ ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify examples/hello-world.txt.ots
Assuming target filename is 'examples/hello-world.txt'
Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST

Incomplete timestamps are ones that require the assistance of a remote calendarto verify; the calendar provides the path to the Bitcoin block header:

$ ots verify examples/incomplete.txt.ots
Assuming target filename is 'examples/incomplete.txt'
Got 1 new attestation(s) from https://alice.btc.calendar.opentimestamps.org
Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST

The client maintains a cache of timestamps it obtains from remote calendars, soif you verify the same file again it'll use the cache:

$ ots verify examples/incomplete.txt.ots
Assuming target filename is 'examples/incomplete.txt'
Got 1 attestation(s) from cache
Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST

You can also upgrade an incomplete timestamp, which adds the path to theBitcoin blockchain to the timestamp itself:

$ ots upgrade examples/incomplete.txt.ots
Got 1 attestation(s) from cache
Success! Timestamp is complete

Finally, you can get information on a timestamp, including the actualcommitment operations and attestations in it:

$ ots info examples/two-calendars.txt.ots
File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb
Timestamp:
append 839037eef449dec6dac322ca97347c45
sha256
 -> append 6b4023b6edd3a0eeeb09e5d718723b9e
    sha256
    prepend 57d46515
    append eadd66b1688d5574
    verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
 -> append a3ad701ef9f10535a84968b5a99d8580
    sha256
    prepend 57d46516
    append 647b90ea1b270a97
    verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')

Timestamping and Verifying PGP Signed Git Commits

See doc/git-integration.md

Privacy Security

Timestamping inherently records potentially revealing metadata: the currenttime. If you create multiple timestamps in close succession it's quite likelythat an adversary will be able to link those timestamps as related simply onthe basis of when they were created; if you make use of the timestamp multiplefiles in one command functionality (./ots stamp <file1> <file2> ... <fileN>)most of the commitment operations in the timestamps themselves will beidentical, providing an adversary very strong evidence that the files weretimestamped by the same person. Finally, the REST API used to communicate withremote calendars doesn't currently attempt to provide any privacy, although itcould be modified to do so in the future (e.g. with prefix filters).

File contents are protected with nonces: a remote calendar learns nothingabout the contents of anything you timestamp as it only ever receives an opaqueand meaningless digest. Equally, if multiple files are timestamped at once,each file is protected by an individual nonce; the timestamp for one filereveals nothing about the contents of another file timestamped at the sametime.

Compatibility Expectations

OpenTimestamps is alpha software, so it's possible that timestamp formats mayhave to change in the future in non-backward-compatible ways. However it willalmost certainly be possible to write conversion tools for anynon-backwards-compatible changes.

It's very likely that the REST protocol used to communicate with remotecalendars will change, including in backwards incompatible ways. If thishappens you'll just need to upgrade your client; existing timestamps will beunaffected.

Calendar Mirroring

As a short-term measure, the raw calendar data for the three calendar serversin operation at this time can be downloaded directly. Seethe contrib/calendar-mirror.sh script for details.

Development

Use the setuptools development mode:

python3 setup.py develop --user

Known Issues

• Need unit tests for the client.

• Git tree re-hashing support fails on certain filenames with invalid unicodeencodings; this appears to be due to bugs in the underlying GitPythonlibrary. As a work-around, you may find the convmv tool useful to find andrename these files.

• Git annex support only works with the SHA256 and SHA256E backends.

• Errors in the Bitcoin RPC communication aren't handled in a user-friendlyway.

• Not all Python platforms check SSL certificates correctly. This means that onsome platforms, it would be possible for a MITM attacker to intercept HTTPSconnections to remote calendars. That said, it shouldn't be possible for suchan attacker to do anything worse than give us a timestamp that failsvalidation, an easily fixed problem.

• ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commitmakes sense.

• bitcoin package can cause issues, with ots confusing it with therequired python-bitcoinlib package. A symptom of this issue is themessage AttributeError: module 'bitcoin' has no attribute 'SelectParams' or JSONDecodeError("Expecting value", s, err.value) from None. To remedy this issue, one must do the following:

# uninstall the packages through pip
pip3 uninstall bitcoin python-bitcoinlib

# remove the bitcoin directory manually from your dist-packages folder
rm -rf /usr/local/lib/python3.5/dist-packages/bitcoin

# reinstall the required package
pip3 install python-bitcoinlib