Topic: BitDNS and Generalizing Bitcoin - page 4. (Read 122681 times)

I'm working on bitx.  You can follow my (slow and leisurely) progress at the fossil repository (http://bitx.appamatto.com) and my blog (http://appamatto.com).  Once that's done, I'll work on either the bitcoin on bitx implementation or on bitCA, which seems to be the better way of doing DNS and related services.

I think theymos/nanotube are working on their proposal as well.  There are probably other proposals that don't require additional block chains or changes to changes to bitcoin proper, but even then it seems a little to early for finished products.

Actually, I have started work on an implementation (not based upon bit-coin source).   

I think there needs to be a way to recycle a name after it has been killed.  As long as the 'trust' is based upon public keys and the name is just an alias.

In theory one public key could have two names.   

I am under the impression that nothing codewise is getting done.

I don't think invalidating a name should put it up for bids.  I think the name is just done at that point.

Furthermore, let us generalize this principle.

   - the owner of a key may 'grant' other names privileges such as:
      * may transfer name
      * may sign data
      * is trusted by me

Now you have an encrypted 'web of trust' and companies like google.com can track which admin made changes and grant/revoke permissions. 

So lets assume that the private key for 'bytemaster' has been compromised.   Bytemaster issues the command to invalidate it.  Now 'bytemaster' is up for bids to the highest bidder.  All trust must be placed in the public key and not the name itself.  Transferring the name to a new owner would have to reset the trust.

Seems like the solution to this problem is to have a 'backup key' such that when the primary key is nuked the backup key takes over.  There could be multiple 'backup layers'.    To transfer a name would require signing the transfer will ALL backup private keys.  When a key is compromised the backup key could then be used to replace the primary key without destroying the reputation of the owner.

Now a site like 'google.com' could give out the private key to 'trusted' admins and lock away their 'backup key' in a secure vault without having to assume the risk of their valuable 'name' being destroyed by one dishonest admin.

Right.  I'm thinking that this could be a huge boon to security and privacy.

I'm not sure that it makes sense to talk about "sites" in particular, but I think we're on the same page.

One problem with certificates is that sometimes the private keys are secretly leaked to government agencies or "discovered" by other third parties.  I think an important part of this system would be a "kill signal", that is a way for a name to self destruct by signing the order with its private key.

This way, whistleblowers who discover a private key would be able to anonymously convey the message that the site's security has been compromised.  There is no reason for their pseudonym or their public key to appear in the system anymore because there is no way to recover from such a private key exposure.  For instance, if a new public key were created and "blessed" by the old one, we couldn't tell if this was an action taken by the authentic person or the imposter.

Yes, all than needs to be included in the block chain is Site A's name and a hash of Site A's Public key.  Gaining access to the site via their IP address can be done through any method.  The point is that it is impossible to 'pretend' to be 'Site A' without having Site A's private key.

Thank you, da2ce7, for that explanation. If that blocks man-in-the-middle attacks, I guess my question is why we're not already putting a hash of the public key into regular DNS records (particularly as signing of the DNS system is currently being implemented).

But yeah, I think a lot of people would like to be able to bypass their CA if there was a way.

I don't know about step 3.  That is, I wonder if it's sufficient to simply have A's public key and then get the IP address through other means, making sure it's signed by A's key.

Each block is allowed to register a maximum number of new names.   Transaction fees determine the priority of name registration.  Hashing the name prevents 'front running' good names.

By tying a concept such as an 'IP' address into the block chain you end up with a fundamental problem of too narrow a scope (IP based networks) that still depend upon current network design.   Suppose that web 3.0 did away with dedicated servers and instead used a gigantic distributed hash table that mapped keys (domain + filename) to values (files) and verified permission to modify the value stored at domain+filename based upon signing the contents of filename with the private key of the domain.  In this situation content is not looked up by 'ip address', but by a hash of the contents domain + filename.

Now imagine that this gigantic distributed hash table stored an 'ip address' at domain/ip.   So users would buy a named public/private key pair via BitName and then trade it (including partial ownership) using the block list.  Then someone invents a snazzy DNS app that knows how to lookup the IP in the DHT.  Users of the domain lookup would not need the block list, they would simply trust the DHT which would validate all writes against the blocklist.

@ribuck

Certificate Authority's work by having a 'master private key' that signs people public keys.  The CA (should) check that the public key indeed belongs to the person it claims to belong to.

Such as CA > signs > address.com key.

Web browsers have the public  keys of many CA's installed by default, when a browser comes across a sight that has a public key it
1. Checks if the public key matches the address of the site.
2. Checks if any of the known CA's public keys match the signature included with the sites public key.
3. Checks if the public key hasn't been revoked or expired.

This entire system revolves around the trust that the user has for the CA's.
The problem is that in practice CA's sign anything, including adversaries, so valid sites owned by evil people get accepted in the browser.  But, worse. CA's sign public keys of sites that already have an active private key to 3rd parties (such as governments).  This allows man-in-the-middle attacks that cannot be easily detected, as to the browser the site is perfectly valid.  However in practice it is just a proxy of a site.


The solution to this major mess that we are in is to get rid of the CA!  We let people 'tie' a public key to something that is human rememberable, (such as a user name, or a DNS name).

1.  The owner of Site A, create a private/public key pair, this par contains a Public Key.  The owner then Hashes the public key and creates Hash(KeyA).
2.  The owner of Site A then creates a new BitDNS transaction that contains "SiteA" and Hash(KeyA).
3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)
4.  Then this user, navigates to Site A's IP address, and is sent Key A, and a signed welcome message.
5.  The user checks if Hash(BitDNS KeyA) == Hash of (IP KeyA).  If this is true, then a man-in-the-middle attack is impossible.

For an adversaries to pretend to be Site A, they must re-write the entire block chain from the point that Site A was registered.  This process would be very public, and Site A would quickly work out that it has been attacked.

I believe this system is very secure, and to my knowledge no easy attack has been devised.

A search for "distributed certificate authority" yields many academic results.  I wonder if any of these provide the same guarantees that a block chain based approach would?

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.

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.

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.

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.

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.

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.

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?