BitDNS and Generalizing Bitcoin

[nanotube]

Do we have a consensus on nanotube's proposal? Any objection?

just to be clear, it's nanotube's+theymos's proposal

and, we're still working out some kinks in the protocol. consider this to be an open RFC period. it's a bit too early for 'consensus'.

[1714125778]

1714125778

[1714125778]

1714125778

[1714125778]

1714125778

[em3rgentOrdr]

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.

If they receive coins that are associated with a domain name registration they will see them as coins.

You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.

I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.  I like the idea of piggybacking bitDNS on top of bitcoin.  However, putting the domain name registration requests inside of bitcoin transactions as a message does cause concern about compatibility, should the bitcoin developers decide to remove that feature in the future for security or other reasons.  I would suggest, maybe is it possible to have the domain name registration request message be not included directly inside the bitcoin transaction, and instead use some cryptogrphic properties of the block be used to index to a bitcoin registration request message?  For example, somehow have the hash of the transaction/block be directly indexable to a DNS registration request?  In which case, the information about the sender and receiver of the DNS registration request would be embedded in the hash such that it proves that address X is the owner of that DNS registration request?  Thus the bandwidth/traffic of domain name table info/requests would only be paid by those clients who are engaged in domain name registration.

Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.

Expiration fixes the "problem" of domain names being lost for eternity.  My question is, what are the relative benifits/disadvantages of using a block count based expiration (e.g. 52,000 blocks) versus a time-based expiration (e.g. 1 year)?  I would think a time-based expiration would make more sense for average people to understand, since they will know that after a certain fixed period of time, they will need to renew their domain, and can set that in their calendar, instead of being completely unaware if the block count reaches some number?  Never mind...I get it...52,000 blocks is approximately the number of blocks that should be produced in 1-year time assuming a rate of 1 block/10 minutes is maintained.

My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.

Speculation is natural; even healthy.

What Kiba said.  Speculation is a part of any world where there are limited resources.  Speculation allows the market to come to a subjective valuation of the unknown value of such resources.  The speculator takes a risk by buying domains (even if it is just an opportunity cost), and that risk is entirely held by the speculator.

[kiba]

I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.

Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.

[em3rgentOrdr]

I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.

Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.

Oh yes, I am perfectly aware.  In fact, the prevalence of simultaneous inventions is a strong argument against the necessity of a patent system to "reward" inventors with monopoly.

[RHorning]

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.

I'm looking at the fees, which certainly would be a reason for a miner to include these into a block with a high priority.  Still, I'm trying to find any sort of motivation for a "DNS Server" to recognize any of this data other than as a repository of potential domain information.  There is a reference to a "vibrant market" for the fees being used here, yet this seems very altruistic that one of these servers would recognize any fee at all if they aren't getting any themselves.  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.

I suppose that this is in effect a way to ensure that the Bitcoin network stays strong, as it certainly is going to be making any sort of mining activity much more profitable by doing this.

What pricing strategies that would be used by a domain server which would have an adjustable price in the interface or config file and why one server would set the "price" at 10 BTC or another at 15 BTC or still another at 5 BTC?  Is this basically "filtering out spamsites" or is there something more serious going on here?  Is this simply an "open bid" for each domain where the most money invested "wins" the domain?

Toward the end of the document there is a reference after a fashion about some more complex fee allocation system that passes around addresses which get deposited into some servers after a fashion.  I guess this is where I'm totally missing the point here perhaps or not understanding what is going on at all with these fees as there is something more implied by this document not written down.

[Hal]

What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

I have a couple questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

When you register a name, there is a fee to a DNS server. In the doc, this appears like a Bitcoin transaction fee. The first example shows 10.01 input and 0.01 output, so the 10.00 difference would be a transaction fee. But tx fees go to miners. Is it assumed that miners are the same as DNS servers? Or would there be a 2nd output, a fee to a particular DNS server to get it to register you, in addition to a tx fee to the miner?

Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

Thanks -

[Anonymous]

This is exciting stuff. The benefits of having an intrinsic value to bitcoin is inestimable and kills a lot of arguments against it. I would like to hear satoshi's thoughts on this as forking the network is not a decision taken lightly.

Is there a way to reserve the top 1000 domains at Alexa ?  I can see massive issues down the road if say google has their name squatted on. Doing this would bring a lot of goodwill towards bitcoin rather than having all the top companies against it. One way this could be done is for the dev team or a council of bitcoin elders  register all of these names before the client is publicly released and hold them in trust. When a top 1000 company wishes to claim their name the profits could go to benefit bitcoin. Is that a good plan?

[da2ce7]

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

This is a very good and important idea, we should set-up some 'domain trust' where well established domains will be protected until they are claimed (at a good fee) by a verified owner.

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

[kiba]

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

No, no, no. The DNS system should be kept as simple as possible.

There will be no silly voting, or court, or any complicating shit.

[Anonymous]

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

No, no, no. The DNS system should be kept as simple as possible.

There will be no silly voting, or court, or any complicating shit.

I think the delay in releasing the client would be enough for the top 1000 to be locked in
 

[theymos]

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.

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.

Is this basically "filtering out spamsites"

Exactly.

What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

Bitcoin already supports it technically, though recently a change was made that causes non-standard transactions such as the ones used by BitDNS to be skipped in blocks created by the official Bitcoin client. However, BitDNS transactions produce quite a lot of fees for generators, so if an implementation is created, I expect it will be easy to get a reasonable percentage of miners to ignore this new rule (only like 5% is really necessary).

Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

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.

Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

Anyone can run them. I think the expiry time should be lowered to like 5,000, though, to make it easier to run a server.

[chaord]

I think reserving the top 1000 alexa domains by seeding the genesis block with those "registrations" would be an excellent show of good faith towards the world at large.  A council of bitcoin "elders" could be elected to hold the private keys to those initial 1000 domains, and turn them over when the time comes (for a fee, which will go towards bitcoin/domainchain community funds). 

[da2ce7]

So in theory this is the perfect system for claiming a 'named address'.  If I wanted to send a payment to 'theymos.btcdns' I could. Or is my understanding wrong?

[da2ce7]

re-read nanotube's+theymos's proposal! Sound Good 
+1

[chaord]

This is all very fascinating stuff.  I read themos+nanotube's proposal, ribuck's proposal, and rhorning's.  While I think I grasp the fundamental differences between them, I am not confident to weigh in.  Could I ask that someone more knowledgeable than I am on these matters create a table (wiki?) that lists the proposals as they currently are?

I'm personally very intrigued by the idea of piggy backing on the existing bitcoin network, if it can be done cleanly and with minimal modification to bitcoin (as per nanotube/themos suggested).

As Kiba pointed out, I am most excited for bitcoin to have it's intrinsic "use-value!"  And it couldn't come at a more needed time what with wikileaks, pirate bay, etc all over the news.

Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a "DomainShadow" system that is only used in the event of crisis (like wikileaks attack, etc)?

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?)

[kiba]

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.

[theymos]

Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a "DomainShadow" system that is only used in the event of crisis (like wikileaks attack, etc)?

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

[nanotube]

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

just to throw in a little bit of optimism here , if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption.

[Anonymous]

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

just to throw in a little bit of optimism here , if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption.

We need a proof of concept. 

[kiba]

Yes, coding need to be done soon.


Repeating ad nauseum:

Speed is of the essence.