BitDNS and Generalizing Bitcoin

[ribuck]

However I'm still in the process of writing out it more formally.

Feel free to write it up on a new page at the domainchain.org wiki if that's convenient for you:
http://domainchain.org/wiki/doku.php?id=start

[ribuck]

Let me throw in a rough outline of a completely different idea, that is not based on the Bitcoin chain.

Suppose the rule is this:

A domain name registration is a mapping from the domain name to a list of (one or more) name servers that are authoritative for that domain name.

The "owner" of a domain name is whoever posts a mapping with the hardest proof of work attached.

Here's how it would work. If no-one else has registered the name that you want, post a mapping from it to your nameservers, together with a hash that represents some proof of work. Now keep on hashing, and every time you find a stronger proof of work, re-post your claim with the stronger proof attached.

As long as you keep hashing, you will occasionally find a stronger hash, which will strengthen you claim on the name.

If someone else also wants your domain name, they can start hashing but you already have a head start. Of course, they can devote more machines to hashing than you, in which case they may be able to generate a better hash and take over your name.

Of course no-one wants to randomly lose their name because someone else was lucky enough to get a very good hash without really trying, so the rule could be that a hostile takeover requires a proof of work 16 times harder. Also there could be a 30-day delay before the takeover, which gives the existing owner a window to hire a server farm and retain the name if it's worth enough to them.

The end result is very different from our current system, but in the end it allocates every domain name to whoever actually wants it the most.

[bitcoinex]

I am propose to use a TLD .bit for bitdns

3 letters is better than 6

microsoft.bit
linux.bit
facebook.bit

[da2ce7]

Ok! I have written out the proposal, hope you like it... the BitDNS part nees fleshing out. However from what I have written you can get the drift.
 
http://domainchain.org/wiki/doku.php?id=bitname

oh yeah, thanks to ribuck for the wiki.

[da2ce7]

In my proposal: http://domainchain.org/wiki/doku.php?id=bitname

The proposal that I have made has covered 3 main areas.

First: Changes to the Bitcoin Protocol.

Expanded templates, (allowing to check transactions based upon what they claim to be).  This also allows new services to be run within the chain without changing the protocol.  Using a strong scripting language it should be possible to make 'plugins' for generators so that they may accept new types of bitcoin transactions.

Transaction Grouping, this allows transactions to be grouped together by template.  Clients will only need to download the summary and the hash tree, unless they want more detail.

Burning transactions.  This is a new sort of transaction fee that 'burns' over time.  It contains two qualities, firstly total number of coins to be to be burnt, and secondly, the rate (per block) that it is burnt at.  This is the basis of the compensation to generators for including extra data in the block chain.   When the transaction stops burning, the extra data may be deleted.

Second: BitName

BitName is a named address that has a fingerprint of a public certificate.  Instead of sending bitcoins to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP, one could send bitcoins to 'da2ce7'.  The BitName concept is built upon burning transactions.  Each transaction that declares a name, must include a burning transaction to keep the name active.  The higher the rate of burning the more likely that the transaction will be accepted.  If the rate is too low, the network will likely ignore or forget the name early.

If a generator accepts a new transaction of the same name as a pre-existing, the network will likely orphan the block, unless the burning fee is so low that the network regards the name as spam.

The other significant benefit from having a BitName is public certificate verification, when one sends a message that is signed, the key signing the message can be check against the known name of the source.  The fingerprint included in the block chain then can be used to verify the signer.

Third: BitDNS

BitDNS is derived from BitName.  A BitName should be used to make any new BitDNS records.  This requirement in the future can be used for spam prevention.

Both the top-level root domains and the 2nd level domains need to be globally unique.  Root BitDNS records are expensive and both the initial fee and the burning  fees are network enforced.  The main purpose of the root domains is top provide a service to the 2nd level domains.  To be accepted by a top-level domain, the fees defined by the top-level domain must be paid to its address.  This is enforced.

2nd level domains behave much like BitNames, with two main difference: first, to be used the domain must pay registration fees to at-least one top-level domain.  Secondly, IP addresses can be binded to these domains.

Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain.  Man-In-The-Middle attacks are very, very, very difficult under this system.

I'm still working on the sub-domain structure.

[jgarzik]

Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.

C++ is a strong scripting language.

Get the other technical details right.  Picking a programming language is the lowest task on the priority list.

[da2ce7]

Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.

Yes, any strong scripting language language will do.  I'll leave it up to the programmers to pick the language. 

[bytemaster]

Amazing that I was just inventing this kind of system (Bitcoin based DNS) only to find this huge thread discussing it.

I actually suggested something like this before with this post: http://bitcointalk.org/index.php?topic=701.msg7545#msg7545 (Bit Stock Broker).

The fundamental key here is verifiable ownership and transfer.  The "thing" that is being transferred whether stock, DNS, title, etc should be handled out-of-band.

Every 'thing' needs a name.   100% of all bitcoins (present and future) is the bitcoin 'name/stock'.
Every 'thing' may have partial ownership which may be transferred.
A DNS is just a name owned by one or more public keys.

Assuming we had a means of transferring fractional ownership of arbitrary names then anyone can validate a use of that name with what ever service.

So suppose BitDNS issues a new thing named 'apple' and assigns it a public/private key pair and 100% ownership.  Facebook could now require that you sign your account application with the private key of 50+% ownership of the 'apple' name and at the same time a DNS service could make the same requirement.

All over the internet everyone could verify all data that came from some set of owners.  So the owner of apple could create a DNS file that contains an IP address and then sign it.  That file could be distributed and queried by what ever p2p or server/client system user applications desire.

To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred.
Limit the creation of new 'names' to N per block. 

By only storing the hash of the name you enable verification of ownership without giving away anything about 'what is owned'.

The only other feature we would need is to define a transaction such as:

100 BTC From MyBtcAddress -> Block Creator
100% name From NEW -> MyBtcAddress  (signed by MyBtcAddress)

When a block is created 'high bid wins' and low bids for name are ignored.

Keep all uses of this name (Facebook, DNS, email, forum login, reputation systems, etc) out of band. 

[Hal]

"To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred."

In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.

I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?

[jimbobway]

I am hoping the developers implement Satoshi's ideas which are:

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

I especially don't want a fork so my Bitcoins are worth something.

[kiba]

How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.

The longer we wait, the less chance of success we will have.

[da2ce7]

How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.

The longer we wait, the less chance of success we will have.

Hmm, I don't think that the longer the wait the less chance of success...

I'm interested in comments about my proposal.  I think that it solves much of the issues in a logical manner.

[kiba]

Hmm, I don't think that the longer the wait the less chance of success...

There is some compoetition in the form of dot p2p project.

[appamatto]

Hmm, I don't think that the longer the wait the less chance of success...

There is some compoetition in the form of dot p2p project.

I wonder if more thought should be put into the nature of names.  Is providing an abstraction over ip the real intent?

What about registering a public key, so that you could later use the name as a pseudonym and show that you're the true owner?

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

[bitcoinex]

This system can be used not only for DNS, it can hand out nicknames in various decentralized networks.

For example, sooner or later, the phone numbers will be replaced with names that the user can create their own.

[da2ce7]

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

All the chain needs to include is a name and a fingerprint of a public key.  Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint.

The system is simple and secure.

[ShadowOfHarbringer]

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

Currency should stay currency, domains should stay domains. This should be separate things.
It is stupid to push something like this on the main client / blockchain.

[da2ce7]

1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.

Domain names shouldn't be 'given' out, it makes no logical scene.  The separation issues is resolved by having 'groups' within the block.  This allows the clients to download what they care about, and ignore the rest.

Bitcoin must be use as the payment method, if we are using the bitcoin CPU power.  Bitcoin already has a built in 'instant' compensation method called 'transaction fees'.

I have proposed a secondary ongoing compensation method called 'Burning transactions' allowing things, like data, to compensate the bitcoin network over it's life.  Then the data can be removed from the chain!

Having a interdependent chain sounds pretty, but would be ugly in practice. Compensation in bitcoins would no-longer be natural and would require messy cross linking.

[ribuck]

Burning transactions sound like a useful mechanism, apart from the fact that they would require changes to Bitcoin. I keep wondering whether there is a way to take the burning mechanism outside of Bitcoin itself, I can't think of a good way to do so.

I also wonder whether it would be a good thing to turn all Bitcoin transaction fees into burning ones, to spread the benefit of processing a transaction beyond the immediate generator.

PS: I don't understand the bit about doing away with Certificate Authorities for secure internet connections, but if this is possible it would be a very popular fringe benefit.

[appamatto]

With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?

Or has public key naming already been solved?

All the chain needs to include is a name and a fingerprint of a public key.  Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint.

The system is simple and secure.

I agree that it is simple.

I think a reliable database of pseudonym to public key (or hash of public key, etc.) mappings could solve a variety of problems.

For example, i2p has an issue distributing eepsite keys in some trusted manner.  And, we're all aware of problems with DNS.

It seems to cover the "irrevocable eternal resource identifier" aspect of DNS but not the "pseudonym to pseudonym transferable virtual property" aspect.