Questions about Chainpoint v2

[kartojal]

Hello,

We are in the first stages of developing a proof of existence platform and would like to collaborate on this standard. We like the updates you have done to v2.0 and have the following recommendations/comments:

1. What was the reason you merged "chainpoint_version" and "hash_type" into "type"? We are finding requirements where the hash type is a variable and can change in each block. What was the reason behind merging the hash version and chainpoint version? We do not see them having a relationship. Would you consider to split these out again similar to what you had in v1?
2. Irrelevant to above direction taken in point #1, can you please add to SHA3-224, SHA3-256, SHA3-384, SHA3-512 which follows the latest 2015 implementation.
3. Our platform executes on both bitcoin and ethereum. Would you add ETHData under Anchor table?
4. You removed "custom" field from v2. We think it might help the community if it added back in and a few (optional) examples like; "timestamp", "transaction fee", "URI", etc.

Thank you, Laury(@laurybehrens) and David (@kartojal) ILAB & Associates

[waynevaughan]

Thanks for the feedback! I'll give a partial answer to your questions and add more detail later.

1) I'll leave this for @jasonbukowski to respond to this point.

2) We have considered adding more hash types.

3) Chainpoint 2.0 was designed to allow anchoring into multiple sources. We had plans to add anchoring into Ethereum, but then the ETC-ETH fork happened and we decided to hold off for a short time.

4) You can embed a Chainpoint receipt in a JSON-LD signature. This provides for better options than including extra fields.

[jasonbukowski]

1. The hash type and version were merged as they were both considered descriptors of the type of receipt represented in the JSON-LD document. Just as the document must conform to the format of the version specified throughout, the document must also use the same hash type throughout. The hash type must be consistent within the receipt in order to properly represent the proof. Given a set of receipt documents, you are free to use different types among that set, but within a single receipt, the hash type is constant thus defining it within its JSON-LD type specification was the decision. We're not free to modify this at this time as others have already started to adopt Chainpoint 2.0 and have built/are building tools that rely on the standard as currently defined.
2. and 3. Hash types and anchor types are things we can add to the specification over time. We intended to use the same hash names as supported in OpenSSL (and other tools that do the same). Since SHA3 support is not yet available in OpenSSL, our initial decision was to hold off. If, however, there is an immediate need for supporting SHA3 hash types, we can accommodate that. Regarding the anchor types, the type name indicate both the blockchain in question and the method of anchoring. BTCOpReturn tells you we are dealing with Bitcoin, and the value is anchored in the OP_RETURN. Can you describe the method you are choosing to anchor data in Etherium?
3. Our goal was to make the receipts as lean as possible, which meant removing from the specification any data which was not absolutely necessary for serving the primary function, proving the targetHash has been anchored at the stated anchor point(s). If you need to include other data, our thought is that you would construct your own JSON document containing that data, and include the Chainpoint receipt as one element among that data. This gives you ultimate freedom to package custom data along with the receipt data however you see fit.

[jasonbukowski]

@kartojal On a related note, regarding issue #1 , as of v2, the Chainpoint specification requires concatenation of hashes be done as binary, not as their hex string representations.

[laurybehrens]

Thank you for the quick feedback.

1 - ok, now understand the reasoning behind merging the two. 2 - Yes, at minimum could you add SHA-512. 3 - In Ethereum transactions, we anchor the merkle root value in "data" field. Ref: https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethsendtransaction [...] 4 - ok, agreed

Thanks, Laury(@laurybehrens) and David (@kartojal)

[laurybehrens]

Woops, typo on #2. It should be SHA3-512

[jasonbukowski]

Support has been added for SHA224, SHA384, SHA3-224, SHA3-256, SHA3-384, and SHA3-512.

The JSON-LD context has been updated to include the definitions for the new receipt types to be used for these hash functions. The new receipt types have been also added to the supported receipt types list on the Chainpoint website (http://www.chainpoint.org). Additionally, all related projects have been updated to support these new types (https://github.com/chainpoint/chainpoint-validate-js, https://github.com/Tierion/merkle-tools).

[kartojal]

Thanks for the update!

[kartojal]

Any news about adding the ETHData anchor type to chainpoint standard?

[jasonbukowski]

"ETHData" has been added as officially supported anchor type for Chainpoint. It represents data anchored to an Ethereum transaction within the data field. The Chainpoint website documentation and JSON-LD context have been updated to support this.