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.
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 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:
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.
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.
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?
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.
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.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.