[web3isgoing]

As I understand, DHT is vulnerable to sybil and eclipse attacks, and not really suited to the task of creating a tamper proof log. If the log and timestamping is not tamper proof, key rotations can be spoofed. Users in the network may need to come to consensus about the ordering of events, such as if signed documents A and B are order dependent. See:

https://news.ycombinator.com/item?id=33639578

Simpler than DHT is just a server hosted in the US somewhere, like what keybase.io is doing, but that goes against my goal of decentralization.

[chriswarbo]

> As I understand, DHT is vulnerable to sybil and eclipse attacks

So are blockchains. However, blockchains are much harder to secure, since they need to preserve the order of the ledger (for Bitcoin that's a total-order; there are some chains which only require partial-order). That forces all transactions to jump through hoops, like proof-of-X; even if they're not under attack.

> not really suited to the task of creating a tamper proof log

That's my point; why impose a log (and hence a total-order of events)?

> Users in the network may need to come to consensus about the ordering of events, such as if signed documents A and B are order dependent.

That's a heck of a hypothetical; and it's solvable without baking order-dependence into everything, e.g. we can embed the hash of one document inside another document; or we can provide hashes-of-hashes (Merkle trees), etc.

[web3isgoing]

> So are blockchains. However, blockchains are much harder to secure, since they need to preserve the order of the ledger (for Bitcoin that's a total-order; there are some chains which only require partial-order). That forces all transactions to jump through hoops, like proof-of-X; even if they're not under attack.

This hardness is what makes them tamper proof, and more resistant to sybil and eclipse attacks than a DHT.

> why impose a log (and hence a total-order of events)?

To quote my linked post:

>> Vitalik, or maybe a charitable non profit organization, signs two PDFs: one says "our new public key is X" and the other says "our new public key is Y." Both of these documents verify correctly, but how do you know which is the latest? One approach is to use Twitter as your append-only timestamped ledger, and broadcast a link to the latest file on IPFS. Another is to build a new centralized service and promise it is secure and will not get hacked or mutated. Another is to rely on a public distributed ledger that is verifiably secure and strongly resistant to modification.

> That's a heck of a hypothetical; and it's solvable without baking order-dependence into everything, e.g. we can embed the hash of one document inside another document; or we can provide hashes-of-hashes (Merkle trees), etc.

Key rotation, financial statements, exchange of assets, loans and borrowing, social messaging interactions, many things in our world are order and time dependent.

Using hashes-of-hashes as you suggest does create an order, but without the distributed consensus mechanism. If there is a fork split, like two key rotation documents both signed by vitalik.eth pointing to two different new addresses and creating two independent chain of hashes, how does the system know which new chain is correct?

To solve this you might store the chain of messages in an append only ledger, like posting on centralized Twittter, or posting on a decentralized blockchain. This is where the original conversation started from: what if instead of having a single centralized and mutable ledger to store these signed messages like keybase.io, you build on top of a decentralized and immutable ledger. Private versus public infra.