wallet/docs/name_system.md

---
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 rendevous server, probably itself.

We probably need to support [uTP for the background download of bulk data].
This also supports rendevous 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 stake, 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 stake, 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
stakeholders – 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.

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