4 ms·
Sorry, what I was stating has nothing to do with finance at all. We've created a new web. A truly decentralized web. The blockchain should only be used for non
by guylepage3 10y ago
Sorry, what I was stating has nothing to do with finance at all. We've created a new web. A truly decentralized web.
The blockchain should only be used for non-financial applications.
- lucozade 10y ago> The blockchain should only be used for non-financial applications Do you really mean it shouldn't be used in any financial applications or just not to replace fiat currencies? If the former could you elaborate on why? I'd be very interested in your opinion.
- alanwatts 10y agoPerhaps it is because the fundamental nature of "finance" as a social conception is inherently centralized. So any purposefully decentralized/distributed system used for financial (centralized) purposes becomes corrupted by default.
- nix0n 10y agohttps://blockstack.org/docs/how-blockstack-works https://blockstack.org/docs/how-blockstack-works has some interesting info. I'm on board with the idea of a DNS replacement using a distributed hash table but I'm not clear on why Bitcoin specifically or a blockchain generally need to be involved.
- jude- 10y agoThe problems with using DHTs for naming are: * Locality-unaware routing. Your lookups can bounce around the planet a few times before reaching the right key, leading to extremely high and extremely variable latency. This can be mitigated with DSHTs (e.g. CoralCDN from NYU) and/or with some clever key/value distribution schemes (e.g. Beehive from Cornell). * Route censorship attacks. DHTs are vulnerable to sybils, which can take over all the routes for a particular set of keys and censor them. * DDoS attacks. Nothing stops you from inserting a bunch of junk key/value pairs and overwhelming the DHT nodes. * Churn attacks. A few sybils can add a bunch of nodes, stay online for a while, and then disappear over a phased withdrawal period. This leading to high node churn, which leads to content unavailability and network partitions. * Content attacks. Unless the DHT's key is the cryptographic hash of its value (not the case in DHT-based DNS), nothing stops you from inserting invalid routes for the same name. Signing the value with a keypair doesn't help either, since that simply changes the name-to-IP lookup problem into a name-to-key lookup problem (i.e. how do you know the "right" key produced the signature?). * Route hijacking. Again, if your DHT isn't content-addressed, sybils can simply take over routes for a set of keys and serve you the wrong values intentionally. The reason Blockstack uses a blockchain to bind a human-meaningful names to hashes is because blockchains are decentralized, inimitable, and totally ordered. Each blockchain peer has a 100% replica of the system state, so the above limitations do not apply. Since they're expensive to imitate and since they're totally ordered, they can be used to enforce name acquisition on a first-come first-serve basis. But of course, the trade-offs are that writes are slow, writes require PoW, and space requirements grow linearly. Blockstack in particular addresses this by using a blockchain to bootstrap name/key bindings, and then storing signed data off-chain in commodity storage providers (peer-reviewed paper at https://blockstack.org/blockstack.pdf https://blockstack.org/blockstack.pdf). Disclaimer: I'm one of the authors.
- nix0n 10y agoThank you, that's very informative.