---
title: Name System
...
We intend to establish a system of globally unique wallet names, to resolve
the security hole that is the domain name systm, though not all wallets will
have globally unique names, and many wallets will have many names.

Associated with each globally unique name is set of name servers. When one’s
wallet starts up, then if your wallet has globally unique name, it logs in
to its name server, which will henceforth direct people to that wallet. If
the wallet has a network accessible tcp and/or UDP address it directs people
to that address (one port only, protocol negotiation will occur once the
connection is established, rather than protocols being defined by the port
number). If not, will direct them to a UDT4 rendezvous server, probably itself.

We probably need to support [uTP for the background download of bulk data].
This also supports rendezvous routing, though perhaps in a different and
incompatible way, excessively married to the bittorrent protocol.We might
find it easier to construct our own throttling mechanism in QUIC,
accumulating the round trip time and square of the round trip time excluding
outliers, to form a short term and long term average and variance of the
round trip time, and throttling lower priority bulk downloads and big
downloads when the short term average rises above the long term average by
more than the long term variance. The long term data is zeroed when the IP
address of the default gateway(router) is acquired, and is timed out over a
few days. It is also ceilinged at a couple of seconds.

[uTP for the background download of bulk data]: https://github.com/bittorrent/libutp

In this day and age, a program that lives only on one machine really is not
much of a program, and the typical user interaction is a user driving a gui
on one machine which is a gui to program that lives on a machine a thousand
miles away.

We have a problem with the name system, the system for obtaining network
addresses, in that the name system is subject to centralized state control,
and the TCP-SSL system is screwed by the state, which is currently seizing
crimethink domain names, and will eventually seize untraceable crypto
currency domain names.

In today’s environment, it is impossible to speak the truth under one’s true
name, and dangerous to speak the truth even under any durable and widely used
identity. Therefore, people who post under names tend to be unreliable.
Hence the term “namefag”. If someone posts under his true name, he is a
“namefag” – probably unreliable and lying. Even someone who posts under a
durable pseudonym is apt show excessive restraint on many topics.

The aids virus does not itself kill you. The aids virus “wants” to stick
around to give itself lots of opportunities to infect other people, so wants
to disable the immune system for obvious reasons. Then, without a immune
system, something else is likely to kill you.

When I say “wants”, of course the aids virus is not conscious, does not
literally want anything at all. Rather, natural selection means that a virus
that disables the immune system will have opportunities to spread, while a
virus that fails to disable the immune system only has a short window of
opportunity to spread before the immune system kills it, unless it is so
virulent that it likely kills its host before it has the opportunity to
spread.

Similarly, a successful memetic disease that spreads through state power,
through the state system for propagation of official truth “wants” to disable
truth speaking and truth telling – hence the replication crisis, peer
review, and the death of science. We are now in the peculiar situation that
truth is best obtained from anonymous sources, which is seriously suboptimal.
Namefags always lie. The drug companies are abandoning drug development,
because science just does not work any more. No one believes their research,
and they do not believe anyone else’s research.

It used to be that there were a small number of sensitive topics, and if you
stayed away from those, you could speak the truth on everything else, but now
it is near enough to all of them that it might as well be all of them, hence
the replication crisis. Similarly, the aids virus tends to wind up totally
suppressing the immune system, even though more selective shutdown would
serve its interests more effectively, and indeed the aids virus starts by
shutting down the immune system in a more selective fashion, but in the end
cannot help itself from shutting down the immune system totally.

The memetic disease, the demon, does not “want” to shut down truth telling
wholesale. It “wants” to shut down truth telling selectively, but inevitably,
there is collateral damage, so it winds up shutting down truth telling
wholesale.

To exorcise the demon, we need a prophet, and since the demon occupies the
role of the official state church, we need a true king. Since there is a
persistent shortage of true Kings, I here speaking as engineer rather than a
prophet, so here I am discussing the anarcho agorist solution to anarcho
tyranny, the technological solution, not the true king solution.

Because of the namefag problem and the state snatching domain names, we need,
in order to operate an untraceable blockchain based currency not only a
decentralized system capable of generating consensus on who owns what cash,
we need a system capable of generating consensus on who who owns which human
readable globally unique names, and the mapping between human readable names,
Zooko triangle names (which correspond to encryption public keys), and
network addresses, a name system resistant to the state’s attempts to link
names to jobs, careers, and warm bodies that can be beaten up or imprisoned,
to link names to property, to property that can be confiscated or destroyed.

A transaction output can hold an amount of currency, or a minimum amount of
currency and a name. Part of the current state, which every block contains,
is unused transaction outputs sorted by name.

If we make unused transaction outputs sorted by name available, might as well
make them available sorted by key.

In the hello world system, we will have a local database mapping names to
keys and to network addresses. In the minimum viable product, a global
consensus database. We will, however, urgently need a rendezvous system that
allows people to set up wallets and peers without opening ports on stable
network address to the internet. Arguably, the minimum viable product will
have a global database mapping between keys and names, but also a nameserver
system, wherein a host without a stable network address can login to a host
with a stable network address, enabling rendezvous. When one identity has its
name servers registered in the global consensus database, it always tries to
login to those and keep the connection alive with a ping that starts out
frequent, and then slows down on the Fibonacci sequence, to one ping every
1024 secondsplus a random number modulo 1024 seconds. At each ping, tells the
server when the next ping coming, and if the server does not get the
expected ping, server sends a nack. If the server gets no ack, logs the
client out. If the client gets no ack, retries, if still no ack, tries to
login to the next server.

In the minimum viable product, we will require everyone operating a peer
wallet to have a static IP address and port forwarding for most functionality
to work, which will be unacceptable or impossible for the vast majority of
users, though necessarily we will need them to be able to receive money
without port forwarding, a static IP, or a globally identified human readable
name, by hosting their client wallet on a particular peer. Otherwise no one
could get crypto currency they would need to set up a peer.

Because static IP is a pain, we should also support nameserver on the state
run domain name system, as well as nameserver on our peer network, but that
can wait a while. And in the end, when we grow so big that every peer is
itself a huge server farm, when we have millions of users and a thousand or
so peers, the natural state of affairs is for each peer to have a static IP.

Eventually we want people to be able to do without static IPs and
portforwarding, which is going to require a UDP layer. One the other hand, we
only intend to have a thousand or so full peers, even if we take over and
replace the US dollar as the world monetary system. Our client wallets are
going to be the primary beneficiaries of rendevous UDT4.8 routing over UDP.

We also need names that you can send money to, and name under which you can
receives. The current cryptocash system involves sending money to
cryptographic identifiers, which is a pain. We would like to be able to send
and receive money without relying on identifiers that look like line noise.

So we need a system similar to namecoin, but namecoin relies on proof of
work, rather than proof of share, and the state’s computers can easily mount
a fifty one percent attack on proof of work. We need a namecoin like system
but based on proof of share, rather than proof of work, so that for the state
to take it over, it would need to pay off fifty one percent of the
shareholders – and thus pay off the people who are hiding behind the name
system to perform untraceable crypto currency transactions and to speak the
unspeakable.

For anyone to get started, we are going to have to enable them to operate a
client wallet without IP and port forwarding, by logging on to a peer wallet.
The minimum viable product will not be viable without a client wallet that
you can use like any networked program. A client wallet logged onto a peer
wallet automatically gets the name `username.peername`. The peer could give
the name to someone else though error, malice or equipment failure, but the
money will remain in the client’s wallet, and will be spendable when he
creates another username with another peer. Money is connected to wallet
master secret, which should never be revealed to anyone, not with the
username. So you can receive money with a name associated an evil nazi
identity as one username on one peer, and spend it with a username associated
with a social justice warrior on another peer. No one can tell that both
names are controlled by the same master secret. You send money to a username,
but it is held by the wallet, in effect by the master secret, not by the
user name. That people have usernames, that money goes from one username to
another, makes transferring money easy, but by default the money goes through
the username to the master secret behind the quite discardable username,
thus becomes anonymous, not merely pseudonymous after being received. Once
you have received the money, you can lose the username, throw it away, or
suffer it being confiscated by the peer, and you, not the username, still
have the money. You only lose the money if someone else gets the master
secret.

You can leave the money in the username, in which case the peer hosting your
username can steal it, but for a hacker to steal it he needs to get your
master secret and logon password, or you transfer it to the master secret on
your computer, in which case a hacker can steal it, but the peer cannot, and
also you can spend it from a completely different username. Since most people
using this system are likely to be keen on privacy, and have no good reason
to trust the peer, the default will be for the money to go from the username
to the master secret.

Transfers of money go from one username to another username, and this is
visible to the person who sent it and the person who received it, but if the
transfer is to the wallet and the master secret behind the username, rather
than to the username, this is not visible to the hosts. Money is associated
with a host and this association is visible, but it does not need to be the
same host as your username. By default, money is associated with the host
hosting the username that receives it, which is apt to give a hint to which
username received it, but you can change this default. If you are receiving
crypto currency under one username, and spending it under another username on
another host, it is apt to be a good idea to change this default to the host
that is hosting the username that you use for spending, because then spends
will clear more quickly. Or if both the usernames and both the hosts might
get investigated by hostile people, change the default to a host that is
hosting your respectable username that you do not use much.

We also need a state religion that makes pretty lies low status, but that is
another post.

#True Names and TCP

Vernor Vinge [made the point](http://www.amazon.com/True-Names-Opening-Cyberspace-Frontier/dp/0312862075) that true names are an instrument of
government oppression. If the government can associate your true name
with your actions, it can punish you for those actions. If it can find the true
names associated with a transaction, it is a lot easier to tax that transaction.

Recently there have been moves to make your cell phone into a wallet. A
big problem with this is that cell phone cryptography is broken. Another
problem is that cell phones are not necessarily associated with true names,
and as soon as the government hears that they might control money, it
starts insisting that cell phones *are* associated with true names. The phone
companies don’t like this, for if money is transferred from true name to
true name, rather than cell phone to cell phone, it will make them a servant
of the banking cartel, and the bankers will suck up all the gravy, but once
people start stealing money through flaws in the encryption, they will be
depressingly grateful that the government can track account holders down
and punish them – except, of course, the government probably will not be
much good at doing so.

TCP is all about creating connections.  It creates connections between
network addresses, but network addresses correspond to the way networks
are organized, not the way people are organized, so on top of networks we
have domain names.

TCP therefore establishes a connection *to* a domain name rather than a
mere network address – but there is no concept of the connection coming
*from* anywhere humanly meaningful.

Urns are “uniform resource names”, and uris are “uniform resource identifiers” and urls are “uniform resource locators”, and that is what the
web is built out of. 

There are several big problems with urls:

1. They are uniform: Everyone is supposed to agree on one domain
   name for one entity, but of course they don’t.  There is honest and
   reasonable disagreement as to which jim is the “real” jim, because
   in truth there is no one real jim, and there is fraud, as in lots of
   people pretending to be Paypal or the Bank of America, in order to
   steal your money.

2. They are resources: Each refers to only a single interaction, but of
   course relationships are built out of many interactions.  There is no
   concept of a connection continuing throughout many pages, no
   concept of logon.  In building urls on top of TCP, we lost the
   concept of a connection.  And because urls are built out of TCP
   there is no concept of the content depending on both ends of the
   connection – that a page at the Bank might be different for Bob than
   it is for Carol – that it does in reality depend on who is connected is
   a kluge that breaks the architecture.

   Because security (ssl, https) is constructed below the level of a
   connection, because it lacks a concept of connection extending
   beyond a single page or a single url, a multitude of insecurities
   result. We want https and ssl to secure a connection, but https and
   ssl do not know there are such things as logons and connections.

That domain names and hence urls presuppose agreement, agreement
which can never exist, we get cybersquatting and phishing and
suchlike.

That connections and logons exist, but are not explicitly addressed by the
protocol leads to such attacks as cross site scripting and session fixation.

A proposed fix for this problem is yurls, which apply Zooko’s triangle to
the web: One adds to the domain name a hash of a rule for validating the
public key, making it into Zooko’s globally unique identifier.  The
nickname (non unique global identifier) is the web page title, and the
petname (locally unique identifier) is the title under which it appears in
your bookmark list, or the link text under which it appears in a web page.

This, however, breaks normal form.  The public key is an attribute of the
domain, while the nickname and petnames are attributes of particular web
pages – a breach of normal form related to the loss of the concept of
connection – a breach of normal form reflecting the fact that that urls
provide no concept of a logon, a connection, or a user.  

OK, so much for “uniform”.  Instead of uniform identifiers, we should
have zooko identifiers, and zooko identifiers organized in normal form.
But what about “resource”, for “resource” also breaks normal form.

Instead of “resources”, we should have “capabilities”.  A resource
corresponds to a special case of a capability, a resource is a capability
that that resembles a read only file handle. But what exactly are "capabilities”?

People with different concepts about what is best for computer security
tend to disagree passionately and at considerable length about what the
word “capability” means, and will undoubtedly tell me I am a complete
moron for using it in the manner that I intend to use it, but barging ahead anyway:

A “capability” is an object that represents one end of a communication
channel, or information that enables an entity to obtain such a channel, or
the user interface representation of such a channel, or such a potential
channel. The channel enables the possessor of the capability to do stuff to
something, or get something.  Capabilities are usually obtained by being
passed along the communication channel. Capabilities are usually
obtained from capabilities, or inherited by a running instance of a program
 when the program is created, or read from storage after originally being
 obtained by means of another capability.

This definition leaves out the issue of security – to provide security,
capabilities need to be unforgeable or difficult to guess.  Capabilities are
usually defined with the security characteristics central to them, but I am
defining capabilities so that what is central is connections and managing
lots of potential connection.  Sometimes security and limiting access is a
very important part of management, and sometimes it is not.

A file handle could be an example of a capability – it is a communication
channel between a process and the file management system.  Suppose we
are focussing on security and access management to files: A file handle
could be used to control and manage permissions if a program that has the
privilege to access certain files could pass an unforgeable file handle to
one of those files to a program that lacks such access, and this is the only
way the less privileged program could get at those files.

Often the server wants to make sure that the client at one end of a
connection is the user it thinks it is, which fits exactly into the usual
definitions of capabilities.  But more often, the server does not care who
the client is, but the client wants to make sure that the server at the other
end of the connection is the server he thinks it is, which, since it is the
client that initiates the connection, does not fit well into many existing
definitions of security by capabilities.

# Mapping between globally unique human readable names and public keys

The blockchain provides a Merkle-patricia dac of human readable names. Each
human readable name links to a list of signatures transferring ownership form
one public key to the next, terminating in an initial assignment of the name
by a previous block chain consensus. A client typically keeps a few leaves
of this tree. A host keeps the entire tree, and provides portions of the tree
to each client.

When two clients link up by human readable name, they make sure that they are
working off the same early consensus, the same initial grant of user name by
an old blockchain consensus, and also off the same more recent consensus,
for possible changes in the public key that has rightful ownership of that
name. If they see different Merkle hashes at the root of their trees, the
connection fails. Thus the blockchain they are working from has to be the
same originally, and also the same more recently.

This system ensures we know and agree what the public key associated with a
name is, but how do we find the network address?

# Mapping between public keys and nework addresses

## The Nameserver System

Typically someone is logged in to a host with an identity that looks like an
email address, `paf.foo.bar`, where`bar` is the name of a host that is
reliably up, and reliably on the network, and relatively easy to find

You can ask the host `bar` for the public key and *the network address* of
`foo.bar`, or conversely the login name and network address associated with
this public key. Of course these values are completely subject to the caprice
of the owner of `bar`. And, having obtained the network address of `foo.bar`,
you can then get the network address of `paf.foo.bar`

Suppose someone owns the name `paf`, and you can find the global consensus as
to what public key controls `paf`, but he does not have a stable network
address. He can instead provide a nameserver – another entity that will
provide a rendevous. If `paf` is generally logged in to `foo`, you can
contact `foo`, to get rendevous data for `bar.foo`, which is, supposing `foo`
to be well behaved, rendevous data for `bar`

Starting from a local list of commonly used name server names, keys, and
network addresses, you eventually get a live connection to the owner of that
public key, who tells you that at the time he received your message, the
information is up to date, and, for any globally unique human readable names
involved in setting up the connection, he is using the same blockchain as you
are using.

Your local list of network addresses may well rapidly become out of date.
Information about network addresses flood fills through the system in the
form of signed assertions about network addresses by owners of public keys,
with timeouts on those assertions, and where to find more up to date
information if the assertion has timed out, but we do not attempt to create a
global consensus on network addresses. Rather, the authoritative source of
information about a network address of a public key comes from successfully
performing a live connection to the owner of that public key. You can, and
probably should, choose some host as the decider on the current tree of
network addresses, but we don’t need to agree on the host. People can work
off slightly different mappings about network addresses with no global and
complete consensus. Mappings are always incomplete, out of date, and usually
incomplete and out of date in a multitude of slightly different ways.

We need a global consensus, a single hash of the entire blockchain, on what
public keys own what crypto currency and what human readable names. We do not
need a global consensus on the mapping between public keys and network
addresses.

What you would like to get is an assertion that `paf.foo.bar` has public key
such and such, and whatever you need to make network connection to
`paf.foo.bar`, but likely `paf.foo.bar` has transient public key, because his
identity is merely a username and login at `foo.bar`, and transient network
address, because he is behind nat translation. So you ask `bar` about
`foo.bar`, and `foo.bar` about `paf.foo.bar`, and when you actually contact
`paf.foo.bar`, then, and only then, you know you have reliable information.
But you don’t know how long it is likely to remain reliable, though
`paf.foo.bar` will tell you (and no other source of information is
authoritative, or as likely to be accurate).

Information about the mapping between public keys and network addresses that
is likely to be durable flood fills through the network of nameservers.

# logon identity

Often, indeed typically, `ann.foo` contacts `bob.bar`, and `bob.bar` needs
continuity information, needs to know that this is truly the same `ann.foo`
as contacted him last time – which is what we currently do with usernames and
passwords.

The name `foo` is rooted in a chain of signatures of public keys and requires
a global consensus on that chain. But the name `ann.foo` is rooted in logon
on `foo`. So `bob.bar` needs to know that `ann.foo` can log on with `foo`,
which `ann.foo` does by providing `bob.bar` with a public key signed by `foo`,
which might be a transient public key generated the last time she logged
on, which will disappear the moment her session on her computer shuts down,
or might be a durable public key. But if it is a durable public key, this
does not give her any added security, since `foo` can always make up a new
public key for anyone he decides to call `ann.foo` and sign it, so he might
as well put a timeout on the key, and `ann.foo` might as well discard it when
her computer turns off or goes into sleep mode. So, it is in everyone’s
interests (except that of attackers) that only root keys are durable.

`foo`’s key is durable, and information about it is published.`ann.foo`’s
key is transient, and information about it always obtained directly from
`ann.foo` as a result of `ann.foo` logging in with someone, or as a result of
someone contacting `foo` with the intent of logging in to `ann.foo`.

But suppose, as is likely, the network address of `foo` is not actually all
that durable, is perhaps behind a NAT. In that case, it may well be that to
contact `foo`, you need to contact `bar`.

So, `foo!bar` is `foo` logged in on `bar`, but not by a username and
password, but rather logged on by his durable public key, attested by the
blockchain consensus. So, you get an assertion, flood filled through the
nameservers, that the network address of the public key that the blockchain
asserts is the rightful controller of `foo`, is likely to be found at `foo!`
(public key of `bar`), or likely to be found at `foo!bar`.

Logons by durable public key will work exactly like logons by username and
password, or logons by derived name. It is just that the name of the entity
logged on has a different form..

Just as openssh has logons by durable public key, logons by public key
continuity, and logons by username and password, but once you are logged on,
it is all the same, you will be able to logon to `bob.bar` as `ann.bob.bar`,
meaning a username and password at `bob.bar`, as `ann.foo`, meaning `ann` has
a single signon at `foo`, a username and password at `foo`, or as `ann`,
meaning `ann` logs on to `bob.bar` with a public key attested by the
blockchain consensus as belonging to `ann`.

And if `ann` is currently logged on to `bob.bar` with a public key attested
by the blockchain consensus as belonging to `ann`, you can find the current
network address of `ann` by asking `bob.bar` for the network address of
`ann!bob.bar`

`ann.bob.bar` is whosoever `bob.bar` decides to call `ann.bob.bar`, but
`ann!bob.bar` is an entity that controls the secret key of `ann`, who is at
this moment logged onto `bob.bar`.

If `ann` asserts her current network address is likely to last a long time,
and is accessible without going through

`bob.bar` then that network address information will flood fill through the
network. Less useful network address information, however will not get far.