Like I said to someone else, the real answer is to not sign documents that are wrong. To avoid doing this, you might have to be more precise than "my public key is X." You probably should include a timestamp, an expiration for the key, a hash of the previous message so people can tell what is supposed to supercede what, etc.
That way, if people get multiple messages from you, they can actually verify which one is supposed to be the most recent and what your key actually should be.
That will solve your problems and let you disseminate public keys through Twitter.
> Like I said to someone else, the real answer is to not sign documents that are wrong.
If "don't make mistakes" was a viable solution, we just wouldn't have a whole family of problems.
> you probably should include a timestamp, an expiration for the key, a hash of the previous message so people can tell what is supposed to supercede what, etc.
An expiration for your current key doesn't _really_ help the problem of "I don't know where to get the next key from". A blockchain _in theory_ formalises the "disseminate your public key through this accessible place" (which you've defined as twitter, I might define as a CA registry that comes with browser and someone else might define as a blockchain), but this solution doesn't actually solve the problem of "the public key is different, which one do I use?" which _is_ what a blockchain does, except in reality, it's useless because when these things diverge you almost certainly look elsewhere for trust.
By the way, this chain of documents with precise information is a blockchain in itself. You don't need another one. Particularly not for disseminating information, where it doesn't really solve any problems. Publish those documents wherever you want, and include the appropriate information so that they are not wrong. That's a blockchain.
I will add that "don't make stupid mistakes" is a key tenet of cryptography in general - and blockchains in specific.
I publish them somewhere I have control, like my website, and ask archiving services to archive that page. I don't need them to be under nobody's control.
If someone compromises my blockchain keys, it's about as bad as if someone compromises my website (in terms of the actual attack vectors).
Unless you go full self-hosted, your website is also under the control of your hosting provider and DNS registry. You implicitly trust those, until you don't. (See the Linode/Itch.io gaffe from the other day.)
And what if your use case requires you to prove to others that you (or your publisher) can't surreptitiously and arbitrarily alter the information you published?
That way, if people get multiple messages from you, they can actually verify which one is supposed to be the most recent and what your key actually should be.
That will solve your problems and let you disseminate public keys through Twitter.