# OpenTimestamps Client
Command-line tool to create and validate timestamp proofs with the
OpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.
Additionally this package provides timestamping of PGP signed Git commits, and
verification of timestamps for both Git commits as a whole, and individual
files within a Git repository.
## Requirements
* Python3
While OpenTimestamps can *create* timestamps without a local Bitcoin node, to
*verify* 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 remote
calendars. 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 Bitcoin
blockchain; we're not doing one transaction per timestamp.
However, the client does come with a number of example timestamps which you can
try verifying immediately. Here's a complete timestamp that can be verified
locally:
$ 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 calendar
to 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, so
if 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 the
Bitcoin 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 actual
commitment 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 current
time. If you create multiple timestamps in close succession it's quite likely
that an adversary will be able to link those timestamps as related simply on
the basis of when they were created; if you make use of the timestamp multiple
files in one command functionality (`./ots stamp <file1> <file2> ... <fileN>`)
most of the commitment operations in the timestamps themselves will be
identical, providing an adversary very strong evidence that the files were
timestamped by the same person. Finally, the REST API used to communicate with
remote calendars doesn't currently attempt to provide any privacy, although it
could be modified to do so in the future (e.g. with prefix filters).
File contents *are* protected with nonces: a remote calendar learns nothing
about the contents of anything you timestamp as it only ever receives an opaque
and meaningless digest. Equally, if multiple files are timestamped at once,
each file is protected by an individual nonce; the timestamp for one file
reveals nothing about the contents of another file timestamped at the same
time.
## Compatibility Expectations
OpenTimestamps is production software that has been in use for many years. The
timestamp format itself is stable and future OpenTimestamp's clients will
always be able to verify OTS timestamps created in the past, provided that the
relevant calendar data is available. The only case where this guarantee could
fail is if cryptographic hashing functions themselves suffer a catestrophic
failure; a failure of Bitcoin itself, eg due to 51% attack, is *not* sufficient
to make Bitcoin timestamps from the past unverifiable, as the Bitcoin chain is
widely witnessed.
It's likely that the REST protocol used to communicate with remote calendars
will change, including in backwards incompatible ways. If this happens you'll
just need to upgrade your client software; existing timestamps will be
unaffected.
## Calendar Mirroring
Calendars can be backed up with the [otsd-backup.py](https://github.com/opentimestamps/opentimestamps-server/blob/master/otsd-backup.py)
tool from the [OpenTimestamps Server](https://github.com/opentimestamps/opentimestamps-server) package.
## 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 unicode
encodings; this appears to be due to bugs in the underlying GitPython
library. As a work-around, you may find the `convmv` tool useful to find and
rename 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-friendly
way.
* Not all Python platforms check SSL certificates correctly. This means that on
some platforms, it would be possible for a MITM attacker to intercept HTTPS
connections to remote calendars. That said, it shouldn't be possible for such
an attacker to do anything worse than give us a timestamp that fails
validation, an easily fixed problem.
* ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commit
makes sense.
* `bitcoin` package can cause issues, with `ots` confusing it with the
required `python-bitcoinlib` package. A symptom of this issue is the
message `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:
```bash
# 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
```
Raw data
{
"_id": null,
"home_page": "https://github.com/opentimestamps/opentimestamps-client",
"name": "opentimestamps-client",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": "cryptography timestamping bitcoin",
"author": "Peter Todd",
"author_email": "pete@petertodd.org",
"download_url": "https://files.pythonhosted.org/packages/3d/cb/15156c9bc8ab404e1fc2750a3b5aa4ecafccd632923776d61c875f116702/opentimestamps-client-0.7.2.tar.gz",
"platform": null,
"description": "# OpenTimestamps Client\n\nCommand-line tool to create and validate timestamp proofs with the\nOpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.\nAdditionally this package provides timestamping of PGP signed Git commits, and\nverification of timestamps for both Git commits as a whole, and individual\nfiles within a Git repository.\n\n## Requirements\n\n* Python3\n\nWhile OpenTimestamps can *create* timestamps without a local Bitcoin node, to\n*verify* timestamps you need a local Bitcoin Core node (a pruned node is fine).\n\n\n## Installation\n\nEither via PyPi:\n\n $ pip3 install opentimestamps-client\n\nor from source:\n\n $ python3 setup.py install\n\nOn Debian (Stretch) you can install the necessary system dependencies with:\n\n sudo apt-get install python3 python3-dev python3-pip python3-setuptools python3-wheel\n\n## Usage\n\nCreating a timestamp:\n\n $ ots stamp README.md\n Submitting to remote calendar https://a.pool.opentimestamps.org\n Submitting to remote calendar https://b.pool.opentimestamps.org\n Submitting to remote calendar https://a.pool.eternitywall.com\n\nYou'll see that `README.md.ots` has been created with the aid of three remote\ncalendars. We can't verify it immediately however:\n\n $ ots verify README.md.ots\n Assuming target filename is 'README.md'\n Calendar https://alice.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain\n Calendar https://bob.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain\n Calendar https://finney.calendar.eternitywall.com: Pending confirmation in Bitcoin blockchain\n\nIt takes a few hours for the timestamp to get confirmed by the Bitcoin\nblockchain; we're not doing one transaction per timestamp.\n\nHowever, the client does come with a number of example timestamps which you can\ntry verifying immediately. Here's a complete timestamp that can be verified\nlocally:\n\n $ ots verify examples/hello-world.txt.ots\n Assuming target filename is 'examples/hello-world.txt'\n Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST\n\nYou can specify JSON-RPC credentials (`USER` and `PASS`) for a local bitcoin node like so:\n\n $ ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify examples/hello-world.txt.ots\n Assuming target filename is 'examples/hello-world.txt'\n Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST\n\nIncomplete timestamps are ones that require the assistance of a remote calendar\nto verify; the calendar provides the path to the Bitcoin block header:\n\n $ ots verify examples/incomplete.txt.ots\n Assuming target filename is 'examples/incomplete.txt'\n Got 1 new attestation(s) from https://alice.btc.calendar.opentimestamps.org\n Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST\n\nThe client maintains a cache of timestamps it obtains from remote calendars, so\nif you verify the same file again it'll use the cache:\n\n $ ots verify examples/incomplete.txt.ots\n Assuming target filename is 'examples/incomplete.txt'\n Got 1 attestation(s) from cache\n Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST\n\nYou can also upgrade an incomplete timestamp, which adds the path to the\nBitcoin blockchain to the timestamp itself:\n\n $ ots upgrade examples/incomplete.txt.ots\n Got 1 attestation(s) from cache\n Success! Timestamp is complete\n\nFinally, you can get information on a timestamp, including the actual\ncommitment operations and attestations in it:\n\n $ ots info examples/two-calendars.txt.ots\n File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb\n Timestamp:\n append 839037eef449dec6dac322ca97347c45\n sha256\n -> append 6b4023b6edd3a0eeeb09e5d718723b9e\n sha256\n prepend 57d46515\n append eadd66b1688d5574\n verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')\n -> append a3ad701ef9f10535a84968b5a99d8580\n sha256\n prepend 57d46516\n append 647b90ea1b270a97\n verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')\n\n### Timestamping and Verifying PGP Signed Git Commits\n\nSee `doc/git-integration.md`\n\n\n## Privacy Security\n\nTimestamping inherently records potentially revealing metadata: the current\ntime. If you create multiple timestamps in close succession it's quite likely\nthat an adversary will be able to link those timestamps as related simply on\nthe basis of when they were created; if you make use of the timestamp multiple\nfiles in one command functionality (`./ots stamp <file1> <file2> ... <fileN>`)\nmost of the commitment operations in the timestamps themselves will be\nidentical, providing an adversary very strong evidence that the files were\ntimestamped by the same person. Finally, the REST API used to communicate with\nremote calendars doesn't currently attempt to provide any privacy, although it\ncould be modified to do so in the future (e.g. with prefix filters).\n\nFile contents *are* protected with nonces: a remote calendar learns nothing\nabout the contents of anything you timestamp as it only ever receives an opaque\nand meaningless digest. Equally, if multiple files are timestamped at once,\neach file is protected by an individual nonce; the timestamp for one file\nreveals nothing about the contents of another file timestamped at the same\ntime.\n\n## Compatibility Expectations\n\nOpenTimestamps is production software that has been in use for many years. The\ntimestamp format itself is stable and future OpenTimestamp's clients will\nalways be able to verify OTS timestamps created in the past, provided that the\nrelevant calendar data is available. The only case where this guarantee could\nfail is if cryptographic hashing functions themselves suffer a catestrophic\nfailure; a failure of Bitcoin itself, eg due to 51% attack, is *not* sufficient\nto make Bitcoin timestamps from the past unverifiable, as the Bitcoin chain is\nwidely witnessed.\n\nIt's likely that the REST protocol used to communicate with remote calendars\nwill change, including in backwards incompatible ways. If this happens you'll\njust need to upgrade your client software; existing timestamps will be\nunaffected.\n\n## Calendar Mirroring\n\nCalendars can be backed up with the [otsd-backup.py](https://github.com/opentimestamps/opentimestamps-server/blob/master/otsd-backup.py)\ntool from the [OpenTimestamps Server](https://github.com/opentimestamps/opentimestamps-server) package.\n\n\n## Development\n\nUse the setuptools development mode:\n\n python3 setup.py develop --user\n\n\n## Known Issues\n\n* Need unit tests for the client.\n\n* Git tree re-hashing support fails on certain filenames with invalid unicode\n encodings; this appears to be due to bugs in the underlying GitPython\n library. As a work-around, you may find the `convmv` tool useful to find and\n rename these files.\n\n* Git annex support only works with the SHA256 and SHA256E backends.\n\n* Errors in the Bitcoin RPC communication aren't handled in a user-friendly\n way.\n\n* Not all Python platforms check SSL certificates correctly. This means that on\n some platforms, it would be possible for a MITM attacker to intercept HTTPS\n connections to remote calendars. That said, it shouldn't be possible for such\n an attacker to do anything worse than give us a timestamp that fails\n validation, an easily fixed problem.\n\n* ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commit\n makes sense.\n\n* `bitcoin` package can cause issues, with `ots` confusing it with the\n required `python-bitcoinlib` package. A symptom of this issue is the\n message `AttributeError: module 'bitcoin' has no attribute\n 'SelectParams'` or `JSONDecodeError(\"Expecting value\", s, err.value) from None`. To remedy this issue, one must do the following:\n\n```bash\n# uninstall the packages through pip\npip3 uninstall bitcoin python-bitcoinlib\n\n# remove the bitcoin directory manually from your dist-packages folder\nrm -rf /usr/local/lib/python3.5/dist-packages/bitcoin\n\n# reinstall the required package\npip3 install python-bitcoinlib\n```\n",
"bugtrack_url": null,
"license": "LGPL3",
"summary": "Command-line tool to create and verify OpenTimestamps proofs",
"version": "0.7.2",
"project_urls": {
"Homepage": "https://github.com/opentimestamps/opentimestamps-client"
},
"split_keywords": [
"cryptography",
"timestamping",
"bitcoin"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "3beda6025dec89a31ac4d3c35a7ac10822b702c965c170e03a9dbb2d42195181",
"md5": "beed39970b1e051d11f687fb7adf1272",
"sha256": "84e604d7f76534da4bab61ab62b211a6559aa988da51438408ae7947b0e8b7ba"
},
"downloads": -1,
"filename": "opentimestamps_client-0.7.2-py3-none-any.whl",
"has_sig": false,
"md5_digest": "beed39970b1e051d11f687fb7adf1272",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 27371,
"upload_time": "2024-12-31T15:13:14",
"upload_time_iso_8601": "2024-12-31T15:13:14.179625Z",
"url": "https://files.pythonhosted.org/packages/3b/ed/a6025dec89a31ac4d3c35a7ac10822b702c965c170e03a9dbb2d42195181/opentimestamps_client-0.7.2-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "3dcb15156c9bc8ab404e1fc2750a3b5aa4ecafccd632923776d61c875f116702",
"md5": "8b2e9bf78d57bc75be90a7956ec8e780",
"sha256": "083a08f59c3123682d6742cc57d3e229ed7b3397807638836efe3a949517accb"
},
"downloads": -1,
"filename": "opentimestamps-client-0.7.2.tar.gz",
"has_sig": false,
"md5_digest": "8b2e9bf78d57bc75be90a7956ec8e780",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 24206,
"upload_time": "2024-12-31T15:17:26",
"upload_time_iso_8601": "2024-12-31T15:17:26.772975Z",
"url": "https://files.pythonhosted.org/packages/3d/cb/15156c9bc8ab404e1fc2750a3b5aa4ecafccd632923776d61c875f116702/opentimestamps-client-0.7.2.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-12-31 15:17:26",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "opentimestamps",
"github_project": "opentimestamps-client",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"requirements": [
{
"name": "opentimestamps",
"specs": [
[
"<",
"0.5.0"
],
[
">=",
"0.4.0"
]
]
},
{
"name": "appdirs",
"specs": [
[
">=",
"1.3.0"
]
]
},
{
"name": "GitPython",
"specs": [
[
">=",
"2.0.8"
]
]
},
{
"name": "PySocks",
"specs": [
[
">=",
"1.5.0"
]
]
}
],
"lcname": "opentimestamps-client"
}
JSON
