Transitioning the web to Namecoin by addressing squatters

[virtual_master]

I think it's unwise to modify the protocol for different characteristics in specific namespaces (d/ in this case). If there's a solution it should apply to names in general over every namespace.

In this case may be a simpler name length based fee system would be proper(it is also easier to implement it) where shorter name registration/renewal will cost more.

[indolering]

I think it's unwise to modify the protocol for different characteristics in specific namespaces (d/ in this case). If there's a solution it should apply to names in general over every namespace.

Each namespace has special needs, arbitrarily handicapping solutions in any one namespace because they are not universal is ... like forcing everyone to use XML based on principal.

[sugarpuff]

You just criticized every proposal without presenting any alternative.

I offered a proposal, it's there in the first post to this thread. When others presented alternatives, I asked questions, and if I criticized them, I explained my reasons for doing so. I'm not sure I understand what you are upset about.

[khal]

Here is half a proposal to solve the "namecoin depends on external data" :

Example :
name: com/google/<random1>
name: com/google/<random2>

- Several google.com can be registered
- You can put data in namecoin related to ICANN data, with signature, anything you want, they don't prevent registration
- Use nmcontrol to choose the right domain
- You can combine several things, to make the choice of what is the "good" domain :
* signed data from the ICANN : prevents squatting on registration
* web of trust : can override domain seizure, you can vote in another namespace :
name: "vote/google/<random1>/<randomA>
value: { id: khal, sign: xxxyyy }
* etc, everything is possible, and more easily updatable than the namecoin protocol

[sugarpuff]

Here is half a proposal to solve the "namecoin depends on external data" :

Exemple :
name: com/google/<random1>
name: com/google/<random2>

- Several google.com can be registered
- You can put data in namecoin related to ICANN data, with signature, anything you want, they don't prevent registration
- Use nmcontrol to choose the right domain
- You can combine several things, to make the choice of what is the "good" domain :
* signed data from the ICANN : prevents squatting on registration
* web of trust : can override domain seizure, you can vote in another namespace :
name: "vote/google/<random1>/<randomA>
value: { id: khal, sign: xxxyyy }
* etc, everything is possible, and more easily updatable than the namecoin protocol

Not fully understanding this.

Who is using "nmcontrol to choose the right domain"? Google? You?

How do you know which Google is the right one, and why are you deciding this?

What specific issue does this proposal solve and how?

[indolering]

I'm with Khal on this, I think using data external to the blockchain based off of network voting is fine. If enough clients can see the same DNS txt entry, that would be enough.

[khal]

What specific issue does this proposal solve and how?

=> Transitioning the web to Namecoin by addressing squatter.

Who is using "nmcontrol to choose the right domain"? Google? You?

Each namespace has its own rules, not defined in the blockchain, but by the spec.
The d/ namespace will ignore names not translated to ascii (IDNA). This rule is followed by each software implementing a DNS resolver from namecoin : nmcontrol & namecoinToBind for instance.

How do you know which Google is the right one, and why are you deciding this?

In the case the name is not seized, it's more simple, and google can :
- create the name "com/google/abcd" and put a field containing the namecoin address that will be used to sign some data
- put a namecoin name in their google.com DNS records (in TXT for ex)
- sign some data (the namecoin name + other ?) from google.com with the previous namecoin address and put the signature in a TXT record

What has been done is to link a specific namecoin name with the google.com domain by signing google.com records with a namecoin address.
The resolvers will check the sign and can decide that the name "com/google/abcd" is validated and will be used to resolve google.com instead of all other "com/google/*".


Now, the more complex part is to fight domain seizure.

If the seized domain do not put a namecoin name & a signature in the google.com, the resolver will not be capable to validate the namecoin name "com/google/abcd" anymore. In that case, the resolver may consider that the last validated name is still valid until a new name is validated.


If the seized domain DO put a new namecoin name ("com/google/seized") & a signature in the google.com (few probability, but feasible), a new name will be validated (and we don't want that in case of seizure, but we want it for a normal transfered domain), so, we must provide some way to counter that.
The first way I thought about was with a voting system in namecoin.
How it works needs also to be defined, but here is some raw idea :
- The resolver will search for names starting with "vote/com/google/*/<random>" and select the one with the most votes/NMC sent/etc (raw idea, easily cheated, but you see the point ?)
- The owner of the previous name update its name and add a field "seized" (but that would block the normal transfer of google.com to another user and another namecoin name if a malicious guy put "seized" in his namecoin record after selling the .com)

There may be some other ways to do it too, try finding the best one :p