[JWett]

Hi, ex-CEO of Surety here. The article is not very technical so I can see where you might assume this is not a true blockchain. However, the hash value published in the Times was, in fact, dependent upon every single hash value for every digital "document" ever submitted to the Digital Notary Service.

A Digital Notary client application would submit a hash value (which in the early days was a combination of MD5 and SHA-1 but the system was very flexible in that it could upgrade the hash algos when more collision resistant versions became available) that would become part of a Merkle tree along with any other client submissions received in a short timeframe. The parent "top hash" node of the Merkle tree was then hashed with the the last value in a linked list referred to internally as the "super hash" chain to create a new end value in the chain.

The client application would receive a notary "certificate" containing all the values in the Merkle tree required to re-calculate the hash woven into the super hash chain along with the timestamp for the moment it became part of the chain. The client application could use this certificate at any time to electronically verify the veracity of any "document" (i.e., guarantee that the document existed in its exact form at a specific point in time.)

On a side note, the algorithms and implementation were successfully tested in court cases. (Some of Surety's customers used the system to timestamp millions of documents turned over in electronic legal discovery to ensure they were not tampered with by opposing counsel.)

The New York Times value was only significant in that if could be used to "manually" calculate the veracity of the notary certificate by hashing the super hash value it contained with all subsequent values in the super hash chain until it resulted in the hash value published in the Times. This "widely witnessed" approach made it impossible for an insider to collude with someone to generate a correct notary certificate retroactively by replacing the document with a forgery.

The blockchain technology used by crypto currencies is similar except for the tremendous amount of computation required to generate a "correct" hash value to close out a block and weave it into the chain.

Stuart Haber and Scott Stornetta deserve a lot of credit for creating this when were working for Bellcore. Two brilliant guys.

[earthscienceman]

In case anyone else knows little about the history of cryptography or who these names are, here's some relevant information.

Here's the paper that started it all:

https://link.springer.com/article/10.1007/BF00196791

And a WSJ article describing the atmosphere in more detail:

https://www.wsj.com/articles/the-eureka-moment-that-made-bit...

[zadler]

The “block” in blockchain is due to it being a byzantine fault tolerant replicated state machine. If it were centralised there would be no need for a block. That may be the main distinguishing characteristic. Git is another example of an application running on a hash chain, but it doesn’t have blocks because it doesn’t require a slow / costly consensus process.

[bigiain]

Feels a bit like that's a post-facto argument to me.

It sounds like the Surity thing had "blocks" consisting of a week's worth of documents which got chained together and had their hash published irrevocably every week.

Without the subsequent invention and popularity of the specific implementation of the bitcoin blockchain - I don't think the slow/costly consensus "feature" could be considered a requirement to distinguish between "hash chains" and "block chains" like that.

(But I'm regularly on the losing side of nomenclature arguments - I'm still pissed at all the people who've decided they should call my non-autonomous quadcopters "drones"...)

[jobigoud]

> I'm still pissed at all the people who've decided they should call my non-autonomous quadcopters "drones"

Apparently we should call them quadpters because it's based on helicopter for which the ethymology is not heli + copter, but helico + pter, like in helicoidal and pterodactyl.

[taejo]

Or tetrapter, to stick with Greek roots (though I'm personally fine with heteroradicalism!)

[bigiain]

From now on, I'm shall call them "spinning dinosaurs"!

"Hey mister! Is that your drone?" "No kid, it's not a drone, it's a spinning dinosaur..."

[bittcto]

The entire point of Bitcoin is the distributed trustless consensus mechanism. Read the Nakamoto white paper, it’s all about double spending.

A chain of hashed data dates back to Merkle himself, that’s what a Merkle tree is.

The entire point of bitcoin is distributed independent truth and that’s the entire point of a Blockchain.

[maxerickson]

The bitcoin whitepaper used the word "block" in the sense of "some data under a given hash".

https://bitcoin.org/bitcoin.pdf

It didn't use the word block in the sense of "to stop people from forging history".

[bittcto]

The entire point of Bitcoin is the distributed trustless consensus mechanism. Read the Nakamoto white paper, it’s all about double spending.

A chain of hashed data dates back to Merkle himself, that’s what a Merkle tree is.

The entire point of bitcoin is distributed independent truth and that’s the entire point of a Blockchain.

[maxerickson]

Your copy pasta is somewhat less effective when I linked the whitepaper to make my point.

[prepend]

Doesn’t this rely on Surety being trusted though? It seems technically possible for Surety to modify documents consistently in and out so the hashes are consistent, but not representative of the submitted documents.

Especially back in the 90s when generating crypto hashes wasn’t as easy for users.

So this is similar to notaries where the trust lies with a different party.

The killer app, I think, that made blockchain blockchain is the trustless nature.

Surety is certainly cool, but just a better version of putting a hash in a bank’s safety deposit box.

[JWett]

Surety is not a trusted central authority. There is no mathematically feasible way to backdate a document and weave it into the chain. The only way to circumvent the system would be to generate the same submitted hash value (using two different hash algorithms) with a different document. Additionally, for it to be actually useful, you would need to generate a hash collision for a different document with a purposeful modification (for example, changing the amount due for an invoice.) I can't begin to calculate the odds on making that happen.

Also note the hash values sent to Surety were calculated on the end user's computer. Surety never sees the actual file being timestamped.

As for the safety deposit box metaphor, the Haber-Stornetta approach is akin to nailing the hash to a post in the town square.

[cbm-vic-20]

A transparent bank safety deposit box, that everyone can see.

[dnautics]

Thanks for clearing that up!