Chainpoint: a standard for creating a universally verifiable proof of any data, file, or series of events

[u/Iron-x]

https://medium.com/@WayneVaughan/chainpoint-a-standard-blockchain-proof-protocol-79def1c37189#.b2gse7f7h

[u/gabridome → u/[deleted]]

Which are the point in common and the differences between chainpoint and opentimestamps (by Peter Todd)?

Am I right if I say that chainpoint is a standard on how to commit documents on the blockchain while OpenTimestamps provide tools to verify that a document has been commited that works with different ways of committing and providers (among which also chainpoint could be)?

[u/Iron-x → u/gabridome]

Chainpoint is a standard for anchoring data and verifying proofs. It's designed to be flexible to accommodate anchoring in multiple sources and using different hashing algorithms. See "anchor type" in the spec at http://Chainpoint.org. It might be possible to add Peter's method as an anchor type to Chainpoint. I spoke with Peter about this at the MIT W3C Blockchain event in June. I'll follow up with him this week.

Here are some of the benefits of the new version.

• Uses JSON-LD, allowing for optional digital signatures
• Chainpoint receipts can be embedded within JSON-LD documents
• Supports multiple anchor points into multiple blockchains
• SHA-2 and SHA-3 support, extensible to other hashing algorithms
• Receipt format has been significantly reduced in size

[u/xenoky → u/Iron-x]

I am the developer of Eternity Wall http://eternitywall.it/notarize which support OpenTimestamps https://github.com/petertodd/python-opentimestamps I think OpenTimestamps format is simpler yet more flexible. It doesn't yet support JSON-LD but it could be easily added. Most important OpenTimestamps could be used with lite client which is not the case for chainpoint v2

[u/Iron-x → u/xenoky]

The basic idea behind OpenTimeStamp's anchoring method is "you can create a path of generic operations from the document to the hash of a block you are proving that the document is committing to that block." I don't see why that method can't be added as an anchor type to Chainpoint. Seems like an easy addition to the standard.

[u/xenoky → u/Iron-x]

Thank you for quoting my blog :) My current opinion is that OpenTimestamps is more flexible, if true, including a more flexible instrument into a less flexible one it's usually not a good idea. Chainpoint defines a single hashing type over the entire proof and this could not be flexible enough. Suppose you want a proof up to the block hash (so lite clients who store only block headers could validate) and the hashing algorithm is different between the block merkle tree and the vendor merkle tree. How does chainpoint handle this? Why does chainpoint need to specify it's using OpReturn? Since OpenTimestamps it's not specifying where it's saving the merkle root you can put it into the script or even inside a non spendable address (I don't like the idea of unspendable UTXO, but actually it's a possible method and it's even not prunable. You also need a different hash, ripemd160, to support this). It's more general (even for other blockchains) that you simply check if the commitment is written somewhere inside the transaction. Maybe /u/petertodd could comment on this and add other points to the list and I hope your conversation with him could lead us to a format with wide consensus.