>I was wondering if it had a name
Yes: blockchain.

By itself it doesn't prove authenticity, though. It only proves integrity. To prove authenticity it would need to incorporate asymmetric cryptography in some way, or participants would need to confirm received hashes via a trusted channel.

Input to previous hash: "antisocial disinfectant"

>>17

I don't think it's a blockchain. In a blockchain, each block contains a hash of the previous. I don't remember having heard of what I am describing in a blockchain. I could be misremembering though.
Also, blockchains have consensus mechanisms such as PoS, FBA and PoW. My scheme does not.

I don't think it proves integrity either (by this definition: https://en.wikipedia.org/wiki/Information_security#Integrity "data integrity means maintaining and assuring the accuracy and completeness of data over its entire lifecycle.[75] This means that data cannot be modified in an unauthorized or undetected manner"). An actual blockchain as described above might go some way towards that though.

Next hash: 9bd31ba95eb2dc3370ab1255b01b54159724dc410d8c17e8bdf5476374455d00

Previous input: "CBT oil"

"Password chain" is a good term, since the inputs are like passwords, and passwords are already verified using hashes.
Or "tripcode chain", since the hashes are like "insecure" (without salt) tripcodes.
I wanted to use "hash chain" but that was already taken.

One problem with this technology is what if the chain splits across multiple "places" i.e. forums? Someone who sees the first message at the second place can go over to the first place and post a message with its password.
This tech only works if everyone is looking at the whole chain, or if the chain stays in one place.

>To prove authenticity it would need to incorporate asymmetric cryptography in some way, or participants would need to confirm received hashes via a trusted channel.
I said prove authenticity "given the authenticity of the first", not absolutely. And also given the trustworthiness of the underlying medium (an admin of a forum could still change the message).

All in all, it seems like a pretty useless protocol compared to something like RSA or Lamport signatures. Oh well, it might end up being useful as part of something else, or in a different form.

Next hash: cd0562b3117cbc9cdbf36091219732d92acb80ccf837f3eb70f354f9fd2cbacd

>>17578
Oh! You mean you include in each message the input to the hash in the previous message. Sorry, I misunderstood. What you're referring to is known as proof of knowledge.

>Also, blockchains have consensus mechanisms such as PoS, FBA and PoW.
A blockchain is merely a data structure where each block is linked to the previous block (or some number of blocks) via a hash. It does not imply a distributed system. Even if there is a distributed system, the consensus algorithm can be as simple as "whatever the authoritative source says", which is pretty much how Git is typically used.

>>17579
>I said prove authenticity "given the authenticity of the first", not absolutely.
If that's all the assurance you want, you could also include your ECDSA public key in the first message and the signature for each subsequent message. Then you wouldn't need to keep track of which secret message you used as input to the previous hash.
Needless to say, neither method protects you if the site's operator decides to rewrite you messages.

>All in all, it seems like a pretty useless protocol compared to something like RSA or Lamport signatures. Oh well, it might end up being useful as part of something else, or in a different form.
Well, you're just using it wrong, I'd say. Proofs of knowledge are typically used to prove that you had a piece of information at an earlier time that you decide to disclose that information. For example, you might make public a hash predicting that the stock market will crash this week, and after it crashes you make public that information, which should hash into the previous hash.

Previous password: "Rose Mary"

>>17580
I've heard of proofs of knowledge. Though I dont think I've heard of them by that name.

> you could just use ECDSA
How fast is it to generate an ECDSA keypair and sign messages? IIRC RSA is slow compared to this scheme.

Next hash: 5fcb6406566e4cbe34ceb9ee0cc2cf02f729842c369936763b550101ae8c7354

>>17581
IIRC, almost all naturals less than 2^256 are valid Secp256k1 private keys, so picking a private key is just a matter of getting a few random bits. I think there were exactly two points on the curve that were unusable; one was an inflection point with only a single solution to the equation and the other's tangent was vertical.
Other curves may work differently, although I think all ECDSA curves are more or less the same with only the coefficients changing. As I recall, Curve25519's curve is somewhat different.

Signing a message with ECDSA is faster than RSA, but slower than getting a SHA-256 digest, because the process involves hashing the message. In particular, Secp256k1 uses SHA-256.