Bitcoin Forum
September 28, 2016, 11:55:43 PM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 »  All
  Print  
Author Topic: BitDNS and Generalizing Bitcoin  (Read 89209 times)
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
December 08, 2010, 05:45:40 AM
 #181


Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)

Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.

Ha.  Good point.  I was thinking the two could potentially operate under the same umbrella.  We'll see though.
1475106943
Hero Member
*
Offline Offline

Posts: 1475106943

View Profile Personal Message (Offline)

Ignore
1475106943
Reply with quote  #2

1475106943
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475106943
Hero Member
*
Offline Offline

Posts: 1475106943

View Profile Personal Message (Offline)

Ignore
1475106943
Reply with quote  #2

1475106943
Report to moderator
1475106943
Hero Member
*
Offline Offline

Posts: 1475106943

View Profile Personal Message (Offline)

Ignore
1475106943
Reply with quote  #2

1475106943
Report to moderator
Anonymous
Guest

December 08, 2010, 06:48:30 AM
 #182

Referencing this thread http://bitcointalk.org/index.php?topic=2129.msg27968#msg27968

I think Gavin is trying to tell us the way forward .




BitDns is not bitcoin.  Smiley

We already have a forked chain.... Get something working on the test network and prove your theories.

Lets get it started in  here..... Cheesy






Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 08, 2010, 07:08:55 AM
 #183


A few more questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.

Names can be changed when registered, but only from one TLD to another. You could change pics.sex to pics.p2p. I don't understand the motivation for this. It seems like something that would seldom be useful.

I'm still confused about fees. I was assuming that fees would be paid to the DNS servers, for the service of acting as a gateway from the Bitcoin block chain to the DNS system. I now see another interpretation, where DNS servers don't receive the fees, but they nevertheless demand that transaction fees of a certain minimum level be paid to miners. As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?

The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today. (I may be misunderstanding this!) Each of these DNS servers publishes a schedule of fees for performing this service. To register a new name... hmm, I am guessing now. Would you contract with one particular DNS server to do something else than host your regular DNS records?

I had thought it would be ok to expect DNS servers to follow the block chain and honor valid domain name transactions without requiring certain minimum fees. Domain names are so valuable (at least at first) that miners already have ample motivation to demand substantial (like $100 = 500 Bitcoins per transaction) fees. Eventually, if the system is successful, virtually all DNS servers would read the block chain.

Hal Finney
RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
December 08, 2010, 02:22:34 PM
 #184

I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.

That is the point.

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each "TLD" would have its own central server where you would have to "pay" to get onto that server?

What I don't see is the mechanism for how or even why a particular DNS server ought to even receive these fees as opposed to somebody else creating a "registrar server" and following this same protocol to put that data into Bitcions for considerably less or even "free".  This issue of where the money goes has been to me the issue all along, and the only place that could be identified easily as having done some sort of "proof of work" in terms of organizing the data is the block miner itself.... that is the Bitcoin block miner and not the DNS block miner as there is no sort of DNS block here at all.

I don't see any rationale for using a particular registrar other than merely because of sheer convenience and the hassle of setting up the software on your computer.

If there is some way that you might show some cryptographic "proof of work" in processing domain records, I might agree that a particular "registrar" deserves some separate fees in addition to the Bitcoin miner, but then the problem is how do you get those fees to that particular "DNS Block miner"?  Otherwise there isn't any sort of effort being put forth by the registrar at all where literally anybody could create some software to put these records into the system.

I could imagine a system where a sort of auction system on a particular domain happens where the person throwing the most number of bitcions in for a registration record "wins" the domain, but something seems a little off on that as well.  It also implies that anybody can "steal" your domain simply by throwing more coins at it than you have.  It is a great idea for miners, but lousy for those trying to register domains.

This is all about the money from my perspective, and this part has not been cleaned up for me upon reading the documentation.  The actual storage of the registration data itself has always been to me a trivial piece of the puzzle.  Throwing those records into Bitcoin transactions are useful as they do provide the time stamping and hashing ability of Bitcoin software, but any fees beyond Bitcoin transaction fees seem to be a pointless exercise without any sort of further proof-of-work.  Any additional fees being thrown with the "registration" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.  I could imagine some "greedy" DNS servers that might expect to be paid for bandwidth and being paid in Bitcoins or some other currency, or perhaps a very small fee for actually putting the transaction into the Bitcoin blocks for those who only have a "thin client" for Bitcoins, but those fees would be subject to a huge and highly competitive market where for most people it would be "free" anyway.

This is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 03:55:05 PM
 #185

I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.

The left-most part has to stay the same. "theymos.btc" can be changed to "theymos.bc". Everything but the left-most part is advisory: "theymos.btc" can actually appear as "theymos.btcdns". In particular, if someone registers a top-level domain such as "theymos.", most servers will probably map it to "theymos.btc" or something.

I really don't get this. What's the point of having a "right-hand-side" if it is advisory? The user doesn't want to have to type theymos.bc into their browser when they're at an internet cafe that uses one DNS, but have to type theymos.btcdns into their browser at home if their ISP uses a different DNS. And if they just type "theymos", what if they are on a LAN that has a node called theymos?

Any default right-hand-side should be explicit in the spec. Also, I don't think something hard-to-pronounce like ".btcdns" is going to work with the public. Can you imagine TV ads saying "go to walmart dot bee tee see dee en ess"?

In the initial phase at least, I suggest that all names registered should be of the form something.domain

I propose ".domain" for this purpose because it's generic and pronounceable. It also somewhat cheekily implies that this is the ultimate all-encompasing domain name registration system.

Three advantages:

  • This establishes clear branding.
  • It helps to keep the system simple, so that we can easily describe how to get up-and-running with these newfangled names.
  • It avoids any clashes with existing domain names.

If people prefer to go for something more ambitious, I suggest that all names registered should be of the form something.tld where .tld can be anything of three or more characters except for existing recognised top level domains. So you could register hamburger.red or silly.fool but not zebra.com
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 04:00:02 PM
 #186

Is there a way to reserve the top 1000 domains at Alexa ?

Please let's drop the idea of reserving the top names. Would you think it was fair if you owned the 1001st domain? It's only going to lead to disputes and hassles.

I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 04:02:27 PM
 #187


We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.
It could set some precedent for protocol change that allow people to shut down certain domains.

I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 04:16:39 PM
 #188

My concern is that there would be a rush to grab hot domains.

If desired, an initial rush could be spread out by a phased introduction.

For example, in the first week only names of ten characters or longer would be accepted for registration. The next week, names of nine characters or longer would be accepted. And so on, until by week ten any length will be accepted.

A more sophisticated phasing would hash the domain name to a number from 1 to 1000. On each of the first thousand days, names that hash to that day's number are added to those that can be registered. So, by day 42 it would be possible to register any domain name that hashed to a number in the range 1 to 42. After day 1000, any name could be registered.

A third possibility is simply to limit the number of registrations. Suppose each block limited the maximum number of domain name registrations to the current generation difficulty divided by 1024. For now, that would mean 8 domain name registrations per block, but the limit would rise over time (quite quickly, I think).

I'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so.
RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
December 08, 2010, 04:18:12 PM
 #189

I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.

Agreed.  I suggested in my previous domain allocation system that the standard ICANN/InterNIC domains and perhaps to be fair some of the domains currently being done with other networks like OpenNIC and the .onion "domain" of the Bittorrent network ought to be held in "reserve" as a part of the internal protocol we are setting up here.  My suggested domain allocation system would have that as an organic part of the system although it would be useful to hold these TLD in escrow for whenever or if ICANN wants to have control of them.

Since to use one of the TLDs with a server you would need to have it assigned to an IP address of some sort, somebody like Google could go aver "google.btc" as a trademark violation by searching for the network which assigned the IP address of the server using that name.  If the domain record points to 127.0.0.1, it really isn't a threat to Google until that address changes anyway.  I agree that this is beyond the scope of this protocol to take care of the Alexa top 1000 names and the only real issue is spoofing existing domain names being used by other DNS registries.

As a side note, during the actual reference implementation of one of these servers it would be nice to throw a bone to OpenNIC and the "dot P2P" guys (presuming they set up their own system) to forward DNS requests that might fall under those respective domain registries.  This is sort of a tip of the hat to say thanks for making sure ICANN doesn't have 100% exclusive control over domain registrations and to support what I think are good projects in their own right even if they aren't a P2P distributed naming system.  That might even get a reciprocal agreement with those alternate domain registries to spread these registrations with the DomainChain registries much further at least initially.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
December 08, 2010, 04:27:27 PM
 #190

It could set some precedent for protocol change that allow people to shut down certain domains.

I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.

Who would be given the "authority" to remove domain names?  That implies central authority of some sort that has control over this network.

Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to "delist" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your hands up and say "I can't change that, sorry".

The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:24:09 PM
 #191


Who would be given the "authority" to remove domain names?  That implies central authority of some sort that has control over this network.

Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to "delist" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your handseddrli up and say "I can't change that, sorry".

The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.

You have forgotten the rule that I asserted earlier in the thread:

Quote
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
December 08, 2010, 05:43:54 PM
 #192

Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to "somebody" to take care of that issue.  You could have a "voting" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore "by consensus" drop the domain.  It would also provide an unneeded attack vector on the network as well as the "votes" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.

I just don't know of an effective way to kill a domain record shy of simply letting it expire.  As long as the registration is following the rules of the network (however we set that up), I don't see how it could possibly be removed.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:44:54 PM
 #193


Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to "somebody" to take care of that issue.  You could have a "voting" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore "by consensus" drop the domain.  It would also provide an unneeded attack vector on the network as well as the "votes" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.

You misunderstood me. I didn't suggest anything like voting or whatever.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 05:49:22 PM
 #194

The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.

My design stores the domain name plus a couple of nameserver IP addresses (say, 50 bytes) for an everlasting registration.

The theymos/nanotube design needs much more data: the initial registration, the regular renewals, and the possibility to include actual DNS records themselves up to 520 bytes. There's talk of the renewals being required perhaps as frequently as every 2000 blocks, and certainly no more than every 52000 blocks.

Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.

I'm starting to think that an everlasting registration really is the way to go. In the DomainChain design, the registration would not be affected by block chain compaction, since compaction only affects spent transactions. If you transfer a DomainChain registration, or modify its name servers, all of the necessary information is contained in the latest transaction, which will remain unspent until the registration is deliberately modified. However, the theymos/nanotube design requires a sequence of transactions (registration, extra fee, DNS record, ...) where only the last transaction in the sequence remains unspent.

I think users will be uneasy about having to renew every 2000 or even 52000 blocks. Having to remember to renew, in order to avoid losing your registration, is bad enough. But block generation rates are variable, so that you won't even know for sure when your renewal falls due. Unpredictable renewals are not something that would make me feel good about using such a system for my domain name registrations. I can see many accidental domain name losses occurring under this system.

Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
December 08, 2010, 05:54:03 PM
 #195


Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.

Time based expiry date rather than block based expiration system. Obviously registrar could remain users to renew as they had done in the earlier system.

RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
December 08, 2010, 06:53:43 PM
 #196

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.

Re-reading this, I think I "get" how this is going to work for registrars, at least how Theymos is proposing here.

Each "Domain server" would separately and independently charge a fee for "registering" the domain on that particular server, where essentially everybody would be paid simultaneously when a new domain would be registered.

Something here just doesn't sound right, which is why I keep bringing this up.  I don't see the mechanism for recognizing new domain servers or what criteria ought to be used so far as to whom these fees are going to be allocated.  A domain server which is regularly being used by just a couple computers in a small office would in this case be a "peer" to a domain server at a major university servicing perhaps thousands of computers for domains.  Yet in this case both would be receiving registration fees and from a network perspective would be indistinguishable.  However getting "your domain" recognized by that major university server would be much more "valuable" than the server in a small office.  Any attempt to report usage could easily be manipulated in a number of ways making it to me impossible to realistically distinguish between the two servers, at least algorithmically.

Maybe I'm missing something fundamental here.  I sure hope so.  It seems sort of silly for somebody to set up a "domain name server" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used.  That sounds like a neat gig to get into, but I don't understand what "service" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered "equal" and receive roughly the same amount of money?

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 07:52:14 PM
 #197

I think we should dispense with the complexity associated with paying various servers. We should also dispense with the concept of paying more if we want better visibility for our domain names.

No-one wants a system where some people can reach some.domain and some people can't, depending on which servers are getting their share of the payment. Or a system where a new server can come to prominence and put pressure on people to pay again for the domains they already paid for.

Let's cut it down to the simplest business model that can work.

Suppose there are some generators who will include domain name registrations into blocks that they generate, because they want to earn the transaction fees. Those generators will operate public-facing domain name servers.

Why? They need to do this, to make the domain name service credible so that people will use DomainChain for their domain registrations. For the generators, it's an overhead, but a necessary one. Kind of like how most restaurants provide toilets without charging separately for them.

You could argue that there will also be some operators who would generate, and who would collect the transaction fees for domain name registrations, but who would not operate a server. After all, why incur the overhead if the other generators will operate the servers?

But the market will take care of this. The generators who do operate servers are not going to accept the blocks generated by those who sell domain names without providing domain name servers.

Additionally, a market like this is likely to have two other kinds of players.

There will be a few organizations who are willing to operate a server for free, perhaps for ideological reasons. Those servers will probably be overloaded and slow (like the free Usenet servers), but they act as a backstop which forces the commercial operators to provide something better.

There will also be a few commercial operators who provide enhanced super-fast servers without being generators. They will do this either because they have paying customers who want the best domain name service that is possible, or they will do it for their own business reasons (as Google does with their free-to-access domain name servers).

Here are the advantages of this simpler system:

  • For the domain name owner, the registration is convenient, secure, and lasts forever,
  • For the internet user, the same set of domains is served to everyone,
  • For the generators, it's a worthwhile extra source of income, and
  • For the Bitcoin system, it's an easy way to get extra strength into the block chain with minimal extra data
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 07:57:04 PM
 #198

Time based expiry date rather than block based expiration system.
Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.

Of course, there is nothing that forces the providers of domain name servers to compact their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains.
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314



View Profile
December 08, 2010, 08:10:14 PM
 #199

I agree with ribuck that DNS servers don't necessarily need to get paid, to support Bitcoin domains. After all, what is the purpose of a DNS server? It is to lookup domains for its clients, which are users wanting to connect to computers using domain names. If BitDNS becomes popular, DNS servers will want to be able to lookup those domains too. All that is necessary is to track the block chain and maintain indexes and hash tables to record which domains are in effect and their basic DNS data. DNS servers don't have to be Bitcoin miners. The existing motivations for DNS servers to operate and provide lookup serves to their clients will be sufficient to make them track Bitcoin domains.

Hal Finney
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 08, 2010, 10:48:14 PM
 #200

DomainChain wiki is here:
http://domainchain.org/wiki/doku.php?id=start

There's not much there, but I will work on it tomorrow.

Meanwhile, some interesting further ideas on integrating with the Bitcoin block chain have been added to the Theymos/Nanotube wiki.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!