Dist.ribut.us

Technical Papers

• DC (dining cryptographers) approach
• BitTorrent Specification
• Decentralized Consensus
• https://github.com/bounce-chat/go-i2p
• https://www.youtube.com/watch?v=8CMxDNuuAiQ
• Sockets
• Byzantine Paxos
• Practical Byzantine Fault Tolerance (PBFT) technically good, hard to follow
• Byzantine Honey Badger Paper - really interesting, 10K tps consensus
• Impossibility of Distributed Consensus
• Ritas protocol
• Byzantine Fault Tolerance (part of a course)

See DHT

Important Concepts

• NAT Traversal
• Crypto
  • Symmetric
  • Hashing
  • Asymmetric
    • Key Exchange
    • Signing
    • RSA
    • Elliptic Curve
• DHT
• Consensus
  • Paxos
  • PBFT
• Erasure Codes
• Merkle Tree
• Block-chain

Dining Bloom Filters

This is still very rough.

A combination of the dining Cryptogrphers with a Bloom filter (and a sort of Paxos phase). Nodes are paired up in groups and each group establishes a shared key. So given A,B,C,D,E; A ends up in AB, AC, AD, and AE and if the the filter array is supposed to be 100 bits long, the shared key for each will be 25 bits. Each node figures out the bits they want to write and writes them as in DC. Then everyone either signs or rejects the whole thing. Now someone can look for a hidden signal in the message.

This has the DC weakness that a malicious node can make writes that will falsely flip bits. I think there's two ways to handle this. One is to have everyone involved sign the output. I'm not sure about the other - I think we can set a limit on the number of bits you can flip and just include enough bits that even if you attack all the bits you can, the odds of corrupting a message are low. And the sender of the message you corrupted can just send in the next round.

The output is like Cherry Ripe. A seemingly meaningless jumble of bits. But the probability of the bits lining up with resource hash is very, very low. So if that happens it means someone probably requested that resource.