Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
OTIP (OpenTimestaps Improvement Proposal) to support human readable .JSON to ease the adoption #43
I thought about outputting
Reading about the format on Wikipedia
I genuinely believe there is a fair balance between usability / user adoption and trying to save each and every byte.
On that basis I recommend extending the standard to support both:
We are already saving data, not publishing any data on the blockchain, even if the .JSON file is
UPDATE: on the other hand, if we acknowledge the existence of other blockchains: https://solidity.readthedocs.io/en/v0.5.8/miscellaneous.html
If reducing size is not possible, then hash or multihash of
OpenTimestamps doesn't use binary to reduce size; it uses binary to reduce risk.
Binary parsing is ideal for that precisely because it isn't forgiving: unless you can parse the proof completely you probably can't parse it at all. That's a good thing for security software! If your OTS implementation has bugs in it, those bugs might be exploitable, so we'd rather those bugs lead to the code not working at all rather than it appearing to work.
Secondly, OTS proofs aren't really human readable in any form, because humans can't do cryptographic hashes in their head. Sure, you can gain some insight into what the proof is doing - good for education. But you can't understand a proof fully without code. So you might as well accept that and default to binary, with the exception of informational tools like
For things like HTML where pure binary simply can't be embedded, I'd suggest just encoding the binary in whatever is the most efficient encoding scheme you have available. Base64 is probably fine.
Fragility is a feature.
Thank you for explaining.
Yup, that's a a perfectly good work around.
You know, another way to think about this is we already do this for cryptographic things like signatures and hashes all the time: a signature or even a hash digest could be represented a "human readable" form consisting of whatever individual numbers the algorithm put out. But that'd be useless as humans can't do anything useful with those numbers, so even in JSON encodings standards tend to just hex-encode such data.
I'm taking part in a bug bounty.
I would like to send the report privately and update the issue on GitHub and paste the content of the
Another use case I can think of - compiling a report in .PDF and including the
Binary data is not suited for displaying on GitHub, email or .PDF.
In my realm of web technologies, JSON is pretty much everywhere and I think there is a place for human-readable representation. Even if the verification (calculating hashes) will require a computer, even if fragility is a feature (pretty clever) there is still value if it can be displayed in plain text. I guess the
Analogy to PGP - verifying signatures requires some software and yet the
Here is the representation in the current form:
So I wouldn't call clearsigned PGP plain text. Rather it's a plain text encoding of binary data.
You can do that with OTS too, with the very simplest way to be just to base64-encode it. I'd also be willing to accept a "clear-stamped" extension format for OTS, that basically worked similarly to how PGP clear-signing works. Main thing there is you want to ensure that you can timestamp a clearsigned document, with the timestamp applying to the PGP signature as well as the document text. This also means you'd want to follow exactly how the OpenPGP standard does clear-signing: https://tools.ietf.org/html/rfc4880#section-7
Something like that?
It looks familiar, similar to PGP and
It does the job.
It can be represented in print.
Can you explain?
Can I opentimestamp (used as verb) a document without opentimestamping the PGP signature?
Yup, kinda like that.
So basically, it's best if PGP can directly verify the signature on the clearsigned text without any fuss, and OpenTimestamps can also verify it directly, while also verifying that the signature itself is timestamped.
Notably, GPG does allow multiple PGP signatures to be attached to one clearsigned piece of text! So you can re-use that flexibility for opentimestamps by sticking the timestamp at the very end.
Play around with it a bit by making up some clearsigned things with fake timestamps at the end and you'll see what I mean.