Dist.ribut.us: Difference between revisions
Adamcolton (talk | contribs) No edit summary |
Adamcolton (talk | contribs) No edit summary |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
* [http://beej.us/guide/bgnet/pdf/bgnet_A4.pdf Sockets] | * [http://beej.us/guide/bgnet/pdf/bgnet_A4.pdf Sockets] | ||
* [https://www.youtube.com/watch?v=XnfAZHkyOy4 Byzantine Paxos] | * [https://www.youtube.com/watch?v=XnfAZHkyOy4 Byzantine Paxos] | ||
* [https://www.youtube.com/watch?v=Q0xYCN-rvUs Practical Byzantine Fault Tolerance (PBFT)] | * [https://www.youtube.com/watch?v=Q0xYCN-rvUs Practical Byzantine Fault Tolerance (PBFT)] technically good, hard to follow | ||
* [https://www.youtube.com/watch?v=Qone4j1hCt8 Byzantine Honey Badger] | * [https://www.youtube.com/watch?v=Qone4j1hCt8 Byzantine Honey Badger] [https://eprint.iacr.org/2016/199.pdf Paper] - really interesting, 10K tps consensus | ||
* [https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf Impossibility of Distributed Consensus] | * [https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf Impossibility of Distributed Consensus] | ||
* [http://www.gsd.inesc-id.pt/~mpc/pubs/ritas-tdsc.pdf Ritas protocol] | |||
* [https://www.youtube.com/watch?v=_e4wNoTV3Gw Byzantine Fault Tolerance] (part of a course) | |||
* [https://www.youtube.com/watch?v=bWKK_z-Rh4Q Async Consensus] Covers several interesting consensus ideas | |||
* [https://www.youtube.com/watch?v=SmyUBbuXfxI Fundamentals of Distributed Algorithms] | |||
* [https://people.mpi-sws.org/~druschel/publications/sigcomm15-herd.pdf Herd (Anonymous VOIP)] | |||
* [https://www.usenix.org/legacy/events/sec02/full_papers/maniatis/maniatis.pdf History Preservation] (I think this is the origin of blockchains) | |||
* [https://www.youtube.com/watch?v=35XrP4rjZr0 Herd] Good data on anonymity related to meta-data | |||
* [https://ont.io/wp/Ontology-Introductory-White-Paper-EN.pdf Ontology] | |||
* [https://raiblocks.net/media/RaiBlocks_Whitepaper__English.pdf RaiBlocks] | |||
* [https://www.abitgreedy.com/transaction-speed/ Look at TX speeds] | |||
See [[DHT]] | See [[DHT]] | ||
| Line 30: | Line 40: | ||
* Merkle Tree | * Merkle Tree | ||
* Block-chain | * 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. | |||
== Crypto == | |||
https://github.com/kevinburke/nacl | |||
[[Category:dist.ribut.us]] | [[Category:dist.ribut.us]] | ||
[[Category:Projects]] | |||
Latest revision as of 15:33, 23 August 2018
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)
- Async Consensus Covers several interesting consensus ideas
- Fundamentals of Distributed Algorithms
- Herd (Anonymous VOIP)
- History Preservation (I think this is the origin of blockchains)
- Herd Good data on anonymity related to meta-data
- Ontology
- RaiBlocks
- Look at TX speeds
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.