BitDNS and Generalizing Bitcoin

[RHorning]

I completely agree here.  Even though his "blessing" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.

We need to get Satoshi's approval if something goes into the main Bitcoin client.  There are other applications involved here besides the DNS system, even if that seems to have high priority at the moment.  We could create a patch that would put hooks into the Bitcoin software to permit these kind of changes, but it could also be for naught if Satoshi rejects that patch.  Since this is also a major architectural change to the software, it seems highly unlikely that it would get accepted unless we can demonstrate a clear need for this idea or show some huge benefits that would help Bitcoin be adopted as a currency.  It is also a whole bunch of software development that depends on just one person accepting that change on essentially a whim.

In short, if we decide to put this into Bitcoin, Satoshi is the gatekeeper.  We could completely fork Bitcoin, which is essentially what we are proposing here anyway as the alternative with these separate coins.  That is our choice.

[kiba]

We need a wiki real bad so Rhorning can write down what he means.

RRRRRRRRRRRRRibuck?

[Anonymous]

Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?

After all who wants to download a massive block chain just to buy or transfer a domain name?

Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?

It seems this could be a way for bitcoin to have its own "app" store of different block chain purposes. 

[RHorning]

Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?

After all who wants to download a massive block chain just to buy or transfer a domain name?

Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?

It seems this could be a way for bitcoin to have its own "app" store of different block chain purposes. 

An interesting thread related to this can be found here: http://bitcointalk.org/index.php?topic=2124.0

Theymos has been discussing how to put miscellaneous data into the transaction blocks themselves, but there are dangers to doing that.  It also shows some incredibly strong resistance to "tweaking" Bitcion itself as a software package to permitting this kind of activity, which seems to me as coming from at least a source that would end up killing any attempt to put a patch into Bitcoin to permit data inclusion for something other than the "stealth" method with transactions.

While the suggestion that Git itself ought to be sufficient for cryptographic timestamping and cryptographic data storage (that is interesting by itself... something I haven't thought about), I don't know enough about Git to say much about it at all in terms of its distributed nature.

I firmly believe you should "pay your own freight" so far as anything which costs others to do, which is why I think this proposal is incredibly useful.  There are costs associated with domain name registration and data storage, and they aren't trivial expenses either.  The concept of Bitcions enables those costs to be borne by those who use the service.  I tried to explore this idea further on this thread:  http://bitcointalk.org/index.php?topic=1764.0

This is indeed a political idea here too, which is where perhaps it is getting some resistance as well.  The idea could be summed up with the concept that "you get what you pay for".  Places like Source Forge offer their "services" for free, but there are hidden costs including being tied to other outside interests.... mainly the advertisers and those who are paying for the "service".  With what we are proposing for BitDNS/Domain Chain is that the service is going to be focused upon those who are paying for the service.... which is those who are making the registrations.  They have the most to lose if this project falls apart.  If the registrants aren't happy with the service, fees are going to go down and the DCC is going to collapse as a currency.  That in turn is going to cause developers to be very strongly focused upon meeting the needs of that community.

The other aspect which is really interesting here is that the process of becoming a "registrar" has a very low barrier to entry.  I'm sure many people would love to have had the chance to do something like being BigDaddy or Verisign in terms of processing domain registrations and receiving the fees for doing that.  Now the chance to perform that sort of "business" at least on a part time basis is at least possible.  No single person or even central organization is going to be receiving the fees but rather a "community" that is open to newcomers and even people with modest technical skills.

I've also seen complaints that "open source software" doesn't pay.  Bitcoin can change that model, including doing things like we are talking about here with the DomainCoin system.  Not only can a bounty system be set up for integrating a specific feature into the system, but the developer can also have a continuing source of income afterward.  BTW, in deference to Kiba, the license itself is immaterial here too and can simply be thrown into the public domain, even though I think that copyleft licenses tend to offer much stronger protections against idiots who would attempt to mess with you in the legal system.  You may want to avoid the judicial system, but sometimes it comes and bites you hard even if you are active in trying to stay out of its reach.  Time is really the one resource that anybody has to sell when you finally get down to the gritty details of economics, and it takes time to be a developer to create projects like this.  Also, even simply maintaining the software afterward takes time and effort, fixing bugs that show up and perhaps putting in tweaks.

Anyway, enough of the issue with the overhead costs.  I am afraid that this is going to effectively split or fork the Bitcoin network, and that isn't a good thing either.  I want to work with the Bitcoin community, but if they won't have us, we may have to move on.  Threats to Bitcoin will still be relevant and I'm not going to leave completely in a huff, but as a separate application it will be essentially a fork of Bitcoin if we proceed with the path I've suggested in terms of a completely separate coin chain and currency.  It might be interesting so far as a social experiment is concerned to see which way is better and which "coin" is going to be more accepted in the long run.  I am challenging some of Satoshi's assumptions here too, but not overly so.  Two very similar project with slightly different goals but which also support each other might be beneficial to each other as well, especially as there is going to be a huge amount of common ground to work with.

[ribuck]

Anyway, I have registered domainchain.org, in case people like it.

Care to stick a wiki up on there?

Yes I'll do this. Don't panic!

But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

[kiba]

Yes I'll do this. Don't panic!

But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

We won't make fun of you.

On my Bitcoiner honor!

[kiba]

Trying to predict the exact numbers required is equal to central economic planning, and pointless.

<--- In another thread.

So there's an economic calculation problem. We...cannot reliably predict how many domain name registration are needed each block.

So we going to need to price generation of blocks, somehow?

[RHorning]

I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

I'm always interested in alternatives.  Take your time though, and I'd like to see how it is different than what we've proposed here.

[ribuck]

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.

Here's a quick summary:

• Bitcoin already allows for a text "payload" to be included with a transaction. Any bitcoin transaction that is sent with the right payload becomes a domain name registration.
• To register a domain name, just send any amount of bitcoin to yourself, with a special payload. This payload identifies itself as a DomainChain payload, and contains the desired domain name plus the IP address of the authoritative name server(s). If no-one else already has that name registered, it's yours.
• To transfer a domain name to someone else, just send them the associated bitcoin (actually any part of the associated transaction will do). The GUI will let you do this in terms of "domain names" rather than in terms of "coins".
• To change the authoritative name server(s), just send the associated bitcoin to yourself with a payload that identifies the new authoritative name server(s)
• Registrations last forever unless you terminate them by sending that bitcoin to yourself with a payload that is a DomainChain "cancel" message
• You can register a domain name with the smallest convenient amount of bitcoins (currently 0.01 BTC), so the system imposes no scarcity of domain names. However, miners will impose transaction fees which increase as the block size increases. This provides a disincentive to registration spammers
• To resolve (lookup) a domain name, the block chain is scanned for the most recent valid transaction for that domain name. In principle, anyone can run a DomainChain resolver, but in practice most users will use a DNS service that is DomainChain-aware

Advantages:

• Provides domain name registration with the same level of pseudonymity as Bitcoin
• Holds registration data in a tamper-resistant distributed manner
• Strengthens Bitcoin by providing additional economic incentive for generators (because they will be able to charge transaction fees for domain name transactions)
• Can be implemented much more quickly than any other scheme that has been proposed so far
• Existing bitcoin clients are unaffected. If they receive coins that are associated with a domain name registration they will see them as coins. do not display domain name registration transactions. No modification is needed.

Disadvantages:

(I'm sure you'll let me know of the disadvantages.)

Implementation:

1. Patch the standard bitcoin client. Run it on the bitcoin test network. The patched client will have a separate panel for domain names that are associated with bitcoins. These bitcoins will not show on the standard panel, nor will they be included in the total balance available to spend. On the DomainChain panel, instead of a "send coin" button there will be buttons for "register a new name", "change nameservers", "transfer a name" and "abandon a name". There will also be a scrolling list of domain names together with their nameservers.

2. Write a program that scans the block chain to determine the authoritative domain name servers for a given domain name. Patch a standard open source domain name server to consult the output of this program as part of its name resolution.

3. If it works well, persuade Satoshi to allow these transactions in the main network. Of course, it would be technically possible to run it on a new network with a new block chain, but who wants competing currencies?

There's obviously a lot to be fleshed out, but I think the design is workable and easy to implement.

[ribuck]

The DomainChains payloads could look like this:

Registration (with and without nameservers):

Code:

DomainChains my-domain.tld
DomainChains my-domain.tld 201.73.213.92 98.252.10.34

Changes of registration details use the same payloads, but the payloads must be sent with a coin that is already associated with the domain name.

To drop a registration and turn the bitcoin back into a spendable coin, send this payload with a coin associated with the domain name:

Code:

DomainChains drop

Obviously this is just to illustrate the idea. The concrete syntax may differ.

[kiba]

Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!

[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.

The #1 disadvantage:  My complaint about shoving useless and meaningless data into the transaction block.  It would work, but there may be changes to Bitcoin to get rid of this "feature" as it may be seen as an attack rather than something useful for the project.  I am not alone with this attitude.  It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion.  Expect more resistance if you actually get a client to accomplish this task.  Bitcion is not bittorrent. 

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.  Instead you would likely need some other application which is reading all of the transaction and either "accepting" or "rejecting" the domain registrations.  Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear "ownership" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system).  Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

I admit that some of this could be worked out simply by saying that the first "registration" takes precedence, including in the same block.  Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would "apply" the rules which identify a valid transaction.  Competing software could put in different "rules" for the same data as well and put different domains as valid.

It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

This could work.  It would be real nice to see what Satoshi thinks of an "abuse" of the transaction scripts in this fashion.  My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.

BTW, one advantage to going this route is that it would not require any reboot of the network

I do have my reservations about the direction this is going, but I'm willing to have an open mind about it.

[theymos]

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.

[ribuck]

RHorning,

The one objection of yours that I can't address is the one about "shoving useless data into the transaction block". This is something for others to decide, and at this time I would respect whatever Satoshi said. But we should not be concerned about "opening the pandora's box" because the box is already open and lots of people are going to look inside in the future. That "problem" (if it is a problem) is for the owners of Pandora's Block Chain to decide.

What I suggest we do is to try out DomainChain on the test network, and see what bitcoiners think of it when it's able to be experimented with. I'm sure we'll get feedback on whether or not it's welcome in the live block chain.

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

There's nothing forcing generators to include bitcoin payments that piggyback DomainChain data, but why wouldn't generators want to include them if the transaction fee is high enough to cover the extra costs plus a profit margin?

Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.

That's true, but it's no different from Bitcoin itself. The block chain only has value because a majority of users are prepared to interpret it in a certain way, according to certain rules. If that works well enough for coins, it will work well enough for domain names.

Although we need generators to include the DomainChain transaction data, we don't need the average person's bitcoin client to recognise that data, or act on it in any way. Only the resolver software, and the modified clients used by those who want to register domain names, need to recognize the extra data.

Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

The first to get their registration into the block chain gets the domain. Ideally the generator who processes these transactions will reject the invalid one. Failing that, the resolver will certainly locate the valid one.

It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

I don't think there is any problem here. The registration data is re-sent if the domain name is transferred to someone else by spending the coin. All we care about is who has the current registration. We don't care about the history of the domain name.

This could work.

Let's do the "simplest thing that could possibly work" for the proof of concept. This seems to be it. If people like it, they will accept DomainChain into the Bitcoin block chain. If they don't like it, we go to plan B.

[ribuck]

I haven't read your spec yet, but...

...Some sort of expiration is required..

That's fine. It's not problematic in my design.

Normal clients will ignore such transactions.

That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client.

[ribuck]

Wow, after a first readthrough of the spec by Theymos and Nanotube I am astonished by the similarities. And their spec is so much further developed. This is excellent!

I will look through it in detail tomorrow as I've already spent way too much time on this today.

[Hal]

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.

[kiba]

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.

[ribuck]

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.

What do you suggest is a better way to decide who gets sex.domain?

[kiba]

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