Our immediate objective, in the minimum viable product, is that peers should be able to talk to each other to reach a consensus on who owns what coin, and clients should be able to connect to peers, should be hosted by peers, to get information about the consensus, to pay each other, and to communicate bills and contracts to each other.</p><p>
Our ultimate objective is to replace the existing centralized internet name system, but for starters, just have a name system so that clients can make payments to entities identified by name.</p><p>
We want our minimum viable system to be compatible with a future system where you can sign up with a host by giving it a name analogous to an email address, a name at which you can be contacted, and then the host contacts your client program on that machine on that machine, the client says "do you want to sign up", and thereafter you have automatic sign in with your client and a bookmark for that host on your client. Also the host can send you messages, and these messages can contain links that have the same effect as that bookmark link, except that the host knows what message you are responding to. But that is future compatibility that the minimum viable system needs to be compatible with, not what the minimum viable product will implement.</p><p>
The minimum viable product will implement a subset of that as necessary for the payment system, capable of being compatibly extended to that in future.</p>
<h2>Binary</h2><p>
Protocol negotiation tends to get broken, making future changes in protocol hard. To prevent this from happening the minimum viable product will have several different protocols so that protocol negotiation can be part of unit test from day one, though the initial protocols will be trivially different from each other, differing only in that different values will be xored into the fields, and the fields will not necessarily be in the same order.</p><p>
Two entities will set up a data structure containing a strong shared secret, and estimates of pipe length and width. This data structure will persist for a long time – a month or so, or until one of the entities reboots or changes its network address. Any number of connections can be opened or closed under that master secret, and these connections will frequently be very short lived, often enduring only for a single request, followed by a single response.</p><p>
The client will obtain the hostname, the host network address, usually a host port, and usually a host public key, and network address public key, and the host preferred protocol (which in the minimum viable product will always be 2654435769-2 except during unit test)
To set up a connection, it will send in the clear one or more protocol identifiers, each represented by a thirty two bit number of order 2<sup>31</sup>
For each protocol identifiers, there will be a range of acceptable sub protocols, represented by two 8 bit numbers. The preferred protocol is the highest numbered sub protocol of the first major protocol identifiers.
In the minimum viable product, the two recognized protocols will 2654435769 and 1013904242, each of which will have the subprotocols 0, 1, and 2.
During unit test some of these protocols will be disabled to test protocol negotiation, but normally the client will always request 2654435769,0,3, meaning that protocol 2654435769-2 is desired, but protocol 2654435769-0 and 2654435769-1 is acceptable.
The client will optimistically assume that 2654435769-2 will be accepted, and send a fresh random new public key encoded in accordance with 2654435769-2, and the public key identifier for the network address, identified in accordance 2654435769-2, and its local steady time in milliseconds.
Using the shared secret generated from these public keys, will encrypt the desired protocol, the host name it wishes to contact, and the expected public key identifier of that host. Using the shared secret generated using public key of the host name, will encrypt the connection request.
However, the network address may not like the request – perhaps something has changed, or perhaps it has too many requests.
It will then send a protocol request, a public key, and, optionally, a proof of work request.
In which case the network address will send a proof of work request. It also informs the client of the public key associated with the network address, if need be.
The task to be performed is to find three small values that when hashed with the ninety six bit value, have their last few bits agreeing with each other. The difficulty is indicated by a small integer, representing the number of bits that must agree.
The client has to generate a large number of such hashes, sort them in accordance with their last few bits, and find a run of the requisite length.
The client then repeats the request, but this time with proof of work and and the proof of work request.
Having – eventually – obtained a shared secret with the network address, it then obtains a shared secret with the hostname.
This shared secret is identified by a thirty two bit number. All subsequent requests to set up a connection quote this number to identify the shared secret under whitch the connection will be setup.
The public key of the network address is not subsequently used – it is just used to hide the public key and hostname. There may be more than one hostname behind a network address.
OK, the client knows it is talking to the correct hostname, because the database links human readable names to Zooko names.
They have also agreed on a protocol, which gives them a protocol for further protocol negotiation.
But what does the host know about the client.
<pstyle="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <ahref="http://creativecommons.org/licenses/by-sa/3.0/"rel="license">Creative
