[messaging] Thoughts on keyservers

[Tao Effect]

On Aug 28, 2014, at 11:35 AM, Tom Ritter <tom at ritter.vg> wrote:

> Or by timestamping.  Blockchain if you're set up to do that, CA
> timestamping if you're rich, hashes on twitter if neither, or a
> Merkle-Tree log in the future.

Twitter is an interesting topic (to me). When analyzing the "security" of any centralized authority (like twitter), I like to think out way into the future, to 1984, when Big Brother looms large.

That usually quickly discounts any central authority as being a reliable entity to ensure the integrity of the data. There have been many instances already where twitter has been responsible for irresponsible censorship [1] [2].

The problem with services like twitter, for example, is if a tweet is taken down, it doesn't matter much even if a timestamped signed merkle root hash exists for it, as the original data is gone (maybe someone archived it? Maybe someone didn't? Was it in the original form that can be used with the Merkle Tree? Probably not.)

With a blockchain-based twitter (or a blockchain-based notary), none of this is a problem: http://twister.net.co

With blockchains, the #1 problem is instead the consensus algorithm.

Bitcoin and Namecoin's consensus algorithms aren't good enough right now. They suffer from:

1. Wasting resources. (Have you seen how much electricity these "bitcoin mines" use on generating hashes??)
2. Being too easily 51% attacked by a single entity or group.

There are alternative consensus algorithms that might addresses these issues:

- https://eprint.iacr.org/2014/452.pdf
- https://github.com/tromp/cuckoo
- https://bitcointalk.org/index.php?topic=309073.msg7385002#msg7385002
- http://letstalkbitcoin.com/blog/post/solution-to-sybil-attacks-and-51-attacks-in-decentralized-networks

I haven't vetted all of these, am just linking to them in case someone else has the time to investigate. There are even more that I haven't listed. Lots of interesting research going on in the area of consensus algorithms.

I think the best way to figure out the "right" consensus algorithm is to first figure out what the theoretical ideal would look like. Maybe it's "one-human stakeholder one-vote" ?

Even that ideal suffers in reality because one rich human can bribe other (poor) humans to vote in their favor. That is the reason why many countries have laws requiring a secret ballot.

Once an ideal (that most can agree on) is found, we should see how to best approximate it algorithmically. Any thoughts as to what such an ideal could look like?

Cheers,
Greg


[1] https://twitter.com/taoeffect/status/503240066563862528 (read the whole tweet thread, this link is to the end of it).

[2] https://firstlook.org/theintercept/2014/08/21/twitter-facebook-executives-arbiters-see-read/

[3]

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On 28 August 2014 10:33, Alaric Snell-Pym <alaric at snell-pym.org.uk> wrote:
>> Yes; providing security against plagiarism is another interesting topic
>> - and pretty tricky when the plagiarist is a MITM :-) If not, then
>> plagiarism can often be at least detected after the fact, by the
>> original turning up as well as the plagiarised version, or the original
>> author seeing their own content with another's signature on it. In
>> practice, we can reduce the impact of plagiarism on
>> crypto-identity-theft by making an effort to use the same
>> crypto-identity (or linked crypto-identities) in lots of different
>> environments, to make it hard to MITM them all. I use the same GPG key
>> to post stuff here and to sign various things on
>> http://www.snell-pym.org.uk/alaric/ (including references to other keys
>> I hold), and for other mailing lists and public mails, for instance -
>> from a variety of Internet connections.
> 
> 
> Or by timestamping.  Blockchain if you're set up to do that, CA
> timestamping if you're rich, hashes on twitter if neither, or a
> Merkle-Tree log in the future.  If you're worried about plagiarism,
> you timestamp your content, and challenge anyone plagiarizing it to
> produce a timestamp prior to yours.  (Of course this works better if
> whoever consumes content from you is trained to expect it to be
> timestamped.)
> 
> -tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140828/73a7c224/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140828/73a7c224/attachment.sig>