On Aug 28, 2014, at 11:35 AM, Tom Ritter <[email protected]> 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 <[email protected]> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to