Topic: BitDNS and Generalizing Bitcoin - page 6. (Read 122681 times)

Will it be open source or proprietary?

More than 40% of the network would have to cooperate to get free domains. If malicious people are getting that much CPU, we have bigger problems. Even if this happens, servers can raise the limit to 7/10 or whatever.

Smaller percentages will get you a "discount", but I don't consider that to be a big deal. In particular, it'll be pretty easy to get a 1/5^th discount if you can ever expect to create a block.

It's not a problem if people buy up names and then sell them on the market. This is an appropriate way to distribute unique resources. It's like homesteading some land in order to sell it later at a profit. We just want to prevent people from claiming millions of domains for free and then not using/selling them.

As for front-running: the first registrant will have an advantage in the race to get 4 adjusts. The first person has to send 4 more messages, while the attacker has to send 5. This can't really be done automatically, either, as people would attack the automated system by registering useless, random domains.

Front-running by miners is a flaw of the current proposals, and it's where I'm stuck. I haven't moved my DomainChain proposal further forward in the past couple of days because I can't solve the front-running problem.

The essential flaw is that domain registrations are contingent on transaction fees. A miner who generates a block can include a large number of speculative high-value registrations in that block, because the transaction fees don't cost them anything. This might be an intractable problem for any domain name registration system that is based around transaction fees.

I see that theymos/nanotube are proposing a "solution" to this. Their idea is that it should take more than one transaction to register a domain name; five transactions in fact. The first transaction pays one-fifth of the fee. Then, for the registration to be valid, there must be four further "fee adjust" transactions, each for one-fifth of the fee. These transactions must take place within ten blocks of the first transaction, to be valid.

My first objection to this is that it doesn't solve the problem of miner front-running; it just makes it more difficult. A few of the largest miners will just make an arrangement to mutually-process each other's fee adjust transactions. Almost inevitably, the design will produce a small group of large registrar-like operators.

My second objection is simply that 5-transaction registrations add an enormous amount of clutter to what should be a simple and elegant process.

Probably the 8 places of granularity that bitcoin already supports would be sufficient. That is 0.00000001. The set of all strings is infinite but it can be mapped onto all the bitcoins by using a hash function.

How big is the entire set of all strings? And what level of granularity do you need for a bitcoin (10, 1, 0.1, 0.0000001, etc.) so it can hold the entire set of strings?

I want to elaborate on a system I alluded to in an earlier post on page 14, that seems to be simpler than most of the other proposals put forth but that no one posted any feedback on.

Under this system, there are no changes to the protocol, except for the work sharing mechanism Satoshi briefly described (that no one else seems to understand completely) whereby clients can do work on multiple networks without choosing one over the other.

To implement this system:
1. Fork the network
2. Map the entire set of all strings (DNS names) onto the coinbase using a hash function (SHA).

Now, the rights to map any given DNS name to an IP address is awarded to whomever owns the coin associated with its hash on the forked network. Note that #2 is possible because every bitcoin is already both distinguishable and traceable in the current system.

This eliminates the need for any new complicated transactions, and eliminates the possibility of introducing any new loopholes or exploits that are not already present in the current bitcoin system. To transfer ownership of a DNS name, simply send the coin associated with its hash, on the forked network.

I also think this can be generalized to all classes of problems where a finite (or infinite) set of items needs to be assigned to people. In other words it should be possible to arbitrarily create forked coinbases for tracking the ownership of different sorts of things.

Any ideas or criticisms for this?

So if I understand this correctly, all sorts of random domain names will be randomly generated such as "q8d79rt0y.bitdns", "sfdn345sdf.bitdns", and "goodurl.bitdns"?

I can see this type of scenario unfold as one possibility... BitDNS starts cranking along producing mostly "ugly" URLs. Somebody like Google wants to adapt to the bitDNS system, but doesn't want to wait for "google.bitdns" to be generated (or it can be generated by brute force, in which case Microsoft adapted to bitDNS before Google and brute-forced "google.bitdns" in order to hold it for ransom?). So, they buy "sfdn345sdf.bitdns" (or just use whatever they generate themselves) and create a plugin for their Chrome browser which translates "google.com" to "sfdn345sdf.bitdns". Naturally, other companies would opt for the "ugly" URL instead of waiting for a "pretty" one, and then try to get their translations into the browser DNS plugin. I also think there would be competition between plugin translation "packages". For example, I prefer "en-us" locale sites so I want "google.com" to go to the US English version ("sfdn345sdf.bitdns"), but someone in Austria would want their "google.com" to point to the site in German ("q8d79rt0y.bitdns"). I think a browser plugin could hold all the locations a person would ever want to visit since most people stick to their own little corner of the internet. If I was a Google, I would show a little button on the homepage of "google.com" that encourages the user to load the bitDNS version of the page, which the plugin basically links "google.com" to "sfdn345sdf.bitdns". From there forward, the browser automatically translates "google.com" to "sfdn345sdf.bitdns" and visits "sfdn345sdf.bitdns" whenever the user types in "google.com".

It's another layer of abstraction, but it might smooth the transition to the BitDNS system.

I think we're on the same page here.  I didn't make it very clear, but my whole "At the end of the day you have to trust ICANN" line was part of the problem statement, so to speak.  I didn't mean to indicate that was something that is just a given, but rather the principle problem that I'm hoping this can work around.


In principle, I absolutely agree.  But the reality of the situation is that people are used to the current system, so eliminating TLDs just increases the barrier to entry.  At this point, most web users have a mental model of how web addresses are formed that pretty much assumes a hierarchical system.  We ignore that at our peril.

Furthermore, allowing arbitrary TLDs effectively guarantees that someone is going to register some of the existing domains.  This is a huge problem in how I envision a system like this being used.  Since I doubt most people are going to just cut themselves off from the existing Internet to live in our corner of the network, the best we could hope for right now is a system where you get DNS names from a DNS server supporting BitDNS, and if it can't find it, it falls back to the existing DNS system.  That works great until you have a conflict, at which point you may end up with a different server then intended.  The beauty of using a new TLD, and forcing everything to fall under that, is that you are implicitly declaring your intention to go to a BitDNS name.  There is no surprise that you went to a server specified in the BitDNS network, since it isn't even valid in the existing system.  And vice-versa for standard names.

When we look at the design of the system, we should definitely allow for the possibility of arbitrary TLDs, since that is clearly a desirable feature in the long-run.  But for now, it makes sense to me to limit TLDs so that this new system could be integrated into existing usage models as seamlessly as possible.

On the positive side, if somebody wants to become their own domain regsitrar, they can certainly get that done too.  On top of that, the financial incentive offered by a fee to register the domain might be sufficient to prevent domain stealing from happening as they will want to include a domain to collect the fee.  I was hoping that somebody processing registrations would be greedy and selfish.
 
Since a registration is open to everybody and any block at any time could include the registration, somebody trying to capture a domain in this way wouldn't have much time to decide if they wanted the domain for themselves as well, presuming they were running a "corrupt miner".

More importantly, I would think this would have to be automated in some fashion, so how could you algorithmically decide what is a "good" domain name to capture?

I wonder if it would work to put a (possibly salted?) hash of the name into the block rather than the name itself? Then it would not be obvious what name is being registered, but you could still lookup registrations by name. This would not be perfectly secure, short names could be found from hashes by brute force, but it would make front-running much harder.

This is a very good point. Any domain registration message to the network could potentially be hijacked. It doesn't matter what the system is, if you're loosely connected and you send a registration message into the network, a well connected client on the network could simply resend the message using the same domain and possibly get to a larger proportion of the network faster than the original sender's registration message, causing his registration to be more likely to be included in the block chain. I'm not sure what the solution to that is. Of course the person who does this will have to spend whatever it costs to register a domain to do this attack, which will have a natural limiting effect on it, which may be the best we can hope for.

Can anyone think of a solution? Perhaps having to mine a hash for the domain registration message with much less difficulty than mining for domaincoins/whatever, but just to slow anyone down from being able to instantly register a domain as their own.

I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.

Nanotube and I will be developing an implementation to go along with our proposal. If you like your idea, create it and let the market decide.

If it were truly democratic, there would be a choice of, "don't do anything like this at all" and would require a quorum of 50% or more of bitcoin users.

Maybe we should start a poll about what we think is best and accept the result as a democratic decision.

For me it looks like this was the best:

[ ] Bitcoin main chain
[X] start a new chain, with DCCs ("DomainChain coins").

[ ] Permanent name registration
[X] renewal necessary
(registration for 1 year ?)

[ ] Support for an unlimited family of applications
[X] just focus on DNS.

[ ] DNS "gateway" servers setting minimum transaction fees
[X] burning a DCC to register a domain.
(not sure if I got all the details about this)

[ ] Include in the block chain, in addition to domain name: just ownership public key,
[ ] ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.
(actually I don't care about this)

[ ] Single TLD .web or .p2p, etc.
[ ] "advisory" TLDs which may be ignored
[X] all TLDs being allowed in names.
(up to 4 or 5 Unicode letters)

Seems like everyone's tugging in a different direction. Here are some of the specific issues:

1. Bitcoin main chain vs start a new chain, with DCCs ("DomainChain coins").

2. Permanent name registration vs renewal necessary.

3. Support for an unlimited family of applications vs just focus on DNS.

4. DNS "gateway" servers setting minimum transaction fees vs burning a DCC to register a domain.

5. Include in the block chain, in addition to domain name: just ownership public key, vs ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.

6. Single TLD .web or .p2p, etc., vs "advisory" TLDs which may be ignored, versus all TLDs being allowed in names.

Any other issues/design choices which can be factored out?

There are some very different philosophies here, so I think we may have a couple of different applications being developed, perhaps jointly.  I'm certainly not going to be implementing the Theymos/Nanotube proposal at least initially, but somebody else might.

Do we have enough uncontroversial detail that somebody can start coding?

no.

I guess he is hinting at the very chaotic planning of .p2p which makes the developement really slow because they can't really start before the specifications are clear.
Ignore that post. I was looking on the wrong page.