[maccard]

> it is fine to publish those signatures on a website you are known to control (or Tweet them out or whatever).

Say I tweet, post on reddit and internet archive both of those pages. When somenoe goes to verify later on, the 4 values are different to the value you've provided to me. Which of the 5 values is trustworthy? This is the problem that a blockchain verifies, in theory.

Unfortunately, there's two different answers, depending on what we're actually sharing. If we're sharing something that confirms my identity, the only correct answer is "it doesn't matter, you are not who you say you are".

If we're sharing something that proves something happened, the answer is "I need to choose one of the N options to trust", and unfortunately going down this path should leave you to "it doesn't matter, I can't actually verify what happened without trusting _someone_". The reality of both situations is that it doesn't matter whether or not the trust is centralised or not centralised, the action you take in both cases is the same - you stop trusting and look elsewhere. And Blockchains can't solve that problem.

[pclmulqdq]

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.

[maccard]

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

[pclmulqdq]

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.

[kuramitropolis]

>Publish those documents wherever you want

And where would one publish such documents, so that they would not be under the control of any single party?

[pclmulqdq]

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

[kuramitropolis]

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?