Hacker News new | comments | show | ask | jobs | submit login
The World’s Oldest Blockchain Has Been Hiding in the New York Times Since 1995 (vice.com)
240 points by chuckblake 3 months ago | hide | past | web | favorite | 78 comments



It is a hash of a block, but not a chain.

For this to be a chain, it would have to be published multiple times, each time containing references to previous blocks under the published hash.

Other than that I am pretty sure we can find many more examples. Hashing and publishing the hash is pretty popular way to prove timestamp of a secret without revealing the secret, yet. I did it myself a couple of times when I wanted to be able to prove later that I had a particular information before some specific time.


Other than that I am pretty sure we can find many more examples.

This statement could be made much more interesting and convincing if you provided some actual examples.


It's fairly common (at least among the security community) to post a hash of a claim to Twitter, that they can reference in the future to prove that they had X information on Y date without disclosing the actual information until later.

For example, I could post the hash "9712f2488fa00fc5b11b657995ac10c9" to Twitter and then after the prediction comes to pass, I can reveal that the hash was for the phrase "Pittsburgh Steelers will Defeat New Orleans Saints 30-21 in Super Bowl LIII", proving that I had some knowledge or prediction that I didn't want to reveal at the time of the prediction.


Wait but this is not fail proof right. For example I can post that Kolkata Knight riders will defeat Mumbai Indians along with a post that Mumbai Indians will defeat Kolkata Knight riders and delete the wrong twitter post once the competetion is over?


Presumably, one can assume that once it is published publicly, someone else could make a note of it, and tattle on the author whenever they delete a hash without revealing the source of it.

In practice, nobody is attending to anyone that closely, aside from a handful of public figures, and shenanigans like those you described might actually work to get someone more attention, only to fail once they have enough. That's why a publication mechanism that disallows deletions is desirable for such hashes.


How is this similar to:

"Instead of posting customer hashes to a public digital ledger, Surety creates a unique hash value of all the new seals added to the database each week and publishes this hash value in the New York Times. The hash is placed in a small ad in the Times classified section under the heading “Notices & Lost and Found” and has appeared once a week since 1995." ?


How is it similar? I think we could rephrase it.

- Post a hash of a document to Twitter.

- Put a hash of a document in an ad in the NYT.

Quite similar.


It's not difficult to find examples:

https://twitter.com/gruber/status/991122089557004288?lang=en

There is even whole industry around the concept, it is called trusted timestamping: https://en.wikipedia.org/wiki/Trusted_timestamping

It basically works like this, you compute a hash of the document and send to some kind of service that will either publish your hash with the timestamp or will also sign the hash and the timestamp cryptographically without ever touching the document.

Later, you can refer somebody to the external service or let them examine the signature and the hash to prove that you were in possession of the information before certain date and time.


"Hash and Sign" timestamping is flawed in that it relies on the trust of a central authority. An insider with access to the private key could easily backdate a timestamp and sign any document/timestamp combination. Surety's widely-witnessed approach was meant to fix this issue.

Chaining the hash values made it fundamentally impossible for any malicious actor to generate a notary certificate for a future document that would roll up and produce the correct super hash value that is woven into the chain.



Thank you for posting this and clearing it up. This was missing from the original article.


Yes, I found it quite frustrating as well. -.-


It's a block chain. From the article:

> a copy of that seal and every other seal created by Surety’s customers is sent to the AbsoluteProof “universal registry database,” which is a “hash-chain” composed entirely of Surety customer seals. This creates an immutable record of all the Surety seals ever produced, so that it is impossible for the company or any malicious actor to modify a seal.

Another well known example of course is git (which slightly extends the definition to a directed acyclic graph).


Just a hash chain, pretty sure one can find much older ones. some old checksums might do that too. When someone says blockchain, in my book (and this might differ from others) - its about the consensus algorithm used to prevent tampering, like POW as introduced by Bitcoin.


I agree with you that your definition is what we should define a blockchain as, as Natamoto defined it. However, I'm afraid to say probably the majority of companies that claim they use blockchain probably use something very close to Git instead, or even just a digital signature or a hash function. Seriously, it's ridiculous.

Imagine if Google called certificate transparency blockchain? Journalists would lose their shit. Such an easy article to write. In fact, Google explicitly say on their website that they're kinda against the hype: http://www.certificate-transparency.org/general-transparency "These technologies are strongly related to the much-hyped blockchain. The reality, of course, is that there isn't a "the" blockchain, and that decentralisation is not always the answer. We are not making "the" blockchain, and we do not claim to support decentralisation."

I'll never forget my first job the business people wanted to investigate "the blockchain" and the yes men came up with a bunch of PoCs. I just asked "how is this different to Git?" Such an awkward moment.


> I agree with you that your definition is what we should define a blockchain as, as Natamoto defined it.

Funny enough, "blockchain" as a term wasn't defined in the Bitcoin white paper at all.


If you don't have decentralized production and validation of blocks, you don't have a block chain.


Why should it need to be decentralized?

A blockchain is a chain of blocks. Tautological, but the words mean something; it isn't just a name. If you hash blocks that contain hashes of previous blocks, you have a blockchain.

At most it might be argued that a centralized blockchain has no reason to exist, but I doubt that's true.


> A blockchain is a chain of blocks. Tautological, but the words mean something; it isn't just a name.

No, it doesn't work like that. "Blockchain" is understood to mean something and you can't decompose the compound word and say "well, here's a block. Oh, and here's a chain. I guess this is a block chain." Your description, e.g., applies to a Merkle tree [0], which git uses, and was published in 1979. But no one has ever or will ever call it a blockchain.

Is a Ford F-150 that's been lit on fire a firetruck? How much straw is in a strawberry?

[0] https://en.wikipedia.org/wiki/Merkle_tree


You're on the right side of the linguistic prescriptivism vs descriptivism debate, but I think the meaning of that word might not have settled enough yet. Personally, I think it makes sense to restrict "blockchain" to a chain (or DAG) of blocks with hashes, and refer to Bitcoin etc. technology as blockchain + POW (rather than having "blockchain" subsume the POW).

That might be a losing battle, but not sure the battle is over yet...


My go-to example for this is "putting a Hershey's bar in the microwave is not hot chocolate."


Because the term was coined by Nakamoto to describe the technology behind bitcoin. Decentralization, proof of work and other characteristics of bitcoin are intrinsic to making the system work. Otherwise you have an inefficient database that has no reason to exist.


> Because the term was coined by Nakamoto to describe the technology behind bitcoin.

It wasn't- there's one mention of a "chain of blocks" in the white paper. The term "blockchain" appears to have been coined by Hal Finney.


You don't really need the 'otherwise'.


You don't need decentralization for a blockchain.

All you need is 1) a reverse linked list of entries and 2) have the list be cryptographic in nature. Even git can be used for a blockchain since it uses a cryptographic hash for commits and can use GPG signing.

Validation, consensus and decentralizations are additional properties that you can add on top that make it useful for certain use cases.


Because the term was coined by Nakamoto to describe the technology behind bitcoin. Decentralization, proof of work and other characteristics of bitcoin are intrinsic to making the system work. Otherwise you have an inefficient database that has no reason to exist.

This is one of the problems with the generic use of “blockchain”. People think you just need Merkle roots including previous blocks, like you do, but that’s useless and pointless without the rest.


>Otherwise you have an inefficient database that has no reason to exist.

That doesn't mean it isn't a blockchain. A inefficient or poor implementation of something is still an implementation of that thing.

>People think you just need Merkle roots including previous blocks, like you do, but that’s useless and pointless without the rest.

I'm well aware of the additional properties required to get it to behave like bitcoin or have cryptographic safety. But those are to my knowledge not a must-have for a blockchain nor defining characteristics.

As the name implies, it's a chain of blocks, the less obvious part is you link them with something cryptographic.

And just because Blockchain was first used and defined in Bitcoin doesn't mean the definition or methodology cannot be separated from Bitcoin, in fact, I consider it heavily separated from Bitcoin by now.

And again, just because they are factors in making Bitcoin work doesn't mean you need them to make a Blockchain.


Except that's a merkle tree. Which we already have a word for. Git isn't a blockchain, but it is a merkle tree. Blockchains are merkle trees, but the reverse isn't true.

A reasonable definition might be that a blockchain is a decentralized merkle tree.


I think the most general thing you could say is monadic mutations of some global state. Blocks act as operators on this state. I don't necessarily think it has to be a consensus algorithm. It can be used as that though.


Blocks are taken as part of the blockchain once there is consensus amongst the nodes that it is valid, so the consensus algorithm (as well as the POW algorithm) are integral parts of what makes a blockchain a blockchain


That's just event sourcing. The innovation in the bitcoin whitepaper was the consensus algorithm.


So they'd have to do something like publish the hashes in a major newspaper?


This isn't exactly new, and not only for the reason in the article - Check out NetNotary from back around that time, too: They published their checksums daily in the WSJ, IIRC. Could be wrong, but I seem to recall NetNotary was a Marshall Rose/Carl Malamud project...


Is there actually any chaining going on, or is this a standard "trusted timestamp"? https://en.wikipedia.org/wiki/Trusted_timestamping


The article doesn't make it totally explicit, but it sure sounds like each new hash incorporated the previous one.

(It's also possible that each published hash is just a brand new hash of the aggregate, but this seems somewhat less likely based on the wording.)

ETA: Looks like it's a chain, or rather a Merkle tree. From the horse's mouth: https://news.ycombinator.com/item?id=17865168


A Merkle root including previous Merkle roots may have been innovative when Surety started, but while its required in bitcoin its not a key feature of what defines a Blockchain.


Given that "blockchain" is a generalization of Bitcoin, not formally defined theoretically beforehand, I suspect we would not agree on what a blockchain even is, and would go 'round and 'round in circles.

But I think we can agree that a Merkle chain like this would be sufficient for most of the things people are trying to use blockchains for recently, which certainly says something.


Yea, I think most would lean towards requiring one or both of:

    - it's a distributed consensus system (often around "blocks", but e.g. iota is not)
    - it's a chain of hashes to prevent mutation (around "chains")
And I doubt we'll ever get everyone to agree on what subset (including null) of those are "a blockchain".

Very (very) few things benefit from distributed consensus IMO. And not all altcoins use blocks at all. So I tend to lean towards hash-chains. Publicly-verifiable immutability is useful in quite a lot of real-world scenarios.


i don't see evidence that it's really a block-chain since the data are not dependent on the previous block, i.e. it's not a linked list ("chain") data structure.


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.


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...


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.


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"...)


> 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.


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


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..."


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.


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".


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.


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


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.


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.


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


Thanks for clearing that up!


It doesn't have to be. The purpose of chaining in the blockchain is to establish an unspoofable temporal ordering of events. In the case of the NYT, you can just look at the date on the paper, so chaining isn't strictly necessary.


Widespread use of this technology would be a problem for government, since it would be difficult to insert fake records to create "legends" for undercover detectives, spies, and people in witness protection, etc.


Widespread use of Facebook might have a much more significant effect, because people don't usually memorialize all of their life events in a public digital notary service but often do so with social media.

I bet counterintelligence agencies are scraping social media and the web in order to see whether some travelers' identities are lacking in (or contradicted by) historical online documentation.


No the oldest block chain was invented by Acient Greeks, take Homer's Odyssey and Iliad. They are similar to blockchain as follows:

- Memorization of whole piece == Proof of work - You need lots of people to agree upon the story == 51 % of nodes - You can only append to the piece, because many others know and have memorized the piece so they will not agree to your version.


Interesting. Now how do we turn this into virtual currency?


I've got an idea - classified advertising!

We'll start selling space in the coinbase field to real estate advertisers and escort services!

'The Times 03/Jan/2009: room to rent in 3br share house in The Mission, $2600/month+utilities'


Initially I thought this was commissioned advertising, and it did read as such.

However, the ex-CEO has mentioned that it only operates for existing customers (https://news.ycombinator.com/item?id=17865294), which conflicts with that view somewhat, so maybe this isn't an ad.

In any case; where can I view 1995 copies of NYT for free? :)


> In any case; where can I view 1995 copies of NYT for free? :)

Every public library in the United States, if I'm not mistaken, and a large number of major libraries worldwide.


Hmm. I was hoping there was a way I could do so online.

Mumbles something about equal opportunity open access and the bourgeois


New York Public Library, with a library card: https://www.nypl.org/blog/2013/08/22/how-to-search-nytimes

Los Angeles Public Library, with a library card: https://www.lapl.org/new-york-times-digital (and you can apply for an e-card online for free: http://www.lapl.org/about-lapl/contact-us/e-card/e-card-regi...)

Kansas City Public Library, with a library card: https://www.kclibrary.org/blog/kc-unbound/how-read-back-issu...

Etc.

Summary: get a public library card, support the oh-so-terribly bourgeois public library system ;)


This is fair, but I don't know how much the National Library of Australia has, or whether access is free. Sorry I forgot to mention my location in my previous comment.


Article has autoplaying audio


You can turn this off in many browsers nowadays (media.autoplay.enabled in Firefox). Still good to call it out though.


So essentially a checksum. Using that logic, blockchains have been hiding within the internet forever because tcp/ip protocol employs them.


there are no blocks and therefore calling it an blockchain is pure clickbait. what we have here is a chain of hashes


Bitcoin's innovation was trust and conflict resolution through proof of work, not linked lists of hashes.


There is difference between bitcoin and blockchain. A blockchain is, by definition, a linked list of hashes.


That's just called a hash chain, Bitcoin I believe just calls it a chain of hashes. The block data structure incl. salt and POW is what is so unique about Bitcoin.


“By definition” people are just making up “Blockchain” as a desperate technology, usually people who don’t understand how bitcoin works and don’t realize they are throwing the baby out with the bathwater.

Redefining the nature of the technology to get away from the difficult reality of it isn’t effective in the end.


This describes something from Surety, LLC. Too bad their web page doesn't have https. Hard to take them as seriously. http://surety.com/


I believe the company is only active in that it still operates its service for existing customers. The website is very old, but you're right, it's admittedly ironic that a computer security company has an HTTP website.



If the page that links to the login page hasn't proven it's secure, I shouldn't trust the links, and therefore shouldn't trust the destination. Hence why static landing pages need HTTPS just as much as login pages.


Fair enough, although you could check that the domain names are the same in this case.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: