I have fleshed out the DomainChain spec quite a bit more:
http://domainchain.org/wiki/doku.php?id=start


Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain

I think you got the context mixed up here.  The reason why the payment is irreversible is because it is derived from a completely different chain.  If there is a chain split in the domain registry chain, the fees spent as bitcoins (going into a completely different system) will have already been spent for those block in the "losing" chain.  Transaction going into that "losing block" are essentially a wasted effort.

I'm suggesting that somebody simply sets up enough of the protocol to be able to appear to be following the domain processing rules so as to appear "legit", but they only have to make an appearance to get a block accepted.  Perhaps they even get some blocks accepted, but then start to make up stuff or somebody attempts to register an existing name (as a scammer claiming they can hijack a domain from somebody else or however).  If there is any reason why the rest of the network doesn't accept the block, for any reason, all of the fees collected by that "miner" or "registrar" would still be collected by that scammer regardless of if it actually gets into the chain.

On the other hand, if the block being "authenticated" is a part of the same chain that creates the currency, this isn't a problem.  If the blocks get rejected by the network, any fees (set up in a system like how transaction fees are done with Bitcoin) are also similarly rejected by the network too.  Any chain splits remove any fees paid to "losing" blocks and therefore can be ignored.  This is why the authentication must happen in the same chain as the transaction.  Either that is in Bitcoin or a parallel currency, but if it is with Bitcoin, the authentication must happen within the Bitcoin network too.  Otherwise, there isn't a way to get payment to the miner with an outside currency that is similar to Bitcoin without fraud and a significant attack on the payment system.  This is fraud because a service is being claimed and paid for, but the service isn't being rendered.

Hacking the data into Bitcoin transactions does not perform authentication of the data and pushes that need somewhere else.  In effect, it permits "double spending" of a domain name or allocation of a domain name to more than one person with ambiguity over who actually owns that domain.

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.

I dont see how this was a red herring.  Unfortuantely if you use a Bitcoin-like system of authentication of a transaction, you can't conduct that transaction in Bitcoins, at least for authentication transaction fees.


I'm really curious about how you make this sort of transaction risk-free without having it integral to Bitcoin as some sort of authentication mechanism.

One thing that really makes this nasty is that the "miner" is unknown until the block is added into an authentication hash tree.  You don't have the two key release mechanism because one of the parties in the transaction is unknown until after the hash is successfully put in, and even that is conditional.

It makes it much more secure and coincidentally easier to scale to treat it as a simple exchange between two currencies, something that happens entirely outside of the system as evidenced by the various exchanges that already exist between Bitcoin and other currencies.  BTW, I agree that Bitcoin or any other monolithic application should not be the ultimate repository of all human knowledge and interaction, as I don't think any sort of system can possibly scale to that size.  I'm not even sure TCP/IP itself can scale to that size.

This is much of what Jgarzik has said that it is unworkable, but going from a different perspective.  The problem is that everybody is trying to get these fees paid for with bitcoins, and I don't think that can be done at all, at least directly.  As an indirect mechanism, perhaps, such as a floating currency that isn't locked down until after the exchange takes place.

BTW, the idea of a "locking exchange" would be a fantastic idea for a peer-to-peer currency exchange network, particularly for electronic currencies like Bitcoin or Liberty Reserve.  I just don't see how you can put any sort of authentication transaction fee in a block that is denominated by a currency other than the currency represented by that block itself.

Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?

It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.

The possibilities are endless.

Bitcoin rewards you, essentially, with a piece of [digital] property.

bitcoin itself is artificial scarcity.

The supply of bitcoin is just an integer determined by network. Otherwise, bitcoin are non-scarce. I can copy a wallet a millllllllllllioooooooooon of time and it will contain the same integer. It's a very weird form of scarcity and non-scarcity.

I agree.  All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.

You might consider a certain amount of work to generate a domain, instead of a fixed total circulation.  The work per domain could be on a schedule that grows with Moore's Law.  That way the number of domains would grow with demand and the number of people using it.

It seems like killing two birds with one stone isn’t enough on the bitcoin forum; one has to kill three.

Firstly, I would like to commend nanotube's+theymos proposal.  I like it because it makes economic sense, and it is simple.
The design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the ‘issues’ said. (I still think there is really nothing wrong about how it is proposed to work as it is.  However, if there is a better way of doing it, why not?)

Before we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply.  Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.

If a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.
So with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.


The main concern on the forum is the inclusion of ‘other data’ in the block chain; the problem isn’t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.
In discussions elsewhere, it has been shown that:
1.   Generators will happily include any data that is profitable to include.
2.   The block size will grow to a size that balances data demands and the profitably of the miners.
3.   Clients only need to ‘keep’ data that they interested in.  Data that is irrelevant to the client may be forgotten once processed.
4.   Transaction balances may be used to cull the chain of old transactions.
Therefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want).  The only outstanding issue is: transfers.

What has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it.  Only after processing may a client delete any data that it doesn’t want.  This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.


I propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

Finally include a ‘summary’ group that contains only the changes to the transaction balances accumulated in all the other groups.

A Block could contain something like this:


Once one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes.  This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.

The important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.


Nanotube and Teymos’s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries.