BitDNS and Generalizing Bitcoin

[theymos]

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.

[1713880194]

1713880194

[Hal]

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.

[bencoder]

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.

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.

[Hal]

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.

[RHorning]

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.

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.

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?

[dtvan]

There is no need to trust ICANN, except for perhaps acknowledging that there are other systems for domain allocation that aren't going to go away and that other people will be interested in using.  I don't see any sort of DNS replacement system suggesting that the ICANN domains should be ignored, merely that they ought to be depreciated with new systems.  The history of ICANN is one of a small group of self-appointed individuals trying to gain control over the resources of the internet for their own personal financial gain.  It also concentrates this authority in such a way that allows governments to exert political influence upon the allocation of domain names for political purposes that have nothing to do with the technical operations of the internet.  One of the points of setting up a peer-to-peer domain allocation system is precisely to get away from this central authority.

There is a sort of libertarian/anarchist bent to the whole notion of creating an alternate DNS system, which is one of the motivations for why this is being set up in the way being described.  Otherwise, I guess you can accept the system as promoted by ICANN.

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.

I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

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.

[abstraction]

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.

[joe]

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?

[abstraction]

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.

Any ideas or criticisms for this?

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?

[joe]

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?

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.

[ribuck]

I thought of a possible problem with all these proposals: front-running by miners.

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.

[theymos]

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.

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.

[ribuck]

Nanotube and I will be developing an implementation to go along with our proposal.

Will it be open source or proprietary?

[theymos]

Will it be open source or proprietary?

Open.

[da2ce7]

There is a very elegant way of solving the front-running problem, but you need to think a little bit creativity 

BitDNS should be subscriptions, as you always pay the generators as long as it is active.

When one registers a domain, the registration contains the rate that should be paid, (an on-going transaction fee) and the total amount.  When the transaction is included in the block chain.  The transaction fee is removed from circulation, and added to every generator at the agreed rate until it runs out.  When it runs out, the registration expires as well as the domain.

For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC.  For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.

[ribuck]

Subscriptions solve the front-running problem, but how exactly would they work?

For example one registers a domain at the rate of 0.01 BTC per block and pays 100BTC.  For the next 10000 blocks every generated block earns an extra 0.01 in transaction fees.

So who is the initial 100 BTC paid to? And how do the extra 0.01 in transaction fees get to the next 10,000 miners? Not by means of 10,000 transactions presumably...

[da2ce7]

the 100BTC are 'Killed" as in they are transfered to a "dead bitcoins" key.  Then the generators can get to claim an extra 0.01 or whatever on the mined bitcoins.  If the generator doesn't claim them, they sit around and accumulate until generator dose.  What is happening is that we are removing coins from circulation and allowing people to generate them again.

The only rule is that the coins cannot be 'claimed' faster than the set amount per block.  If a generator doesn't claim the coins in one block. The next block can claim two lots of it.

[ByteCoin]

I thought of a possible problem with all these proposals: front-running by miners.

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 solution to the front running problem has been solved by Hal in http://bitcointalk.org/index.php?topic=1790.msg29919#msg29919
A suitably salted hash of the required name is submitted for inclusion into the chain. After it has been confirmed then the name (and salt) are published and everyone now accepts the new registration.

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 agree that the theymos/nanotube "solution" to this problem is ugly.
There are also serious problems outlined by RHorning which need addressing.

ByteCoin

[da2ce7]

There are also serious problems outlined by RHorning which need addressing.

The problem with this is that the generators themselves can put hundreds of domain names into their own block.  Just like generators can include transactions for free in their own block.

[da2ce7]

I have come up with a solution to most of RHorning issues. However I'm still in the process of writing out it more formally.  It is quite a big departure from anything that has been talked on the forum yet.  But still (mostly) compatible with the bitcoin architecture.