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.

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, wherebar 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.