Replace "timestamp" with a better term

[kennylavender]

From @ericelliott

https://github.com/poetapp/node/pull/142#issuecomment-402894564

This is confusing to me. Claims should have their own timestamps before they get to the batching process. Batching to the blockchain doesn't timestamp the claims. It provides consensus for the order of claims, not the precise creation time of claims. I don't think we should be using "timestamping" in reference to claim batching.

Also, batch frequency has no protocol-guaranteed timing, so if you think of a batch as a "timestamp", it doesn't have any particular resolution. Accuracy vary be within 20 minutes, an hour, or a week.

@ericelliott @lautarodragan @geoffturk To avoid confusion and miscommunication I was thinking we should use a better term throughout the codebase where we are currently using the term timestamp. I was thinking anchor? or maybe a more specific blockchainAnchor? This should also be adjusted in other repos such as poet-js. Thoughts?

[lautarodragan]

Although it could cause confusion initially, I think it's pretty standard in the blockchain world.

See OpenTimestamps for example.

A timestamping proof standard

OpenTimestamps aims to be a standard format for blockchain timestamping. The format is flexible enough to be vendor and blockchain independent.

OTS has a lot of weight in the scene in part because it was started by Peter Todd.

The term may origin from Trusted Timestamping.

Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one—not even the owner of the document—should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.

See Decentralized timestamping on the blockchain.

With the advent of cryptocurrencies like bitcoin, it has become possible to securely timestamp information in a decentralized and tamper-proof manner.

Searching for timestamping to blockchain provides many results related to this.

Chainpoint uses both anchor and timestamp.

Chainpoint is an open standard for creating a timestamp proof of any data, file, or process

Anchor an unlimited amount of data to the Bitcoin blockchain. Verify the integrity and existence of data without relying on a trusted third-party.

[geoffturk]

I hear what you are saying Lautaro, but just because it is a convention doesn't mean it shouldn't be improved if there is room for improvement. We could coin a new term like blockchainAnchor or blockstamp and then define it in our documentation.

I think it is a bit confusing when we use the same word to refer to two different things in the same system.

[lautarodragan]

Agreed. If you guys still think it's confusing and would like to replace it, I'm all in for that.

[geoffturk]

Great! blockstamp is short but maybe trying to be a bit too catchy. blockchainAnchor is good but a bit long. I'm fine with either one or maybe someone has a better idea.

What will this field contain exactly? The number of the block in the Bitcoin blockchain that the claim batch hash was written to?

[kennylavender]

Cool! Yup, I am in for exploring some name ideas and if any make a significant improvement we can adjust. I don't believe this will introduce any breaking changes, but if/when the node changes the views collection entries from using "timestamp" to whatever name, explorer-web will also need to be updated I believe, not sure if the frost-api or frost-web will have any code conflicts, but in frost web we do have some 'references' to timestamping, for example, this tooltip in frost-web: Frost is currently only timestamping to testnet — mainnet timestamping is unavailable.

Here are the poet-js interfaces

export interface TransactionPoetTimestamp {
  readonly transactionId: string
  readonly outputIndex: number
  readonly prefix: string
  readonly version: ReadonlyArray<number>
  readonly ipfsDirectoryHash: string
}

export interface PoetTimestamp extends TransactionPoetTimestamp {
  readonly blockHeight: number
  readonly blockHash: string
  readonly ipfsFileHash?: string
}

Here is an example work entry that contains a "timestamp".

{  
      "id":"a3ff6ebf71f627dba84fee1d02bcf1499ca6bd9ed3cffc5b39eea10420ad96ac",
      "publicKey":"023e321dd76c7b2e85378a02575b27a16533b4e2ec8b78bbc01264a833fb3e0f0e",
      "signature":"3045022100e87514569fd621af4832b863ee57e39890dc08b509ff25be8e1fc3577c72c7ce02202c4069394b507f2aca937164cb1bb228dac2c7945ef663367ca1b8c938ff8b81",
      "type":"Work",
      "dateCreated":"2018-07-30T06:41:29.383Z",
      "attributes":{  
         "name":"Testing Claim Batching 2",
         "author":"Lautaro",
         "tags":"short story, detective story, detective",
         "dateCreated":"1841-01-01T00:00:00.000Z",
         "datePublished":"1841-01-01T00:00:00.000Z",
         "content":"The mental features discoursed of as the analytical, are, in themselves, but little susceptible of analysis..."
      },
      "timestamp":{  
         "ipfsDirectoryHash":"QmYMHmt9H37gqwDMd4yYrt99cDRJxHpwVATKWYGbYNWncp",
         "transactionId":"7f362f6e93dadca3349b29281866eb3c5400594b1285a7d14df093d23b5c172b",
         "outputIndex":0,
         "prefix":"BARD",
         "version":[  
            0,
            0,
            0,
            3
         ],
         "blockHeight":1356137,
         "blockHash":"00000000000151360aad32397ff1cf7dd303bed163b0ef425e71a53ccdec7312",
         "ipfsFileHash":"QmVwXooK1Ba6eYULLpzFzSekgDsc5hhnumbPsJnLmnf55G"
      }
   }

[lautarodragan]

I like the sound of blockstamp, definitely catchy! But I think blockchainAnchor is more self-explanatory and there's at least one other company using that term. A quick google for blockstamp doesn't seem to throw any relevant results...

[geoffturk]

We could just go with anchor since it is shorter and can be used as a verb as well. For example, in the frost-web tooltip quoted above (Frost is currently only timestamping to testnet — mainnet timestamping is unavailable.): Frost is currently only anchoring to testnet — mainnet anchoring is unavailable.

I don't mind coining a new term (blockstamp) if it describes the process better than a generic term like anchor. I like how this sounds: Frost is currently only blockstamping to testnet — mainnet blockstamping is unavailable.

Distinguishing between a timestamp and a blockstamp in our glossary is easy to do and shows that the terms are related but different.

[ericelliott]

Let's use "anchor" to describe committing something to the blockchain via a hash of hashes, because that's the term the rest of the ecosystem has already pretty much settled on, and anybody with some blockchain background should be able to understand what we mean without a detailed explanation.

I think people immediately get the metaphor, and it's already in wide use by companies like Tierion, IBM, Philips, etc...

[waynevaughan]

Anchor has become an industry standard term.

Chainpoint uses anchor. https://chainpoint.org

Kaleido uses anchor. https://aws.amazon.com/blogs/apn/launch-enterprise-ready-blockchain-networks-on-aws-in-minutes-with-kaleido-a-consensys-solution/

Factom uses anchor. https://www.factom.com/about/faqs

Bitfury uses anchor. https://bitfury.com/content/downloads/bitfury_white_paper_on_blockchain_auditability.pdf

I could keep adding examples, but I think the four provided are sufficient.

I hope this input helps. Good luck with Poet.

[geoffturk]

anchor it is then. Thanks everyone for your input.

Reassigning to myself and will close once the documentation is updated.

[petertodd]

Well, what type of proof does poet actually produce? Or put another way, what does it prevent an attacker from doing?

OpenTimestamps proves that data existed in the past; OpenTimestamps does not prove anything beyond that. It's traditional in cryptography to call that particular type of proof a "timestamp"

Notably OpenTimestamps does not prove the non-existence of conflicting data. The usually example I use is the sale of a house: timestamping the title documents associated with that sale simply shows that those documents existed in the past. The sale still could be invalid however as the seller might have already sold the house to someone else. That previous sale would have been conflicting data, something that OpenTimestamps can't prevent.

I'd suggest not using the term "anchor" as it doesn't have a clear cryptographic meaning.

[lautarodragan]

Thanks @petertodd. Given that description, timestamp would seem more accurate.

Maybe “anchor” has the added meaning of the timestamped data being dereferenceable?

[petertodd]

Maybe “anchor” has the added meaning of the timestamped data being dereferenceable?

What do you mean by "dereferenceable"?

[lautarodragan]

That the stored data is an address, a pointer to more data. (An IPFS Directory Hash in our case)

[petertodd]

Timestamped data is still a pointer in the sense that you could look up the timestamped hash digest in something like IPFS.

I think a better definition would be for anchor to mean a proof of non-existence of conflicting data. Of the four companies mentioned above that use the term "anchor", Factom and BitFury appear to be using the term in that sense, and Kaleido probably is. Chainpoint may have intended to do so, but their product does not provide that type of guarantee.

One thing I don't like about the term "anchor" is that real-life anchors aren't associated with a concept of uniqueness: ships often have multiple anchors, and anchors themselves aren't unique. The implication is also reversed from how such a cryptographic proof has to actually work: we usually think of a ship as anchored to the seabed, when in fact the cryptographic analogy would have us follow the seabed to the ship by finding a specific anchor on the seabed.

A better term to use for this concept would be "gazetted". The term "gazette" is often used for official legal publications over which there is consensus on the contents of the publication; a notice "gazetted" in such a document has been published widely in a fashion that allows everyone to come to consensus over the contents of that notice. Similarly a transaction in a blockchain that commits to the state of another consensus system has been published widely, allowing anyone to come to consensus over the state of that secondary consensus system.

[petertodd]

Example: https://changeofname.in/online-application-for-name-change-in-gazette/online-gazette-form-for-name-change-after-marriage/

tl;dr: Part of the process of changing your name in Indian is to gazette a notice of that name change to an official gazette publication.

[lautarodragan]

I personally prefer timestamp for the same reasons you stated (see my first comment on this thread), but I understand it can be less friendly to people that are getting started. It could be their [un]familiarity bias, it could be mine.

Gazetted could work and it may even go well with our [initial] industry, but I haven't heard it before and I don't think anyone is using it?

Anchor on the other hand, even if not the most accurate, already has a bit of momentum, is easy to spell and pronounce, leaves no doubts as to how to camelCase or PascalCase to newcomers and is not used by anything else in tech AFAIK. Feels like a good middle ground.

[petertodd]

@lautarodragan Well, in your case I'd just use the term timestamp, as if I understand correctly that's what poet does; I wouldn't use any other term unless you're doing more than a timestamp proof.

[poet-ci]

:tada: This issue has been resolved in version 2.10.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: