The role of the block chain is more than merely timestamping, but also to cryptographically certify the integrity of that data.
The Bitcoin block chain provides two functions:
- Secure distributed timestamping
- A guarantee that any transaction in a deep enough block is valid
The only use for the validity guarantee is to avoid having everyone download the entire block chain. Bitcoin doesn't even use that feature right now.
I would add to this that Bitcoin also verifies block and transaction information to identify if it conforms to some sort of network protocol standards, which include aspects like making sure that double spending isn't happening and weeding out some flood attacks on the database. Placing data into the transaction script as random superficial data is not going to be measured against any sort of network protocol at all or verifying that the data may have been duplicated. The only defense against abusing this vector of attack is the transaction fees for transaction size.
"Shoving random garbage" into the Bitcoin block chain provides timestamping, but not validity guarantees. As Bitcoin doesn't even use validity guarantees at the moment, this is clearly useful in many cases. Data that is only necessary for a few weeks, for example, can be included this way: clients only need to download the last 2000 blocks or so, which should never be too difficult.
I could see a thin client only having to be "watching" for recent blocks sent around and verifying that a transaction got incorporated into a block, and furthermore that the block was accepted into the primary chain where additional miners are adding on additional blocks. Such a client would not be in a position to identify double-spending, however, without the full block chain. That could involve "trust" of the core nodes which are involved in the mining activity.
The validity "guarantee" as I've described above is to see that the data being included meets some sort of criteria for inclusion. Verification of "ownership" of a piece of data is also included here, such as if somebody has the ability to spend a particular transaction output. In the case of something like BitDNS, it would be to verify that the person making the transaction has "ownership" of the domain record to be able to make changes or modifications to that data and to produce a chain of evidence in terms of who authorized those changes. Currently Bitcoin only performs this "service" for transaction data alone and my suggestion was that perhaps it could be more generalized in some fashion to include other data.
A "thin" BitDNS client would only have to see the changes to the data records and not the full chain of evidence in a full block chain, and perhaps they might only be interested in information about "their" domains thus filtering out even more information that is of interest to the central nodes for full verification.
There are certainly some cases where the double-spending guarantee is required. But just because it is required doesn't mean you can design the incentive structure well enough to attract the necessary CPU power over the long-term. BitDNS, for example, is in a dangerous (and IMO impossible) situation: not creating enough domains will make the system useless in the long-term, but creating too many will not give generators enough incentive. Maybe it's even impossible to get enough incentive for a DNS-only block chain. Trying to predict the exact numbers required is equal to central economic planning, and pointless.
In terms of deciding where to draw this balance as you are trying to suggest, that is what a market is for. Certainly no single individual is going to figure that out, but setting up in effect an auction market which makes this prediction through economic incentives is something that I think is going to provide a much stronger balance for this situation. If too many domains are created and created on the cheap, fewer people will be interested in participating in mining and processing the transactions. If domain creation is too expensive and rare, there will be incentives for somebody to create a new node that starts to accept more domain transactions at a cheaper price and where many more people will start to participate in the network.
The issue here to me isn't if the concept of domain registration done in this way would work, but rather how it is going to be paid for and who pays for that service. My hope here would be to get those using the service to pay for that service, and ideally to pay for that service in Bitcoins. This could be a source of additional revenue and fees for miners and thus strengthening the main Bitcoin block chain with additional CPUs as well as growing the size of the Bitcoin economy. If the members of this community don't want that money, however you define that money, it will go elsewhere. There is a market for a service of this nature with real demonstrated demand for such a service. I just think it is sort of sad that it is being driven out of the Bitcoin economy is all.