BitDNS and Generalizing Bitcoin

This is based on a discussion on 11/14/2010 on the IRC channel.

BitDNS

Although there have been attempts to tackle DNS in a distributed way in the past, I don’t think there have been solutions that have fully removed authority from the equation.

If there was such a solution, it probably would have been able to implement bitcoin directly on top of it, and we all know that didn’t happen.

However, it seems possible to create a bitcoin clone (bitDNS) that provides a solution to distributed authority-free name allocation and transfer.

Basically, the system is a copy of bitcoin where miners generate 50 new name mappings of their choosing whenever they win a block. The name mappings change hands in a way similar to btc.

This system is separate from btc, and it is likely that escrow services will provide a name market in btc, since any such escrow can leverage the two block chains to verify transactions. Miners can pick names that are already being bid upon with funds in escrow to make sure they are able to sell generated names quickly.

Generalizing Bitcoin: BitX

This is all well and good, but now there are two block chains, and any given miner can only generate for one at a time. This will be really bad when even more clever applications are developed that require bitcoin-like properties but will be susceptible to attack in their early development. Enter BitX, designed to support any and every such application on a single block chain.

BitX has a block chain like bitcoin’s. However, miners choose to distribute arbitrary application data in the following manner:

1. The payload in a block is a mapping from application names to hashes: [“bitcoin”: , “bitDNS”: , “bitHaiku”: , …]

2. Any given block is only allowed to create one new application that does not already appear somewhere in the block chain. This is to prevent spam.

3. Any given block may omit data for any application. Similarly to the current situation, miners have a choice as to what transactions to include, and this extends to the choice over which applications to choose to send data for.

4. Application data is transfered separately, so for instance a bitcoin client will never have to care about haikus or DNS names, as it can simply ask someone for the bitcoin payload and make sure it matches the hash in the appropriate block.

5. On the client side, blocks are only ever rejected for an error relating to the previous four points. In other words, blocks aren’t rejected for carrying a faulty bitcoin payload, because this might result in rejecting valid DNS transfers. Instead, bitcoin clients accept the most recent block but ignore the invalid bitcoin transactions.

Miners will engage in activities they feel profitable. For example, miners may not see a profit motive in haikus, but will want to generate DNS names because they can be sold easily. I think this system could support a very wide range of useful applications while adding only a minimal overhead to the block chain itself. Application proliferation is kept in check by the interests of the miners themselves.

This also seems to make the block chain more modular, as it separates concerns; the block chain is strictly for creating a universal state of the system for everyone in the world, and application data travels out of band but is verified against the block chain.

One effect of the modularity is that applications can ignore illegal or undesirable application data and only download payloads for the applications they care about.

As a last thought: BitX poses a significant threat to bitcoin, because money may not be the “killer app” for the block chain. In other words, what happens when bitBeanieBabies becomes bigger than bitcoin? Suddenly the bitcoin system doesn’t seem as secure. If both were running on top of BitX, they would enhance each other’s security, and interfere with one another minimally.

Thanks for reading, Appamatto

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn’t need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

Instead of fragmentation, networks share and augment each other’s total CPU power.  This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one.  Instead, all networks in the world would share combined CPU power, increasing the total strength.  It would make it easier for small networks to get started by tapping into a ready base of miners.

Quote from: nanotube on December 09, 2010, 09:20:40 PMseems that the miner would have to basically do “extra work”. and if there’s no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner’s incentive to include bitdns (and whatever other side chains) ? The incentive is to get the rewards from the extra side chains also for the same work.

While you are generating bitcoins, why not also get free domain names for the same work?

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

You have one piece of work.  If you solve it, it will solve a block from both Bitcoin and BitDNS.  In concept, they’re tied together by a Merkle Tree.  To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.

In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that’s not a big deal.  You’ve been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility.  We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.

Note that the chains are below this new Merkle Tree.  That is, each of Bitcoin and BitDNS have their own chain links inside their blocks.  This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain.  This is two timestamp servers not sharing a chain.

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.

Quote from: Hal on December 10, 2010, 07:14:04 PMadditional 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? Right, the exchange rate between domains and bitcoins would float.

A longer interval than 10 minutes would be appropriate for BitDNS.

So far in this discussion there’s already a lot of housekeeping data required.  It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin’s chain.  Some transactions:

Changing the IP record.

Name change.  A domain object could entitle you to one domain, and you could change it at will to any name that isn’t taken.  This would encourage users to free up names they don’t want anymore.  Generated domains start out blank and the miner sells it to someone who changes it to what they want.  

Renewal.  Could be free, or maybe require consuming another domain object to renew.  In that case, domain objects (domaincoins?) could represent the right to own a domain for a year.  The spent fee goes to the miners in the next block fee.

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.