6 ms·

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. There is zero security if yo

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. There is zero security if you dismiss every such measure to accomplish a level of security by saying that its just 'random crypto' that doesn't accomplish anything (why do you say that?) >Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. I think there may be some confusion in your understanding of the system. Registered names aren't visible, only their hashes. The design masks names through a verifiable delay function which forces registering parties to do lengthy computations to construct the lookup function. Since computations can be stored in bulk - names can be registered atomically across IRC servers without revealing what they are directly. >Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. In the context of networking 'sybils' refer to being able to create multiple identities, machines, or so on controlled by the same person. But your usage of the term here is confusing because (1) users don't control third-party servers (2) users can't see names directly (3) there is a cost to creating names (4) and a threshold system is used to do consensus over name lookups and registrations (which was designed to solve the problem you're talking about.) >The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with. I would love to use a blockchain for this. There's only one problem. Currently there are no such blockchains that have zero transaction fees to use them. I think that such a system would be very useful. But it seems that no one wants to do it -- and working at blockchain startups for more than a decade has taught me that bolting forced monetization and funky tokens onto everything can make a system worse (or even unusable) for its intended purpose. I think if you re-read the post you will see how I've addressed the problems you raised.

charcircuit 3y ago
>why do you say that? Because the information needed to lookup a name is equivalent to the information needed to register the name. >Registered names aren't visible, only their hashes. But domains are public information. Imagine if in normal DNS anyone could register google.com at any time. Claiming that its not insecure because people don't know google.com exists doesn't make sense. >names can be registered atomically across IRC servers without revealing what they are directly. But if someone learns the name they can register it themself. Two people can both claim to be google.com. If a new IRC server is added anyone can create a channel for an existing domain. If your answer to the problem of the same domain being registered by multiple people is that a domain should be both a name and an encrypted nonce you run into the problem where it might be more convienent to just pass over the public key. >But your usage of the term here is confusing That is my fault, I assumed this was a permissionless system where any IRC server was permitted to be used instead of a permissioned one. >Currently there are no such blockchains that have zero transaction fees to use them. Some cost near $0. A fork of one could be made to do so.
- Uptrenda 3y ago
  The channel names are unique per server. Knowing the channel name isn't enough to infer what name it represents so you can't just go and register the name on other servers after observing channel names. The only way to know what a channel name represents is to do a lengthy computation for a possible name, tld, password (optional), and server. Depending on uniqueness -- this might not be practical. The idea of having masked names was only to prevent race conditions in the initial registration process. After the channel names are registered they are unavailable for other attackers to register and since a verifiable delay has to be done on the name to compute it -- there is adequate time to register the name across multiple servers. A malicious server can reuse a channel name and have it hijacked by an operator. But the system also ties in ECDSA signatures with a basic threshold consensus algorithm across servers. So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
  - charcircuit 3y ago
    >The channel names are unique per server. But there is not a limit for how many channels can exist for a single domain. >After the channel names are registered they are unavailable for other attackers to register Yes, but an attacker can use a different channel name for the same domain. >So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name. An attacker could associate their own key with that domain any number of times across any number of servers.
    - Uptrenda 3y ago
      I'm not sure I understand what you mean. One channel is registered per server, for one name. Successful registrations require a super majority of those registrations to succeed. Lookups can be limited to a sub-set as long as the result number is at least greater than the minimum failure threshold for a successful registration. >Yes, but an attacker can use a different channel name for the same domain. >An attacker could associate their own key with that domain any number of times How?
      - 3y ago
baobun 3y ago
OK, so, one thing isn't clear to me: 1. Alice registers example.tld 2. Bob registers example.tld 3. Bob reveals example.tld 4. Alice reveals example.tld It seems there is now two rooms corresponding to the same name. Who controls example.tld? I'm missing uniqueness and it still seems vaguely racey.
- Uptrenda 3y ago
  Both Alice and Bob check if a name is already registered beforehand. Lets say that both of them see that a name is available and go to register it at the same time. Either both will fail (due to taking X names each) or one will succeed (per the consensus requirements.) The software will indicate the results by checking the channel owner after registration for each server. So you know whether to try register a different name or not. So conflicts can still happen here but they're reduced by having unique TLDs + names, requiring small computations, and checking availability beforehand.
dangerface 3y ago
You claim here that there is a cost to creating the domain but rule out Ens because it has a cost? You can't make both claims. You can generate Ethereum and buy domains with it much in the same way you do here. You rule out DNS as it doesn't have a standard registration but IRC doesn't have a standard way to register channels nickserv isn't on all IRC and they have different implementations. IRC is not distributed it's owned by a centralised provider who has complete control, they can trivially take over any domain they want. IRC has no consensus mechanisms a netsplit would make it trivial to create duplicate channels on the same IRC network. You check channel availability then register, this by definition isn't atomic, it's a race condition between check and register. You need a way to wrap this in a transaction to prevent the race condition. IRC provides no way to do transactions. Even registering a channel on a network is not atomic because of the potential of netsplits, which is stated in the rfc. How are networks choosen and distributed? You picked 11 random servers that meet your requirements. If I pick 11 random servers how are their ips shared? Traditionally this is done with DNS but since you are trying to replace this requiring it is odd, how do you stop some one just hijacking your DNS once that problem is solved your scheme becomes pointless. If you expect everyone to use the same 11 servers this isn't distributed, it's centralised to 11 servers you can't trust. I think you are under the impression that IRC is distributed and so if you build a secure system on top of it, then the system as a whole will be secure and distributed. The problem is that IRC isn't secure or distributed it's centralised with no Byzantine fault tolerance. I understand you check multiple channels/networks in an attempt to provide this protection but the underlying servers can do anything they want and there is nothing you can do about that. Finally getting to the point of being on IRC and checking a channel has a lot of attack points none of which are accounted for. The difficult part of any distributed bysentain tolerant system is the distributed bysentain problem IRC doesn't solve this problem and your scheme outsources it to IRC. Charcircuit is just telling you the truth you don't want to accept.
- hanniabu 3y ago
  > You claim here that there is a cost to creating the domain but rule out Ens because it has a cost? You can't make both claims It's HN, they don't understand how blinded they are by their bias against blockchain. I see these contradictions all the time and have learned it's pointless to reply.

charcircuit 3y ago

>why do you say that? Because the information needed to lookup a name is equivalent to the information needed to register the name. >Registered names aren't visible, only their hashes. But domains are public information. Imagine if in normal DNS anyone could register google.com at any time. Claiming that its not insecure because people don't know google.com exists doesn't make sense. >names can be registered atomically across IRC servers without revealing what they are directly. But if someone learns the name they can register it themself. Two people can both claim to be google.com. If a new IRC server is added anyone can create a channel for an existing domain. If your answer to the problem of the same domain being registered by multiple people is that a domain should be both a name and an encrypted nonce you run into the problem where it might be more convienent to just pass over the public key. >But your usage of the term here is confusing That is my fault, I assumed this was a permissionless system where any IRC server was permitted to be used instead of a permissioned one. >Currently there are no such blockchains that have zero transaction fees to use them. Some cost near $0. A fork of one could be made to do so.

Uptrenda 3y ago
The channel names are unique per server. Knowing the channel name isn't enough to infer what name it represents so you can't just go and register the name on other servers after observing channel names. The only way to know what a channel name represents is to do a lengthy computation for a possible name, tld, password (optional), and server. Depending on uniqueness -- this might not be practical. The idea of having masked names was only to prevent race conditions in the initial registration process. After the channel names are registered they are unavailable for other attackers to register and since a verifiable delay has to be done on the name to compute it -- there is adequate time to register the name across multiple servers. A malicious server can reuse a channel name and have it hijacked by an operator. But the system also ties in ECDSA signatures with a basic threshold consensus algorithm across servers. So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
- charcircuit 3y ago
  >The channel names are unique per server. But there is not a limit for how many channels can exist for a single domain. >After the channel names are registered they are unavailable for other attackers to register Yes, but an attacker can use a different channel name for the same domain. >So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name. An attacker could associate their own key with that domain any number of times across any number of servers.
  - Uptrenda 3y ago
    I'm not sure I understand what you mean. One channel is registered per server, for one name. Successful registrations require a super majority of those registrations to succeed. Lookups can be limited to a sub-set as long as the result number is at least greater than the minimum failure threshold for a successful registration. >Yes, but an attacker can use a different channel name for the same domain. >An attacker could associate their own key with that domain any number of times How?
    - 3y ago

baobun 3y ago

OK, so, one thing isn't clear to me: 1. Alice registers example.tld 2. Bob registers example.tld 3. Bob reveals example.tld 4. Alice reveals example.tld It seems there is now two rooms corresponding to the same name. Who controls example.tld? I'm missing uniqueness and it still seems vaguely racey.

Uptrenda 3y ago
Both Alice and Bob check if a name is already registered beforehand. Lets say that both of them see that a name is available and go to register it at the same time. Either both will fail (due to taking X names each) or one will succeed (per the consensus requirements.) The software will indicate the results by checking the channel owner after registration for each server. So you know whether to try register a different name or not. So conflicts can still happen here but they're reduced by having unique TLDs + names, requiring small computations, and checking availability beforehand.

dangerface 3y ago

You claim here that there is a cost to creating the domain but rule out Ens because it has a cost? You can't make both claims. You can generate Ethereum and buy domains with it much in the same way you do here. You rule out DNS as it doesn't have a standard registration but IRC doesn't have a standard way to register channels nickserv isn't on all IRC and they have different implementations. IRC is not distributed it's owned by a centralised provider who has complete control, they can trivially take over any domain they want. IRC has no consensus mechanisms a netsplit would make it trivial to create duplicate channels on the same IRC network. You check channel availability then register, this by definition isn't atomic, it's a race condition between check and register. You need a way to wrap this in a transaction to prevent the race condition. IRC provides no way to do transactions. Even registering a channel on a network is not atomic because of the potential of netsplits, which is stated in the rfc. How are networks choosen and distributed? You picked 11 random servers that meet your requirements. If I pick 11 random servers how are their ips shared? Traditionally this is done with DNS but since you are trying to replace this requiring it is odd, how do you stop some one just hijacking your DNS once that problem is solved your scheme becomes pointless. If you expect everyone to use the same 11 servers this isn't distributed, it's centralised to 11 servers you can't trust. I think you are under the impression that IRC is distributed and so if you build a secure system on top of it, then the system as a whole will be secure and distributed. The problem is that IRC isn't secure or distributed it's centralised with no Byzantine fault tolerance. I understand you check multiple channels/networks in an attempt to provide this protection but the underlying servers can do anything they want and there is nothing you can do about that. Finally getting to the point of being on IRC and checking a channel has a lot of attack points none of which are accounted for. The difficult part of any distributed bysentain tolerant system is the distributed bysentain problem IRC doesn't solve this problem and your scheme outsources it to IRC. Charcircuit is just telling you the truth you don't want to accept.

hanniabu 3y ago
> You claim here that there is a cost to creating the domain but rule out Ens because it has a cost? You can't make both claims It's HN, they don't understand how blinded they are by their bias against blockchain. I see these contradictions all the time and have learned it's pointless to reply.