6 ms·

The internet basically only works because small entities have as much standing and control as large entities. This is also why things like RPKI are required, to

by ixfo 4y ago

The internet basically only works because small entities have as much standing and control as large entities. This is also why things like RPKI are required, to prevent small (and large!) actors causing disruption through malicious or accidental configuration of e.g. BGP. Whereas in a blockchain, if you assume the participants are the same set of actors - which would make sense - then it would be very easy for a majority of network control to be held by a Google, an AT&T, a China Telecom, etc. Introducing third-parties who are not neccesarily involved in the operation of networks to said blockchain also opens up BGP operators to a whole new raft of attacks. Want to blackhole an ASN? If you can convince a smart contract that the routing policy for that ASN is "drop all traffic" then you don't even need to compromise people's routers or muck around with all that messy DDoS stuff. Bad, bad idea. Just like 99% of stuff with the word "blockchain" in it.

dgellow 4y ago
What would you say are the 1% of stuff with blockchain in the name that aren’t bad ideas?
- rvz 4y ago
  Don’t bother asking here about anything with the word ‘blockchain’ since not only it is poisonous here, but it is guaranteed to be quickly dismissed without any curiosity of the 1% of applications it may have. Here are a few that are part of that 1%: [0] https://skiff.org https://skiff.org [1] https://ens.domains https://ens.domains [2] https://impervious.com/beacon https://impervious.com/beacon
  - throwaway82652 4y ago
    I'm sorry but absolutely none of those applications need blockchains or even benefit from them at all. If you want to discuss this I could go into extreme detail why that's the case. I can understand being excited about the promises made by them but at some point we all need a good reality check. Having curiosity doesn't suggest any particular kind of acceptance, we can actually accept that something is universally useless and not worth our time. I'm not saying this because I want to crap on people's startups, I'm saying this because they could make a lot better products if they weren't getting wrapped up in this.
    - everfree 4y ago
      I actually wouldn't mind you going into detail about why naming systems like ENS do not benefit from being on a blockchain, as they seem to me to be one of the more obvious use cases. If the default path of technology were such that our current DNS system were based on a blockchain smart contract system, and then someone proposed a new system with single points of failure, reliant on trusted recursive resolvers, registrar middlemen, a trusted root zone for every country, and a tacked-on CA system that requires fully trusting N-of-N organizations dotted across every jurisdiction on the globe whose job is to verify address resolution from multiple network perspectives, plus OCSP and CT servers to enforce revocations and maintain certificate history - both of which are problems directly caused by a non-blockchain system design - they would be laughed out. With ENS: * The blockchain itself is the root of trust, because every name entry has an associated owner entry and every owner entry has a public key entry, which can be used to encrypt and authenticate content. * Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software. * Users can register names directly by using a piece of software, without requiring registrar companies. * The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers. * In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS. If you want to go into "extreme detail", now is the time. Please tell me why I am wrong.
      - throwaway82652 4y ago
        >they would be laughed out. No they wouldn't because almost all of those properties are actually desirable, and the only real achievement of ENS is to approximate all of that. Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise. If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain. I'll address each of your points. >The blockchain itself is the root of trust Which is the single point of failure. >Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software. This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism. >Users can register names directly by using a piece of software, without requiring registrar companies. This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way. In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract. >The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers. This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers". >In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS. The solution here would be to just add more redundancy to DNS, blockchains again don't do anything special.
everfree 4y ago
> if you assume the participants are the same set of actors - which would make sense - then it would be very easy for a majority of network control to be held by a Google, an AT&T, a China Telecom, etc. Why wouldn't one just design such a system to give each entity equal sway over the network? One entity, one vote.
- jimmydorry 4y ago
  What would stop an entity creating many other entities to sway voting outcomes? This would be referred to as a Sybil attack. I think you would need something like a web of trust (each entity is responsible for the actors they vouch for). Otherwise, some kind of proof of how many users they represent.
  - everfree 4y ago
    > What would stop an entity creating many other entities to sway voting outcomes? A hard-coded initial entity set, along with a voting process for additions to and removals from that entity set. In other words, a classic DAO design.

by ixfo 4y ago

dgellow 4y ago

What would you say are the 1% of stuff with blockchain in the name that aren’t bad ideas?

rvz 4y ago
Don’t bother asking here about anything with the word ‘blockchain’ since not only it is poisonous here, but it is guaranteed to be quickly dismissed without any curiosity of the 1% of applications it may have. Here are a few that are part of that 1%: [0] https://skiff.org https://skiff.org [1] https://ens.domains https://ens.domains [2] https://impervious.com/beacon https://impervious.com/beacon
- throwaway82652 4y ago
  I'm sorry but absolutely none of those applications need blockchains or even benefit from them at all. If you want to discuss this I could go into extreme detail why that's the case. I can understand being excited about the promises made by them but at some point we all need a good reality check. Having curiosity doesn't suggest any particular kind of acceptance, we can actually accept that something is universally useless and not worth our time. I'm not saying this because I want to crap on people's startups, I'm saying this because they could make a lot better products if they weren't getting wrapped up in this.
  - everfree 4y ago
    I actually wouldn't mind you going into detail about why naming systems like ENS do not benefit from being on a blockchain, as they seem to me to be one of the more obvious use cases. If the default path of technology were such that our current DNS system were based on a blockchain smart contract system, and then someone proposed a new system with single points of failure, reliant on trusted recursive resolvers, registrar middlemen, a trusted root zone for every country, and a tacked-on CA system that requires fully trusting N-of-N organizations dotted across every jurisdiction on the globe whose job is to verify address resolution from multiple network perspectives, plus OCSP and CT servers to enforce revocations and maintain certificate history - both of which are problems directly caused by a non-blockchain system design - they would be laughed out. With ENS: * The blockchain itself is the root of trust, because every name entry has an associated owner entry and every owner entry has a public key entry, which can be used to encrypt and authenticate content. * Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software. * Users can register names directly by using a piece of software, without requiring registrar companies. * The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers. * In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS. If you want to go into "extreme detail", now is the time. Please tell me why I am wrong.
    - throwaway82652 4y ago
      >they would be laughed out. No they wouldn't because almost all of those properties are actually desirable, and the only real achievement of ENS is to approximate all of that. Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise. If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain. I'll address each of your points. >The blockchain itself is the root of trust Which is the single point of failure. >Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software. This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism. >Users can register names directly by using a piece of software, without requiring registrar companies. This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way. In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract. >The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers. This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers". >In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS. The solution here would be to just add more redundancy to DNS, blockchains again don't do anything special.

everfree 4y ago

> if you assume the participants are the same set of actors - which would make sense - then it would be very easy for a majority of network control to be held by a Google, an AT&T, a China Telecom, etc. Why wouldn't one just design such a system to give each entity equal sway over the network? One entity, one vote.

jimmydorry 4y ago
What would stop an entity creating many other entities to sway voting outcomes? This would be referred to as a Sybil attack. I think you would need something like a web of trust (each entity is responsible for the actors they vouch for). Otherwise, some kind of proof of how many users they represent.
- everfree 4y ago
  > What would stop an entity creating many other entities to sway voting outcomes? A hard-coded initial entity set, along with a voting process for additions to and removals from that entity set. In other words, a classic DAO design.