BitDNS and Generalizing Bitcoin

[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.

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?

[1714189310]

1714189310

[1714189310]

1714189310

[1714189310]

1714189310

[1714189310]

1714189310

[1714189310]

1714189310

[da2ce7]

@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.

[bytemaster]

"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?

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.

[appamatto]

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.

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.

[ribuck]

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.

[da2ce7]

3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)

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.

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.

[appamatto]

3.  A user looks up Site A in the BitDNS record and gains it's IP address AND Hash(KeyA)

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.

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.

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.

[bytemaster]

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.

[bytemaster]

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. 

[appamatto]

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.

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

[kiba]

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

[bytemaster]

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.   

[appamatto]

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

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.

[kiba]

Progress report?

[bytemaster]

The design of bitcoin as a linked-list of transactions does not apply well for non-linked list state changes.  I have been struggling with how this could all be implemented in a more generic manner an have come to the following conclusions.

Review of Goals:
1) Global name registry, 1 name -> public_key
2) Ability to issue new 'stocks' backed by real commodities or simply 'competing' bit-currencies.
3) Ability to expand block chain to support new commands and state changes.
4) Keep application data outside the block chain


1) Each block in the chain contains one or more 'transactions'.
2) A 'transaction' is a list of 'commands' to perform on one or more 'global database tables'. 
3) Each client must process the commands in order to arrive at the same 'global database state'
4) The changes to the global 'state' must be kept in a BerkeleyDB transaction until confirmed by enough blocks.
          - any changes to the block chain (finding a longer chain) would simply 'abort' the 'db transaction' and cause it to try again.
5) The end result is a block chain able to manage the state of any number of different 'tables' simply by defining
         new commands.

Effectively the block chain would represent 'edits' from the last 'balance sheet' or 'snapshot'.   

Initially there are two commands:

1) register_name  'name'   'public_key'     (name may only contain a-z0-9_)  ('.' is reserved as a delimiter)
     - the command is only successful if the public_key is signed by the private_key and 'name' is not registered
     - if the name is registered, then it must be signed by the old private key to transfer it.

2) transfer  SHARES  'stock_name'  'from_account_name'  'to_account_name'
    - 1 share = 1 / INT64_MAX
    - if from_account_name == 'new' then transfer must be signed by the private key of 'stock_name', otherwise by the private key of 'from_account_name'.  A 'new' stock can only be issued for 'stock_name' once.

    - each 'account_name' may have a different balance for each kind of share it holds.

Eventually there will be other commands to assign 'privileges' from one name to another.  To implement escrow transactions.  To post 'bid' and 'ask' transactions and thus eliminate the need for trusted 'exchanges'. 

   Now you can create commodity backed currencies and trade them as long as you trust the 'issuer'.   In theory you would have a 'name' for every stock on the stock market, every national currency, 'gold', 'silver'.   It would be like the days before central banking where each 'bank' issued its own paper currency backed by gold/silver.   The difference would be that everything would be public and there is a hard limit to the ability to print.   

I have implemented the back-end database, have all of the RSA encryption in place and am working on the block chain now. 

I am still open to ideas / potential pitfalls. 



   

 

[kiba]

theymos/nanotube, working on your implementation?

[FreddyFender]

I made a little writeup on the original reason for this post before it became strictly bitDNS topic. There are a few thoughts and would appreciate anybody's input.

http://bitcointalk.org/index.php?topic=2163.40

[kiba]

Progress report?

[hacim]

If people are interested in finding working alternative solutions to the existing centralized certificate authority problem, the Monkeysphere project (http://monkeysphere.info) has figured out how to do distributed, web of trust based, https X509 certificates. They have done quite a bit of key translation work and now you can verify a https website via your OpenPGP key and the web of trust, instead of relying on a centralized "authority". It also works for ssh host and user validation as well.

[FreddyFender]

http://www.aaronsw.com/weblog/squarezooko
Apparently this topic is now dead...