cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Checking in html files

Browse Source
This commit is contained in:
reaction.la 2022-02-18 13:33:27 +10:00
parent 90465409f0
commit e49662106b
No known key found for this signature in database
GPG Key ID: 99914792148C8388
67 changed files with 7220 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
.gitconfig
View File

@ -1,29 +1,32 @@
[core]
autocrlf = input
whitespace = trailing-space,space-before-tab,tabwidth=4
whitespace = -tab-in-indent,tabwidth=4,indent-with-non-tab,trailing-space,space-before-tab
safecrlf
[apply]
whitespace = fix
ignoreWhitespace = no
[alias]
lg = log --reverse --max-count=4 --oneline --pretty='format:%C(yellow)%h %d %Creset%p %C("#60A0FF")%cr %Cgreen %cn %GT trust%Creset%n%s%n'
graph = log --max-count=20 --graph --pretty=format:'%C(yellow)%h%Creset %s %Cgreen(%cr) %C(bold blue)%cn %GT%Creset' --abbrev-commit
lg = log --max-count=6 --oneline --pretty='format:%C(auto)%h %d %Creset%p %C("#60A0FF")%cr %Cgreen %cn %G? %GT trust%Creset%n%s%n'
graph = log --max-count=18 --graph --pretty=format:'%C(auto)%h %s %Cgreen(%cr) %C(bold blue)%cn %G?%Creset' --abbrev-commit
alias = ! git config --get-regexp ^alias\\. | sed -e s/^alias\\.// -e s/\\ /\\ =\\ / | grep -v ^'alias ' | sort
fixws = !"\
if (! git diff-files --quiet .) && \
(! git diff-index --quiet --cached HEAD) ; then \
git commit -m FIXWS_SAVE_INDEX && \
git add -u :/ && \
git commit -m FIXWS_SAVE_TREE && \
git rebase --whitespace=fix HEAD~2 && \
git reset HEAD~ && \
git reset --soft HEAD~ ; \
elif (! git diff-files --quiet .) ; then \
git add -u :/ && \
git commit -m FIXWS_SAVE_TREE && \
git rebase --whitespace=fix HEAD~ && \
git reset HEAD~ ; \
an elif (! git diff-index --quiet --cached HEAD) ; then \
git commit -m FIXWS_SAVE_INDEX && \
git rebase --whitespace=fix HEAD~ && \
git reset --soft HEAD~ ; \
fi"
if (! git diff-files --quiet .) && \
(! git diff-index --quiet --cached HEAD) ; then \
git commit -m FIXWS_SAVE_INDEX && \
git add -u :/ && \
git commit -m Fix_whitespace && \
git rebase --whitespace=fix HEAD~2 && \
git reset HEAD~ && \
git reset --soft HEAD~ ; \
elif (! git diff-files --quiet .) ; then \
git add -u :/ && \
git commit -m Fix_whitespace && \
git rebase --whitespace=fix HEAD~ && \
git reset HEAD~ ; \
elif (! git diff-index --quiet --cached HEAD) ; then \
git commit -m FIXWS_SAVE_INDEX && \
git rebase --whitespace=fix HEAD~ && \
git reset --soft HEAD~ ; \
fi"
[commit]
gpgSign = true

65
LICENSE.html Normal file
View File

@ -0,0 +1,65 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>LICENSE</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="docs/pandoc_templates//style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
border: 1px solid #999;
padding: 0.5rem;
text-align: left;
}
h1.title{
text-align: center; font-size: xxx-large;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<header id="title-block-header">
<h1 class="title">LICENSE</h1>
</header>
<p>Copyright © 2021 reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F</p>
<p>This distribution of free software contains numerous other
distributions with other compatible free software licenses and copyrights.
Those files and directories are governed by their own license, and their
combination and integration into this project by this license and this
copyright, and anything in this distribution not otherwise licensed and
copyrighted in this distribution is governed by this license, and this
copyright.</p>
<p>Licensed under the Apache License, Version 2.0 (the “License”);
you may not use this distribution of software except in compliance with the License.
You may obtain a copy of the License at
<a href="https://directory.fsf.org/wiki/License:Apache-2.0" class="uri">https://directory.fsf.org/wiki/License:Apache-2.0</a></p>
<p>Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.</p>
</body>
</html>

64
NOTICE.html Normal file
View File

@ -0,0 +1,64 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>NOTICE</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="docs/pandoc_templates//style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
border: 1px solid #999;
padding: 0.5rem;
text-align: left;
}
h1.title{
text-align: center; font-size: xxx-large;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<header id="title-block-header">
<h1 class="title">NOTICE</h1>
</header>
<p>Copyright © 2021 reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F</p>
<p>The license of this software, and the licenses of the packages on which it
relies, grant the four software freedoms:</p>
<ol start="0" type="1">
<li>The freedom to run the program as you wish, for any purpose.</li>
<li>The freedom to study how the program works, and change it so it
does your computing as you wish.</li>
<li>The freedom to redistribute copies so you can help others.</li>
<li>The freedom to distribute copies of your modified versions to
others.</li>
</ol>
<p>This software is licensed under the <a href="LICENSE.html">apache 2.0 license</a>.</p>
<p>This product includes several packages, each with their own free software licence, referenced in the relevant files or subdirectories.</p>
<p>Or, in the case of Sqlite, the Sqlite blessing in place of a license, which is
morally though not legally obligatory on those that obey the
commandments of Gnon. See also the <a href="docs/contributor_code_of_conduct.html">contributor code of conduct</a>.</p>
</body>
</html>

173
README.html Normal file
View File

@ -0,0 +1,173 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>README</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
pre > code.sourceCode { white-space: pre; position: relative; }
pre > code.sourceCode > span { display: inline-block; line-height: 1.25; }
pre > code.sourceCode > span:empty { height: 1.2em; }
.sourceCode { overflow: visible; }
code.sourceCode > span { color: inherit; text-decoration: inherit; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
pre > code.sourceCode { white-space: pre-wrap; }
pre > code.sourceCode > span { text-indent: -5em; padding-left: 5em; }
}
pre.numberSource code
{ counter-reset: source-line 0; }
pre.numberSource code > span
{ position: relative; left: -4em; counter-increment: source-line; }
pre.numberSource code > span > a:first-child::before
{ content: counter(source-line);
position: relative; left: -1em; text-align: right; vertical-align: baseline;
border: none; display: inline-block;
-webkit-touch-callout: none; -webkit-user-select: none;
-khtml-user-select: none; -moz-user-select: none;
-ms-user-select: none; user-select: none;
padding: 0 4px; width: 4em;
color: #aaaaaa;
}
pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa; padding-left: 4px; }
div.sourceCode
{ }
@media screen {
pre > code.sourceCode > span > a:first-child::before { text-decoration: underline; }
}
code span.al { color: #ff0000; font-weight: bold; } /* Alert */
code span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */
code span.at { color: #7d9029; } /* Attribute */
code span.bn { color: #40a070; } /* BaseN */
code span.bu { } /* BuiltIn */
code span.cf { color: #007020; font-weight: bold; } /* ControlFlow */
code span.ch { color: #4070a0; } /* Char */
code span.cn { color: #880000; } /* Constant */
code span.co { color: #60a0b0; font-style: italic; } /* Comment */
code span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */
code span.do { color: #ba2121; font-style: italic; } /* Documentation */
code span.dt { color: #902000; } /* DataType */
code span.dv { color: #40a070; } /* DecVal */
code span.er { color: #ff0000; font-weight: bold; } /* Error */
code span.ex { } /* Extension */
code span.fl { color: #40a070; } /* Float */
code span.fu { color: #06287e; } /* Function */
code span.im { } /* Import */
code span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */
code span.kw { color: #007020; font-weight: bold; } /* Keyword */
code span.op { color: #666666; } /* Operator */
code span.ot { color: #007020; } /* Other */
code span.pp { color: #bc7a00; } /* Preprocessor */
code span.sc { color: #4070a0; } /* SpecialChar */
code span.ss { color: #bb6688; } /* SpecialString */
code span.st { color: #4070a0; } /* String */
code span.va { color: #19177c; } /* Variable */
code span.vs { color: #4070a0; } /* VerbatimString */
code span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="docs/pandoc_templates//style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
border: 1px solid #999;
padding: 0.5rem;
text-align: left;
}
h1.title{
text-align: center; font-size: xxx-large;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<header id="title-block-header">
<h1 class="title">README</h1>
</header>
<p><a href="docs/index.htm">pre alpha documentation (mostly a wish list)</a></p>
<p><a href="./license.txt">copyright © and license</a></p>
<p>pre-requisite, Pandoc to build the html documentation from the markdown files.</p>
<p>Windows pre-requisites: Visual Studio and git-bash</p>
<p>To obtain the source code from which the project can be built, including
this README, from the bash command line (git-bash in windows).</p>
<pre class="bash2"><code>git clone missing url
cd wallet
./winConfigure.sh</code></pre>
<p>To configure and build the required third party libraries in windows, then
build the program and run unit test for the first time, launch the Visual
Studio X64 native tools command prompt in the cloned directory, then:</p>
<pre class="bat"><code>winConfigure.bat</code></pre>
<p>winConfigure.bat also configures the repository you just created to use
<<<<<<< HEAD
<code>.gitconfig</code> in the repository, causing git to rquire to implement gpg signed
commits – because cryptographic software is under attack from NSA,
entryists, and shills, who seek to introduce backdoors.</p>
<p>This may be inconvenient if you do not have gpg installed and set up.</p>
<p>It adds several git aliases:</p>
<ol type="1">
<li><code>git lg</code> to display the gpg trust information for the las three commits.
For this to be useful you need to import the repository public key
public_key.gpg` into gpg, and locally sign that key.</li>
<li><code>git fixws</code> to standardise white space to the project standards</li>
<li><code>git graph</code> to graph the commit tree, and git alias to display the git aliases.</li>
=======
<code>.gitconfig</code> in the repository, causing git to require to implement GPG signed
commits – because <a href="./docs/contributor_code_of_conduct.html#code-will-be-cryptographically-signed" target="_blank" title="Contributor Code of Conduct">cryptographic software is under attack</a> from NSA
entryists, and shills, who seek to introduce backdoors.</p>
<p>This may be inconvenient if you do not have <code>gpg</code> installed and set up.</p>
<p><code>.gitconfig</code> adds several git aliases:</p>
<ol type="1">
<li><code>git lg</code> to display the gpg trust information for the last four commits.
For this to be useful you need to import the repository public key
<code>public_key.gpg</code> into gpg, and locally sign that key.</li>
<li><code>git fixws</code> to standardise white space to the project standards</li>
<li><code>git graph</code> to graph the commit tree</li>
<li><code>git alias</code> to display the git aliases.</li>
>>>>>>> origin/master
</ol>
<div class="sourceCode" id="cb3"><pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="co"># To verify that the signature on future pulls is unchanged. </span></span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="ex">gpg</span> <span class="at">--import</span> public_key.gpg</span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a><span class="ex">gpg</span> <span class="at">--lsign</span> 096EAE16FB8D62E75D243199BC4482E49673711C</span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="co"># We ignore the Gpg Web of Trust model and instead use</span></span>
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a><span class="co"># the Zooko identity model. </span></span>
<span id="cb3-6"><a href="#cb3-6" aria-hidden="true" tabindex="-1"></a><span class="co"># We use Gpg signatures to verify that remote repository</span></span>
<span id="cb3-7"><a href="#cb3-7" aria-hidden="true" tabindex="-1"></a><span class="co"># code is coming from an unchanging entity, not for</span></span>
<span id="cb3-8"><a href="#cb3-8" aria-hidden="true" tabindex="-1"></a><span class="co"># Gpg Web of Trust. Web of Trust is too complicated</span></span>
<span id="cb3-9"><a href="#cb3-9" aria-hidden="true" tabindex="-1"></a><span class="co"># and too user hostile to be workable or safe.</span></span>
<span id="cb3-10"><a href="#cb3-10" aria-hidden="true" tabindex="-1"></a><span class="co"># Never --sign any Gpg key related to this project. --lsign it.</span></span>
<span id="cb3-11"><a href="#cb3-11" aria-hidden="true" tabindex="-1"></a><span class="co"># Never check any Gpg key related to this project against a</span></span>
<span id="cb3-12"><a href="#cb3-12" aria-hidden="true" tabindex="-1"></a><span class="co"># public gpg key repository. It should not be there.</span></span>
<span id="cb3-13"><a href="#cb3-13" aria-hidden="true" tabindex="-1"></a><span class="co"># Never use any email address on a gpg key related to this project</span></span>
<span id="cb3-14"><a href="#cb3-14" aria-hidden="true" tabindex="-1"></a><span class="co"># unless it is only used for project purposes, or a fake email,</span></span>
<span id="cb3-15"><a href="#cb3-15" aria-hidden="true" tabindex="-1"></a><span class="co"># or the email of someone whom you do not like.</span></span></code></pre></div>
<p>To build the documentation in its intended html form from the markdown
files, execute the bash script file <code>docs/mkdocs.sh</code>, in an environment where
<code>pandoc</code> is available. On Windows, if Git Bash and Pandoc has bee
installed, you should be able to run a shell file in bash by double clicking on it.</p>
<p><a href="./RELEASE_NOTES.html">Pre alpha release</a>, which means it does not yet work even well enough for
it to be apparent what it would do if it did work.</p>
</body>
</html>

2
README.md
View File

@ -67,7 +67,7 @@ gpg --lsign 096EAE16FB8D62E75D243199BC4482E49673711C
To build the documentation in its intended html form from the markdown
files, execute the bash script file `docs/mkdocs.sh`, in an environment where
`pandoc` is available. On Windows, if Git Bash and Pandoc has bee
`pandoc` is available. On Windows, if Git Bash and Pandoc has been
installed, you should be able to run a shell file in bash by double clicking on it.
[Pre alpha release](./RELEASE_NOTES.html), which means it does not yet work even well enough for

51
RELEASE_NOTES.html Normal file
View File

@ -0,0 +1,51 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Release Notes</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="docs/pandoc_templates//style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
border: 1px solid #999;
padding: 0.5rem;
text-align: left;
}
h1.title{
text-align: center; font-size: xxx-large;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<header id="title-block-header">
<h1 class="title">Release Notes</h1>
</header>
<p>To build and run <a href="./README.html">README</a></p>
<p><a href="docs/index.htm">pre alpha documentation (mostly a wish list)</a></p>
<p>This software is pre alpha and should not yet be released. It does not work well enough to even show what it would do if it was working</p>
</body>
</html>

40
docs/Massive_Parallelism.html Normal file
View File

@ -0,0 +1,40 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Massive Parallelism</title>
</head>
<body><p>
Digital Ocean, Docker, microservices, Rest, Json and protocol buffers.</p><p>
The world is drifting towards handling massive parallelism through https microservices.</p><p>
Typically you have an nginx reverse proxy distributing https requests to a swarm of docker instances of node.js</p><p>
These communicate by rest, which means that http get and post map to wrapped database operations. On the wire the data is represented as JSON, protocol buffers, or ASN.1.</p><p>
JSON being by far the most popular, despite its inefficiency. It is a strictly text format, that is in principle human readable, though YAML is JSON variant that is far more human readable.</p><p>
Numerous docker instances keep in agreement through the Mongo database, which handles the syncrhonization of massive parallelism, possibly through a sharded cluster. Mongo communicates in binary, but everyone wants to talk to it in JSON, so it has a sort of bastard binary JSON, and can also talk real JSON.</p><p>
The great use of Mongo is coordinating numerous instances, which rapidly runs into scaling problems. Mongo is shardable, albeit sharding it is non trivial.</p><p>
Each instance of these massively parallel applications are contained in docker containers, which are themselves contained in VMs. A docker container is a sort of lightweight VM, which always represents a live, fully configured, running machine, which provides various services over the network, and any permanent effects are stored on a database that is apt to be external to the docker container, so that the virtual machine can be casually destroyed and restarted.</p><p>
To provide private keys to the docker container, have a volume that only one local user has access to, and mount it to the docker container. It then uses that key to get all the other secret keys, possibly by using crypt. But this seems kind of stupid. How about it generates its own unique private key, and then gets that key blessed – in the process of accepting the authority of the blessing key.</p><p>
When launched, hits up a service to get its key blessed and register its availability, and thereafter accepts whatever commands are issued on the key chain issued when first it showed up.
</p><p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

195
docs/May_scale_of_monetary_hardness.html Normal file
View File

@ -0,0 +1,195 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
.center {text-align:center}
.red{color:#BF0000; background-color:#FFFFFF;}
.green{color:#00C000; background-color:#FFFFFF;}
body{color:#000000; background-color:#FFFFFF;}
</style>
<link rel="shortcut icon" href="../rho.ico"><title>May scale of monetary hardness</title>
</head>
<body>
<h1>May scale of monetary hardness</h1>
<p><a href="./index.html"> To Home page</a> </p>
<p>
J.C. May defined the following scale of monetary hardness.
The following is mostly his words, edited to bring them up to
date.</p>
<table border="1" cellpadding="6" cellspacing="0" width="95%">
<tbody>
<tr>
<td colspan="2" style="background-color: #99CC66;
text-align:center;">May Scale of monetary hardness </td>
</tr>
<tr>
<td style="text-align:center;"><b> Hardness</b> </td>
<td> <br/>
</td>
</tr>
<tr>
<td colspan="2" style=" text-align:center;">Hard</td>
</tr>
<tr>
<td class="center"><b>1</b></td>
<td>Street cash, US dollars</td>
</tr>
<tr>
<td class="center"><b>2</b></td>
<td>Street cash, euro currencies, japan</td>
</tr>
<tr>
<td class="center"><b>3</b></td>
<td>Major crypto currencies, such as Bitcoin and Monaro</td>
</tr>
<tr>
<td class="center"><b>4</b></td>
<td>Street cash, other regions</td>
</tr>
<tr>
<td class="center"><b>5</b></td>
<td>Interbank transfers of various sorts (wires etc),
bank checks</td>
</tr>
<tr>
<td class="center"><b>6</b></td>
<td>personal checks</td>
</tr>
<tr>
<td class="center"><b>7</b>
</td>
<td>Consumer-level electronic account transfers (eg
bPay)</td>
</tr>
<tr>
<td class="center"><b>8</b></td>
<td>Business-account-level retail transfer systems</td>
</tr>
<tr>
<td colspan="2" style=" text-align:center;">Soft</td>
</tr>
<tr>
<td class="center"><b>9</b></td>
<td>Paypal and similar 'new money' entities, beenz</td>
</tr>
<tr>
<td class="center"><b>10</b></td>
<td>Credit cards</td>
</tr>
</tbody>
</table>
<h2 class="green">Three essays from different periods follow</h2>
<hr><p>Observe that say stock brokerages definitely do not accept credit cards or
paypal to fund an account. They will only accept instruments that are very hard,
such as wire transfers or certified bank checks.</p><p>
When hard money is required, only money-types with a hardness of about 5
or better will do the job.</p><p>
On the other hand, if you're purchasing an online subscription, or
consumer goods from a large retailer, softer money-types are more acceptable.</p><p>
When dealing with conversions <b>between</b> different types of money,
generally you can only go "downwards" on the May scale.</p><p>
Thus, for example it is very easy to accept cash-dollars, and handout
paypal-dollars in return. But it would be almost impossible to accept credit cards or
paypal-dollars,and hand out cash in return.</p>
<hr/>
<p><em>It is extremely significant that <b>individuals</b> tend to require harder money in their transactions.</em></p><p>
Corporations and large bodies <b>can get away with</b> using softer money, as they have more political (in the broad sense) power to affect the outcome of dubious or revoked transactions.</p><p>
For instance, selling you a car, I could only trust you if you pay me
with a hard money. Say, no softer than 5 on the may scale.
No-one takes a personal check when selling a car.</p><p>
A car dealership, though, can trust you with somewhat softer money .. say up to 7/8 on the May scale (they probably would not take credit cards, though).</p><p>
WalMart can trust you all the way through to 10 when you buy goods at WalMart. (WalMart have more political recourse if a payment repudiates.)</p><p>
<b>We are entering the age of the "sovereign individual" where individuals will have ever-more power.</b> More and more, individuals will be able to behave in ways previously reserved for large government or corporate entities. More and more, individuals will be able to fulfill functions previously dominated by large government or corporate entities.</p><p>
For instance, it would have been in inconceivable in <b>1900</b> for one individual to, say, set up and operate a stock market. That would be and could only be the work of a large, powerful, social-political-corporate group.</p><p>
However in <b>2000</b>, one individual could completely program and operate stock market with a few hours programming and a web site.</p><p>
Money systems that are higher up on the may scale are <b>more suitable for individuals</b>.</p><p>
As we move more and more into the age of the "sovereign individual", where individuals will replace many of the functions of corporate/government entities, <b>there will be more and more demand for money systems that are higher-up on the may scale</b>.</p>
<p class="green"> The above essay turned out to be optimistic, but a successor to bitcoin may accomplish what e-gold failed to accomplish.
<hr>
<p class="green">
Original (oldest) essay, where Tim May first proposed the May Scale of Monetary Hardness:<br/>
This essay was written in the time when e-gold appeared to be successful. E-gold attempted to do what Bitcoin is attempting to, and failed. Bitcoin was inspired in substantial part to fix the problems that killed e-gold. The centralized single-point-of-failure ledgers of e-gold came under attack by the state, by scammers, and by state backed scammers.</p>
<pre>
&gt;Your question provokes us to focus on a major factor inhibiting the growth
&gt;of e-gold – that there’s no common way now to put money into an account fast
&gt;(as in a matter of minutes instead of hours or more likely, days and weeks).
&gt;An ironic situation, considering that e-gold is destined for greatness as
&gt;the currency of the internet.
</pre><p>
It’s worth noting that funding – say – a trading account with your
stock broker is just as "difficult" as buying e-gold. </p><p>
For that matter, funding a new BANK ACCOUNT is just as difficult as
buying e-gold.</p><p>
When you open a stock broking account at etrade or whatever, you
certainly cannotget funds there instantly – your options are wire
and wait days, bank check or cashier’s check and wait a week or a
personal check and wait a couple of weeks.</p><p>
A stock broking account, like buying e-gold, is a very HARD form of
money. Whenever you are trying to buy a very HARD form of money,
using a softer form of money.
</p>
<p>
Here is the "May Scale" of money hardness (comments invited)
</p>
<pre> --hard--
1 street cash, US dollars
2 street cash, euro currencies, Aus, japan
3 egold
4 street cash, other regions
5 interbank transfers of various sorts (wires etc)
6 checks
7 consumer-level electronic account transfers (eg bPay in Australia)
8 business-account-level retailer transfer
--soft--
9 paypal and similar 'new money' entities
10 credit cards
--ludicrously soft!--
</pre>
It is not meant to be definitive (eg, 6 and 7 could perhaps be
swapped; I left out cash on call at your stock broker, which is
probably around "2", etc) but gives a framework to think in.<p>
Now if you're a retailer and you're selling VCRs, sure, you can take
poxy money around the May Scale of 8, 9 or 10.</p><p>
But if you're a "retailer" and what you're selling is money itself
– ie, you are selling e-gold, or you are Quick &amp; Reilly – it
is EXCEEDINGLY DIFFICULT to accept anything with May Scale &gt; about 5.</p><p>
(Note that at coconutgold, we simply only accept wires! All the exchange providers for e-gold who accept money on the May Scale of 9 or 10 are very brave, tough, and quite understandably have to charge fairly high premiums to do so!)</p><p>
Again the point --- it’s no surprise or horror that it is somewhat DIFFICULT to get e-gold, to fund e-gold .... it’s for exactly the same reason that you can’t instantly fund a stock broking account.</p><p>
Observe that at Bananagold, we TAKE IN #3 and PUT OUT #8 .. so that’s a very 'secure' transaction. The #3 transactions is essentially not reversible, whereas the #8 transaction is a joke, we could reverse it anytime with a short argument on the phone.)</p><p>
What a surprise! that banks will only accept money that is at the 1 to 4 end of the May Scale, and they are only really happy giving you money on the 6 to 10 end of the May Scale!</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

154
docs/bitrot_and_protocol_negotiation.html Normal file
View File

@ -0,0 +1,154 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Bitrot, Protocol Negotiation, and the Confused Deputy Problem</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Bitrot and Protocol Negotiation</h1>
<h2>The problem</h2><p>
One particular case of the bitrot problem was the Microsoft Windows
problem known as “DLL Hell”, DLLs being binary dynamically linked
libraries in Microsoft Windows.&nbsp; </p>
<p> Over time these libraries tended to be upgraded, improved, and changed,
and programs written for the old libraries would develop bugs with the new
libraries, sometimes these bugs were crash and burn bugs, “bitrot”,
sometimes there were unexpected interactions between programs using the
same library, which caused one program to accidentally foul up another, or
enabled one program to maliciously manipulate another. </p>
<p> This problem was solved. The solution was “COM”.&nbsp; In COM, dynamic
linking necessarily involves version negotiation.&nbsp; Mandatory version
negotiation largely relieves bitrot.&nbsp; </p>
<p> In COM, in accordance with Zooko’s triangle, each version of a library’s
behavior, each library interface, has three names. Describing those names
and their behavior from the point of view of Zooko’s triangle, which is
not how most Microsoft programmers would describe them or think about
them: </p>
<ol>
<li>The GUID, the globally unique identifier, a very large random number,
a number so large that it was unlikely that any two libraries or two
versions would randomly choose the same number. Compiled software
interacts with other compiled software using this identifier.</li>
<li>The nickname, a human readable user friendly name and version number,
which is not necessarily globally unique.&nbsp; “Nickname” is Zooko’s
terminology, not what Microsoft calls them. Humans writing code to be
interpreted may use the nickname, though the correct behavior would be
for the code writer to use the petname, and for the development
environment to insert the appropriate GUID, if no GUID is specified, and
adjust the petname to its local value if the GUID is specified. </li>
<li>It may, and should, have a petname, its registry key, a humanly
readable user friendly local name which is guaranteed unique on the
particular computer on which the library (ActiveX object) has been
installed, but is not necessarily meaningful to the world at large,
though this is not quite implemented.&nbsp; Again, petname is Zooko’s
terminology, not what Microsoft calls them.&nbsp; The petname, if it
exists, is automatically generated from the nickname.&nbsp; Error
messages should use the petname, though they tend to use the nickname. </li>
</ol>
<p> In order for a program to connect to any COM library (what Microsoft
calls an ActiveX object), it has to do protocol negotiation in order to
get an interface, has to ask for the interface by its globally unique
identifier, so the library always knows what version of the library the
program expects, and will provide that behavior, or, if it cannot provide
that behavior, the program will fail immediately with an error message
explaining the problem.&nbsp; </p>
<p> <em>This solution worked. It solved DLL hell, solved bitrot.&nbsp;</em>
</p>
<p> Windows implementation of this solution was less successful in dealing
with another problem – library calls often cross thread and process
boundaries. They provided a general purpose threading solution, also part
of COM, which was hideously complicated and failed dismally.&nbsp; But
they fixed bitrot.&nbsp; </p>
<p> Cross thread and cross process interactions usually wind up being
implemented as message streams and message queues.&nbsp; The correct
approach is to make this explicit, to define the interface as a message
protocol, rather than attempting to hide the underlying message queue
behavior as Microsoft did and pretend it is an ordinary synchronous object
method.&nbsp; Where COM runs on top of message queues, as it does whenever
a call crosses thread or process boundaries, the result is intolerable
obscurity, complexity, and inefficiency – which is still a lot better than
the bitrot that it fixed.&nbsp; </p>
<h2>The blockchain solution</h2><p>
A pool is a shared collection of transactions with a single schema and protocol, but no global transaction order.</p><p>
A blockchain is a shared collection of transactions with a single schema and protocol with a global order and a sequence number for every transaction. Every blockchain has a pool, and transactions are added from the pool to the blockchain by a process for constructing consensus on order.</p><p>
There will be many blockchains, though we would prefer only one. One is likely to emerge supreme, but there will always be forks and competing blockchains, and forks and competition have to be lived with until they are resolved, which is apt to take a long time.</p><p>
Because establishing a global order is costly, there will be many pools without blockchains. If you don’t need a global order on transactions, don’t pay the costs of constructing one. Usenet was an immensely valuable pool without global order, and it was a great pity that it died. I want to replace it.</p><p>
There will be necessarily be many schemas and many protocols. A blockchain should assign a globally unique arbitrary precision number to each pool, schema, and protocol, but there will be more than one blockchain, and pools outside any one blockchain.</p><p>
Although the number is in principle arbitrary precision, each peer, host, and client will have an arbitrary limit to the precision of the identifiers that they will handle. They have to be able to handle at least sixty three bits, often sixty four bits, and have to be able to fail gracefully with identifiers that exceed their precision. Anything with an identifier that exceeds their precision limit will not exist for them. In practice, most identifiers are likely to less than eight bits.</p><p>
A peer continually checks in full that its blockchain follows or follows from the blockchain of its peers, an operation that is costly. It terminates communication with any peer that is forking. A client treats its host peer’s version of the blockchain is the authoritative one true version of the blockchain.</p><p>
A client necessarily has communications with many peer hosts. If one of its peer hosts has a block number and root hash for that block of the blockchain that is different from that of another peer host, it has to terminate communications with one peer host or the other, and terminate interactions concerning that blockchain with other clients that rely on a peer host with discrepant block for what is purportedly the same blockchain.</p><p>
Every blockchain, every pool, every schema, and every protocol has a short human readable name, but this name is not necessarily globally unique. Indeed, for schemas and protocols, certainly not globally unique, because schemas and protocols are always being updated, and we don’t want to change the name every time, and pools are continually being updated, with no two peers on a pool necessarily having exactly the same pool.</p><p>
A blockchain on one peer is the same as the blockchain on another peer if its root hash is the same, or follows, or follows from, the root hash on the other peer, but for pools, we have no definition of a pool being the same that a computer can check. But a pool has a schema and a protocol, and that the computer can check.</p><p>
Schemas and protocols have version numbers, which are deweydecimal sequences of arbitrary precision integers, but even these are not guaranteed to be globally unique, though any one blockchain may choose to ensure that the list of schemas and protocols for which it provides unique arbitrary precision identifers have globally unique names and deweydecimal numbers.</p><p>
The globally unique identifier of a schema or protocol is a thirty two byte probabilistically unique number, which may be the twenty byte globally unique identifier of a git commit, preceded by as much of the start of the name and the trailing end of the dewey decimal sequence as fits, albeit likely not much fits in twelve bytes.</p><p>
When establishing communication, the setup relies on a hash value that employs the globally unique identifiers of everything relevant to the communication, so that communication will immediately and gracefully fail if the parties establishing communication are in disagreement about what protocols and and schemas they are employing. But first they have to figure out what protocols and schemas the other party is using, relying on identifiers that could potentially have conflicting meanings.</p><p>
When establishing communication in a blockchain context, they rely on blockchain unique arbitrary precision integer identifying the schema or protocol. But there may be no such agreed context, or they may be communicating about a pool that is not on the blockchain, or not on any blockchain, for example a transient pool set up to establish a shared multiparty transaction to mingle crypto currency, which requires a blockchain context, but will not be identified by the blockchain, though it will rely on a schema and protocol that is identified by the blockchain.</p><p>
A transient pool set up to organize a multiparty transaction has a nickname, petname, and deweydecimal number, which deweydecimal is likely to be the number of pools of that name the entity starting the pool has attempted, hence highly likely to not be globally unique, or even blockchain unique. Maybe not even unique to that entity.</p><p>
To identify a pool, a schema, or a protocol in a context where there is no authortative guarantee of unique integer identifier, the parties send a fragment of the probabilistically unique thirty two byte identifier, consisting of a four bit multiple of sixteen bits of offset into that identifier, and sixty bits of the intentifier. Thus each full 256 bit identifier has sixteen possible 64 bit identifers. The parties systematically or randomly change which of the sixteen they use, in order to escape collisions.</p><p>
The parties look up a hash table of recently used 64 bit identifiers, and if that fails, an associative array of sixty four bit identifers. If there is a collision between sixty four bit identifiers, neither of the colliding sixty four bit entries are entered into the associative array, but when a twofiftysix bit identifier is used that was not found in the hash table, all sixteen sixty four bit identifiers go into the hash table, so that a seldom used two hundred and fifty six bit identifier that has a colliding sixty four bit identifier has its colliding identifier masked by a frequently used two hundred and fifty six bit identifier.</p><p>
In the unlikely event that a collision exists in the space of all sixtyfour bit identifiers known to a particular entity in the associative array, it cannot collide in the space of sixtyfour bit recently used identifiers in the hash table.</p><p>
Thus a pool, a schema, a blockchain, or a protocol is identified by its far from unique nickname and petname, its name plus its usually but not necessarily unique deweydecimal number, its globally unique 256 bit identifier, and sixteen sixty four bit identifiers, which are overwhelmingly likely to be unique, but can fail (very very rarely). If the sixtyfour bit identifier fails then the communication fails that one time, but will succeed, with at least fifteen sixteenths probability, another time.</p><p>
In the highly unlikely event that an identifier has a sixty four bit collision with a commonly used identifier, this is a a problem for the less commonly used identifier, since one in sixteen connections will fail. If a hash table has eight thousand entries, corresponding to five hundred commonly used entities, the likelihood of any one randomly generated long identifier having a collision of one of its sixteen short identiers with a commonly used identifier is one in 100 000 000 000 000, which is too low to worry about. Potential collisions between two rarely used identifiers do not matter, because if someone is using a rarely used identifier, it likely to be commonly used identifier for him and the people he is communicating with.</p><p>
The worst case is a collision between two commonly used identifiers, but the more restrictively we define "common" the less likely such a collision. If a group of people are commonly using fifty entities, then the chance that two of those entities have a collision in one of their sixty four bit identifers, resulting in one of their entities leading to communication failure one sixteenth of the time, is one in 30 000 000 000 0000.</p><p>
When setting up a pool for a multi party transaction, the parties initially communicate with each other in a namespace controlled by a single blockchain, hence have blockchain unique identifiers for protocols and schemas, hence the only collision possible is between pools, and there will not be all that many multiparty transactions going at any one time among the people a party is interacting with, though the number of possible multiparty transactions being organized at any one time is potentially very large.</p><p>
If the user is looking for subscrbers to a particular pool among subscribers to a hundred thousand pools, each subscriber subscribing to a hundred pools, it will be enormously rare for him to misidentify a subscriber to a different pool as a subscriber to his own pool and then attempt to communicate with that subscriber, and such misidentification will merely slow things down imperceptibly, not halt things. The communication with that subscriber will simply fail. Failure for other reasons is enormously more probable.</p><p>
Sixtyfour bit identifiers suffice for most practical purposes, provided that the communication protocol is such that misidentification of the corresponding twohundredfiftysix bit identifier results in immediate graceful communication failure.</p><p>
There are some cases where sixty four bits do not suffice, for example identifying a transaction on the blockchain. In such cases, we use the blockchain transaction sequence number, which is globally unique to the blockchain, or the full twofiftysix bit identifier, which is proabilistically unique. An entity in the context of a blockchain is identified by its transaction number, and its output/input number within the transaction, though the blockchain itself is identified merely by a short human readable string, which in the presence of forks and competition, is likely to cause potential misidentification. The sequence number of inputs to a transaction follows, rather than precedes, the sequence number of inputs, which resolves potential ambiguity at an average waste of one bit in the rare case that one references an input, rather than an output.</p>
<h3>Fully general solution</h3><p>
If there was a consensus on what identifiers were common, we could get away with variable length identifiers. But this leads to the TLA problem. Hard to establish a consensus, hard to know what it is. If you have a system that drifts towards consensus, such as the english language, what drives the drift is that collision problems happen. But you don’t want collision problems to happen, because then you need rather complex code for handling that case, and a complex data structure to describe estimates of what the consensus likely is.</p><p>
So, we have an identifer that establishes an explicit context, a map of probabilistically unique twofiftysix bit identifiers to indefinite precision integers and to short human readable strings. The blockchain provides such a mapping, and the pool references the blockchain. But a pool cannot contain such a mapping, unless it has its own blockchain.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

32
docs/block_google_analytics.html Normal file
View File

@ -0,0 +1,32 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Block Google Analytics</title>
</head>
<body><a href="./index.html"> To Home page</a>
<h1>Block Google Analytics</h1><p>
Most internet sites use Google Analytics, which downloads an enormous pile of javascript on your browser, which systematically probes your system for one thousand and one privacy holes and weaknesses and reports back to Google Analytics, which then shares some of their spy data with the site that surreptitiously downloaded their enormous pile of hostile spy attack code onto your computer.</p><p>
Modify your hosts file to include the following lines:</p><pre>
0.0.0.0 google-analytics.com
0.0.0.0 www.google-analytics.com
0.0.0.0 ssl.google-analytics.com</pre><p>
On Linux, your hosts file is found under <code>/etc</code><br/>
On windows found under <code>%windir%\system32\drivers\etc</code></p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

42
docs/canonicalizing_human_readable_identifiers.html Normal file
View File

@ -0,0 +1,42 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Canonicalizing Human Readable Identifiers</title> </head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Canonicalizing Human Readable Identifiers</h1><p>
This is not an urgent problem, since we will only employ password-authenticated key agreement based on zero knowledge password proofs, considerably reducing the phishing attack surface.&nbsp; </p><p>
The C language library <a href="http://www.flexiguided.de/publications.utf8proc.en.html">utf8proc</a> does some rather basic canonicalization for identifiers, falling well short of the lengthy and complex prescriptions of the unicode consortium.</p><p>
The unicode consortium has <a href="https://www.unicode.org/reports/tr39/#UTR36">extensive</a> <a href="https://www.unicode.org/reports/tr39/">documentation</a> on confusable identifiers, plus <a href="http://unicode.org/cldr/utility/confusables.jsp">source code for detecting them</a>.&nbsp; They are primarily worried about spoofing paypal.&nbsp; </p><p>
But for identiers, we convert the original UTF-8 string to <a href="https://www.unicode.org/reports/tr15/tr15-45.html">Normalization Form C (NFC)</a>, and <a href="https://www.unicode.org/reports/tr39/">then has homoglyphs mapped to a single glyph with a context sensitive mapping tool that tries to choose the homoglyph that best suits the surrounding character script.</a>.&nbsp;</p><p>
We apply the following rules to an identifier string:&nbsp; </p><ul><li>
Invisible characters removed.&nbsp; </li><li>
All of the innumerable different kinds of unicode whitepaces are mapped to a single white space.&nbsp; </li><li>
Leading and trailing whitespace removed.&nbsp; </li><li>
All strings end with a visible character followed by a terminator null.&nbsp; No invisible strings.</li><li>
Homoglyphs that look like a numeric are mapped to a numeric if followed or preceded by a numeric.&nbsp; </li><li>
Homoglyphs that look like a member of a script are mapped to that script if followed or preceded by a member of that script.&nbsp; Preceding characters take precedence, except that numerics take precedence over latin, and latin precedence over other scripts.</li><li>
Isolated homoglyphs, homoglyphs that do not look like any member of the scripts of the preceding or following characters, are mapped to the first script preceding them that provides a match, or, failing that, the first script following them that provides a match, or, failing that, to the homoglyph with the lowest numeric value, which is usually the most vanilla homoglyph.&nbsp; </li></ul><p>
If these rules result in any changes, the rule set is reapplied until no further changes ensue.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

187
docs/contributor_code_of_conduct.html Normal file
View File

@ -0,0 +1,187 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Contributor Code of Conduct</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="./pandoc_templates//style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
border: 1px solid #999;
padding: 0.5rem;
text-align: left;
}
h1.title{
text-align: center; font-size: xxx-large;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<p><a href="./index.html"> To Home page</a></p>
<header id="title-block-header">
<h1 class="title">Contributor Code of Conduct</h1>
</header>
<nav id="TOC" role="doc-toc">
<ul>
<li><a href="#peace-on-earth-to-all-men-of-good-will"><span class="toc-section-number">1</span> Peace on Earth to all men of good will</a></li>
<li><a href="#operational-security"><span class="toc-section-number">2</span> Operational Security</a>
<ul>
<li><a href="#no-namefags"><span class="toc-section-number">2.1</span> No namefags</a></li>
</ul></li>
<li><a href="#code-will-be-cryptographically-signed"><span class="toc-section-number">3</span> Code will be cryptographically signed</a></li>
<li><a href="#no-race-sex-religion-nationality-or-sexual-preference"><span class="toc-section-number">4</span> No race, sex, religion, nationality, or sexual preference</a></li>
<li><a href="#no-preaching-supererogation"><span class="toc-section-number">5</span> No preaching supererogation</a>
<ul>
<li><a href="#no-claims-of-doing-good-to-random-unknown-beneficiaries"><span class="toc-section-number">5.1</span> No claims of doing good to random unknown beneficiaries</a></li>
<li><a href="#no-victim-classes-no-identity-politics-and-no-globalism"><span class="toc-section-number">5.2</span> No victim classes, no identity politics, and no globalism</a></li>
</ul></li>
</ul>
</nav>
<h1 data-number="1" id="peace-on-earth-to-all-men-of-good-will"><span class="header-section-number">1</span> Peace on Earth to all men of good will</h1>
<p>May you do good and not evil. May you find forgiveness for yourself and
forgive others. May you share freely, never taking more than you give.</p>
<h1 data-number="2" id="operational-security"><span class="header-section-number">2</span> Operational Security</h1>
<p>A huge problem with software that relates to privacy and/or to money is
that frequently strange and overcomplicated design decisions are made,
(passive tense because it is strangely difficult to find who made those
decisions), decisions whose only apparent utility is to provide paths for
hostile organizations to exploit subtle, complex, and unobvious security holes.</p>
<p>These holes are often designed so that they can only be utilized efficiently
by a huge organization with a huge datacentre that collects enormous
numbers of hashes and enormous amounts of data, and checks enormous
numbers of hashes against an even more enormous number of potential
pre-images generated from that data.</p>
<p>Another huge problem is that if we get penetrated by enemy shills,
entryists, and buggers, as the Patriot Front is and the Jan Sixth protestors
were, we are likely to wind up like the January sixth protestors, who as I
write this are imprisoned indefinitely being tortured by black guards
recently imported from the northern part of black Africa, awaiting
trial with no likelihood of any actual trial for years.</p>
<h2 data-number="2.1" id="no-namefags"><span class="header-section-number">2.1</span> No namefags</h2>
<p>A participant who can be targeted is likely to introduce unobvious security
flaws into the software architecture. All contributors should make some
effort to protect themselves against a third party subsequently coercing
them to use the reputation that they have obtained by contributing to make
subsequent harmful contributions.</p>
<p>All contributors will use a unique name and avatar for the purpose of
contributing to this project, and shall not link it to other names of theirs
that are potentially subject to pressure. In the event of videoconferencing,
the participants shall wear a mask over the lower part of their face that
conceals the shape of their mouth and jaw and a rigid hat like a fedora that
conceals the shape of the upper part their head.</p>
<p>Apart from your mouth, the parts of your face that communicate non
verbal information turn out to be surprisingly useless for identifying
individuals.</p>
<p>If you wear glasses, should not wear your usual glasses, because facial
recognition software is very good at recognizing glasses, and easily
distracted, confused, and thrown off by unusual glasses.</p>
<p>Even if there are gaping holes in our security, which there will be, and
even if everyone knows another name of a participant, which they will, no
need to make the hole even bigger by mentioning it in public. People who lack
security are likely to result in code that lacks security. They come under
pressure to introduce an odd architecture for inexplicable reasons. We see
this happening all the time in cryptographic products.</p>
<h1 data-number="3" id="code-will-be-cryptographically-signed"><span class="header-section-number">3</span> Code will be cryptographically signed</h1>
<p>Of necessity, we will rest our developer identities on GPG keys, until we
can eat our own dogfood and use our own system’s cryptographic keys.
Login identities shall have no password reset, because that is a security
hole. If people forget their password, they should just create a new login
that uses the same GPG key.</p>
<h1 data-number="4" id="no-race-sex-religion-nationality-or-sexual-preference"><span class="header-section-number">4</span> No race, sex, religion, nationality, or sexual preference</h1>
<figure>
<img src="./images/nobody_know_you_are_a_dog.webp" alt="On the internet nobody knows you are a dog" /><figcaption aria-hidden="true">On the internet nobody knows you are a dog</figcaption>
</figure>
<p>Everyone shall be white, male, heterosexual, and vaguely Christian, even
if they quite obviously are not, but no one shall unnecessarily and
irrelevantly reveal their actual race, sex, religion, or political orientation.</p>
<p>All faiths shall be referred to respectfully. Even if they happen to be
making war on us, this software may not be very relevant to that kind of
warfare, in which case that discussion can be held elsewhere.</p>
<p>All sovereigns shall be referred to respectfully, if they are referred to at all,
which they should not be. If this software is likely to frustrate their
objectives, or even contribute to their overthrow, no need to make it
personal, no need to trigger our enemies. War will come to us soon
enough, no need to go looking for it.</p>
<h1 data-number="5" id="no-preaching-supererogation"><span class="header-section-number">5</span> No preaching supererogation</h1>
<p>Status must be on the basis of code, good code, and clever code, not on
cheap claims of superior virtue.</p>
<p>When someone plays the holier than thou card, he does not intend to share
what we are sharing. Out of envy and covetousness, he intends to deny us
what we are sharing, to deny us that which is ours.</p>
<p>If he is holier than we are, he not only wants what we have, which we will
gladly share. He wants us to not have what we have.</p>
<p>Christians are required to turn the other cheek, and people attempting to
maintain a politically neutral environment need to turn the other cheek.
But you very quickly run out of cheeks, and then it is on. You cannot be
politically neutral when the other guy is not being neutral. You have to
bring a gun to a gunfight and a faith to a holy war. People who start
politics in an environment intended to be politically neutral have to be
purged, and a purge cannot be conducted in a politically neutral manner.
You have to target the enemy faith and purge it as the demon worshiping
heresy that it is, or else those attempting to maintain political neutrality
will themselves be purged as heretics, as happened to the Open Source and
Free Software movements. You may not be interested in war, but war is
interested in you.</p>
<p>We want to maintain a politically, racially, religiously, and ethnically
neutral environment, but it takes two to tango. You cannot maintain a
politically neutral environment in a space where an enemy faction wants
their politics to rule. Neutrality cannot actually be neutral. It merely means
that the quietly ruling faction is quiet, tolerant of its opponents, and does
not demand affirmations of faith. If an enemy faith wants to take over,
the ruling faith can no longer be quiet and tolerant of that opponent.</p>
<h2 data-number="5.1" id="no-claims-of-doing-good-to-random-unknown-beneficiaries"><span class="header-section-number">5.1</span> No claims of doing good to random unknown beneficiaries</h2>
<p>We are doing this for ourselves, our friends, our kin, and our posterity, not
for strangers a thousand miles away, and we only care about strangers a
thousand miles away to the extent that they are likely to enable us to make
money by making them secure.</p>
<p>If someone mentions the troubles of people a thousand miles away, it
should only be in the frame that we will likely have similar troubles soon
enough, or that those people a thousand miles away, of a different race,
religion, and language, could use our product to their, and our, mutual
advantage, not because he cares deeply for the welfare of far away
strangers that he has never met in places he could not find on a map.</p>
<h2 data-number="5.2" id="no-victim-classes-no-identity-politics-and-no-globalism"><span class="header-section-number">5.2</span> No victim classes, no identity politics, and no globalism</h2>
<p>The Open Source and Free Software movements were destroyed by
official victimhood. Status and leadership must be on the basis of code,
good code, and clever code, not on cheap claims of superior oppression.</p>
<p>The experience of the Open Source and Free Software movement
demonstrates that if victimhood is high status, code and code quality must
be low status. If victimhood is high status then “you did not build that”.
Rather, if victimhood is high status, then good code, silicon fabs, and
rockets spontaneously emerged from the fertile soil of sub-Saharan Africa,
and was stolen by white male rapists from the brave and stunning black
warrior women of sub-Saharan Africa, and social justice demands that the
courageous advocate for the brave and stunning black warrior women of
sub-Saharan Africa takes what you have, what you gladly would share,
away from you.</p>
<p>Unless, when a female contributor unnecessarily and irrelevantly informs
everyone she is female, she is told that she is seeking special treatment on
account of sex, and is not going to get it, no organization or group that
attempts to develop software is going to survive. Linux is a dead man walking.</p>
<p style="background-color: #ccffcc; font-size: 80%;"><a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/80x15.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.</p>
</body>
</html>

109
docs/crypto_currency_and_the_beast.html Normal file
View File

@ -0,0 +1,109 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Crypto Currency and the Beast</title> </head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Rhocoin and the Beast</h1><p>
We need blockchain crypto currency supporting pseudonymous reputations and end to end encrypted communications where an encrypted communication can carry money, rfps, bills, invoices, and offers. </p><p>
We also need one whose consensus protocol is more resistant to government leverage. Ethereum is alarmingly vulnerable to pressure from our enemies.</p><p>
The trouble with all existing blockchain based currencies is that the metadata relating to the transaction is transmitted by some other, ad hoc, mechanism, usually highly insecure, and this metadata necessarily links transaction outputs to identities, albeit in Monaro it only links a single transaction output, rather than a network of transactions.</p><p>
Thus we need a pseudonymous, not an anonymous, crypto currency.</p><p>
The intent of this technology is to liberate the reputational information that makes transactions possible, currently largely siloed by Ebay and Amazon, to secure it not by a record in centralized databases, but by secret keys held by unknown individuals who cannot be grabbed by cops or beaten up by antifa.</p><p>
These reputations will make it possible for an anonymous use-once identity to perform an instant on the spot transaction secured by the reputation of a large and long established peer on the blockchain with a pseudonymous reputation, the transaction being with an identity secured by a secret held by an anonymous individual, also secured by the reputation and secret held by someone who controls a large and long established peer with a pseudonymous reputation, whose physical servers are located in a data center in a nation state distant from the nation state and local authorities where the actual transaction takes place.</p><p>
But it is awfully close to, and very similar to, the profoundly oppressive technology of the Prophecy of the Beast. It is a dual use technology, that can be used by individuals to free themselves from centralized control, and could be used by powerful centers to enforce centralized control.</p><p>
The free and pseudonymous end to end encrypted messaging is intended to undermine the officially unofficial state religion of progressivism, making the worship of Gnon possible and safe, but could easily be repurposed to the heavily censored messaging scrutinized by global databases belonging to the beast that today we see with Twitter, Facebook, and Gmail, which enforce the officially unofficial State Religion of the Beast.</p><p>
For example, this technology can be used to publish data obtained by the Scientific Method, secured by reputations for faithfully adhering to the scientific method, but Google Docs censors such information and downranks such reputations in search results in favor of data concocted by Peer Review, which are priestly truths established by the priestly method of Holy Synods, of the priesthood of the Beast.
<h2>The Prophecy of the Beast</h2><p>
The Beast with seven heads establishes a false, state enforced religion, which converges all other religons to it and:</p>
<blockquote>16 And he causeth all, both small and great, rich and poor, free and bond, to receive a mark in their right hand, or in their foreheads:<br/>
17 And that no man might buy or sell, save he that had the mark, or the name of the beast, or the number of his name.</blockquote><p>
What the Dark Enlightenment calls the Cathedral is The Beast with Seven heads, no single will but a consortium of several conspiracies, rather too many conspiracies, each contending for power and status, each composed of several individuals, rather too many individuals, each contending for power and status. The Cathedral is not a single individual, and lacks a single will, but it is not a very large number of individuals either.</p><p>
Everyone today is tracked by their cellphone, which is necessarily continually triangulated by several cell phone towers, and necessarily reports its distance to anything pretending to be a cellphone tower, and everyone’s face is recorded in numerous facial recognition databases.</p><p>
If these databases get integrated with your social security number or tax file number, which increasingly they are, that is the number of the beast.</p><p>
So, everyone does have that number, but the prophecy of the beast is not yet fullfilled unless everyone, both small and great, rich and poor, free and bond, needs that database integration to buy and sell.</p><p>
The prophecy, in today’s context, means you would not be able to buy and sell except your face and phone links the transaction to your social security number, and this system would be applied throughout the American Empire with a global database of tax file numbers.</p><p>
To buy and sell, your phone would need to contain a local copy of a recent extract from the Beast’s global database, digitally signed by a recent digital signature from the Beast, which extract contains a recent photograph of your face, or recent face recognition parameters, or you would need a card with a chip on it, containing a recent extract with recent face recognition parameters.</p><p>
Deliveries would only be delivered to a name and address registered to a social security number or tax file number in the Beast’s database, and paid for from an account registered to that that social security number or tax file number. In person transactions over the counter transactions would require your face matching the Beast’s database, a face that can be beaten in by antifa.</p><p>
If you can use cash, gold, silver, tobacco, anonymous crypto currency, or small calibre long rifle ammunition to buy and sell, then the prophecy of the beast has not yet come to pass.</p><p>
Crypto currency has the great advantage that you can use it to perform
transactions over distance and time, secured by the blockchain, and
rhocoin is designed to also allow instant in person on-the-spot
over-the-counter transactions, intended to be a complete replacement
for fiat money.</p><p>
It is increasingly the case that low, poor, and bond, face considerable risks in using cash. For example black people, mainly black people who do not have jobs or families, are using bottles of laundry powder as cash, because a low person with a lot of cash is apt to have his cash seized by police. The advantage of using laundry powder as money is that its inconvenient bulk makes the police reluctant to seize it.</p><p>
Crypto currency passphrases are also inconvenient to seize, since they need to beat up the holder of the secret, and he likely has more than one such secret, but low, poor, and bond find them a bit difficult to use. It is has to pass that low poor and bond are using laundry powder to do transactions without the number of the beast, and high, rich, and free are using crypto secrets.</p><p>
It is very difficult to exchange fiat money for crypto cash, except you record your face and data integrated with the database of the beast with the exchange.</p><p>
Every major crypto exchange is integrated with the beasts databases, linked to your social security number or tax file number, and with a recent photograph that will be used for facial recognition, to the number on your hand and on your forhead.</p><p>
The capability of rhocoin for instant in person transactions is intended to
make exchanges of fiat cash for rhocoin difficult to centralize, and the
capability of rhocoin for communication secured by pseudonymous reputations is
intended to make it possible for the scientific method to be practiced, as the
true worship of Gnon requires.</p><p>
The capability for public communications securely connected to a pseudonymous reputation is primarily intended to free the reputational data currently siloed by Amazon and Ebay, used to exchange value over time and distance, but also intended to be used for other reputational purposes, to liberate scientific reputations from academic silos.</p><p>
When high, rich, and free gets his gold and cash seized, and the secret key to his crypto extracted by rubber hose cryptography, when integration of crypto currency to the databases of the Beast is complete, or dangerous to avoid, when the blockchain records your every transaction forever and connects them to a face that can be beaten in, and places where that face is likely to be found, then the prophecy of the beast has come to pass.</p><p>
As a blockchain scales up to full commercial scale, running a full peer
becomes costly and burdensome, so with bitcoin we have alarmingly few
miners, and power over the blockchain is concentrated in very few miners.
The reason for rhocoin
to use the paxos protocol rather than the mining protocol is to ensure that
when that when concentrated power comes to pass, the concentrated power is in
the hands of wealthy people who want to use its transaction service, who
probably do not want all of their transactions exposed to hostile scrutiny.
The design aims to ensure that when power gets concentrated, as with scaling
it
inevitably will, it gets concentrated into peers whose underlying identity
secrets can easily vanish off to another jurisdiction, and whose power depends
on having lots of wealthy clients, many of whom are unlikely to want full
scrutiny of all their transactions, lest envious people find some excuse for
beating in their faces. Paxos protocol means that the system operates
effectively like corporate board, and since "votes" are proportional to bitcoin
of clients, a "board" that we may hope that, when scaling inevitably produces
centralization, is in effect composed of a large number of rich and powerful
people who prefer banking in secrecy and do not trust each other all that much.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

64
docs/crypto_currency_launch.html Normal file
View File

@ -0,0 +1,64 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Crypto Currency Launch</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Crypto Currency Launch</h1><p>
The total value held in the form of gold is ten trillion. But gold has problems – if you try to transport it through an airport, security will likely take it from you. Hard to travel with it hidden. </p><p>
Hard to transfer it from one person to another, or from one identity to another. Hard to do international transactions in gold, hard to pay for oil with gold, or be paid for oil with gold, because transporting large amounts of gold is slow and dangerous.</p><p>
So, something better than gold, more transportable, more hideable, people would probably keep more than ten trillion in that form.</p><p>
The current value of bitcoin is about three hundred billion. Arguably crypto currency, if it works, if safe against the state, should be rather more than ten trillion. Say thirty trillion. This provides an upside of another hundred fold increase in value. On the other hand, the bitcoin is traceable in ways that gold is not. People are waiting to see what happens when the government cracks down.</p><p>
A crypto currency needs to be totally traceable and totally untraceable. Ann wants to be able to prove to Carol that she paid Bob, and that therefore her debt to Bob is cleared, or Bob has an obligation the Ann. But Ann and Bob likely do not want a powerful hostile party to be able to discover that Ann made a payment to Bob. Existing crypto currencies suffer from total traceability.</p><p>
Money is a store of value, a medium of exchange, and a measure of value. Gold sucks as a medium of exchange, because of transportation risks and costs. Crypto currency is very good as a medium of exchange, better than anything else, because banks are so remarkably incompetent, inefficient, and lawless. </p><p>
As a measure of value, gold has immense and ancient history, which makes it the best for long term measure of value. If you graph the prices of something, such as oil, over decades and centuries, you get far saner and more plausible data when you graph in terms of gold than in dollars, or even supposedly inflation adjusted dollars. Gold is the best measure of value over time. Inflation adjusted dollars give results that smell of politics and propaganda. Bitcoin, because of volatility and extremely rapid deflation, is really bad as a measure of value, but time will slowly fix this.</p><p>
The current price of bitcoin reflects a substantial possibility that it replaces the dollar as the currency of international transactions, in which case the dollar finds itself on the bitcoin standard, like it or not.</p><p>
To attract a significant portion of the wealth of the world, we do not want to have any mining, since this basically a fee against large accounts. We want a per account fee, because every account results in accountancy costs, and a transaction fee, because every transaction results in transaction costs, but not a charge against holding enormous amounts of wealth in an account. Mining is a charge against the value of accounts, which is a bad idea if we want wealth holders to hold their wealth in our crypto currency.</p><p>
We want it to be impossible to find who holds a large account if he does not want to be found, so that he is safe from rubber hose cryptography. We want it to be easy for him to keep control, and hard for anyone else to get control. He should be able to take the wallet that controls the bulk of his money offline, so that it cannot sign anything, because he has the signing key on a scrap of paper hidden somewhere, or on several such scraps of paper.</p><p>
And then, bringing together the scraps of paper that are the secret number that controls his account paper, he can sit down at a computer anywhere in the world, and send that money hither and yon.</p><p>
Gold has problems as the medium of international exchange, because of the problems of moving it. So everyone left their gold in Fort Knox, and moved ownership of that gold around, but it gradually became more and more obvious that America has embezzled all that gold.</p><p>
Because of problems with gold, people wound up using the US$ as the medium of international exchange. Which works fine if the US Government likes you, but from time to time it decides it does not like someone, for reasons that grow increasingly capricious and unpredictable. </p><p>
Bitcoin is moveable. Big advantage over gold.</p><p>
Bitcoin is governed by consensus, which has serious problems because it is a consensus of miners, rather than a consensus of people who hold large amounts of bitcoin, but it has the advantage that the miners are rational, self interested, and competent, and are therefore predictable, while the US government is increasing crazy, self destructive, and criminal, and therefore unpredictable.</p><p>
The coin to invest in needs to be able to scale all the way to wiping out the US$ as a world currency. But it also needs to gain initial critical mass.</p><p>
How do we start up the coin?</p><p>
Bitcoin got started because everyone and his brother and his brother’s dog could mine, thus getting the software and and a small amount of coin into the hands of a large number of interested people. But a coin that relies on weight of stake, rather than weight of processing power, does not have mining. Instead, the coin is effectively shares in the startup. Founders, investors, and initial employees get the coins. But for the coins to be useful, have to get them into the hands of a wider circle of people.</p><p>
At the core of a crypto coin is a mechanism for determining and globally witnessing a global truth. That is a service that needs to be available on a for profit basis</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

67
docs/crypto_currency_new_index.html Normal file
View File

@ -0,0 +1,67 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<title>***************</title> </head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>************</h1>
Bitcoin and everything blockchain is a centralized ledger. Worse than that – it’s the One True Ledger. It isn’t like gold. Gold one can have directly on one’s person or indirectly in a vault somewhere.<p>
It is possible to have a crypto currency similar to bitcoin where though there is one global ledger recording what public keys own what, there is no way to tell which human actors know the private keys corresponding to those public keys. </p><p>
The downside of Chaumian e-cash is very simple. You need a single centralized trusted server holding a small number unshared secrets. At two in the morning Mueller kicks down your door and demands you alter the behavior of your server in ways that make it profoundly untrustworthy. While he is at, holds a gun to your head and takes the secrets, charges you with tax fraud, money laundering, etc, and puts you in solitary confinement pending trial so as to make it impossible to organize your defense. </p><p>
A crypto currency needs to be centerless – it needs to able to survive the seizure of key servers by a hostile powerful party. </p><p>
Trouble with bitcoin is that it is not centerless – proof of work winds up being centralized in a small number of extremely powerful and extremely expensive computers. </p><p>
Thus we need a system with proof of stake, and not only proof of stake, but proof of client stake – the power over the system needs to reside with peers that have a lot of wealthy clients – and it needs to be hard to find who the clients are, and where they are keeping their secrets, so that even if Mueller seizes important peers on charges of tax evasion and money laundering, does not thereby gain control. </p><p>
If the system handles an enormous number of transactions, peers are going to be big and expensive, thus vulnerable to people like Mueller armed with vague and open ended charges of tax evasion and money laundering. Hence the power of peer over the currency needs to be proportional to the wealth controlled by the secrets held by that peer’s clients. And that peer’s clients need to be free to move from one peer to the next, and apt to move to peers that make it difficult for Mueller to find their clients. </p><p>
Need a crypto currency where Bob can prove to the whole world that he paid Ann such and such amount, in accord with such and such a bill, but no one else can prove he paid Ann, nor that there ever was such a bill, except he shows them. Bitcoin is far too traceable. We need controlled traceability, where the parrticipants can prove a transaction to third parties and the world, but the world cannot. And Bob needs to be able to prove what the payment was about, that it was part of a conversation, a meeting of minds. </p><p>
The reason we have end user demand for crypto currency is the same as the reason we have end user demand for gold. </p><p>
When quasi governmental entities started freezing the accounts of "Nazis", "racists", "Russian trolls", and suchlike, a lot of "Nazis" and "Russian trolls" moved to crypto currency, shortly thereafter followed by a great many very wealthy men who were worried that when they needed their wealth in a hurry, they would suddenly become Nazis and Russian trolls also, and their wealth would suddenly become inaccessible or worthless. </p><p>
For a long time the big demand for crypto currency has been wealthy Chinese evading currency controls, but with the recent crackdown on hate speech, we are seeing massive American and European demand, which directly resulted in the recent spike in crypto currency values. </p><p>
Another substantial source of demand for crypto currency, which has been around since the beginning, is buying steroids and suchlike over the internet, but the really huge move in crypto currency demand came during the recent crackdown on political activists. </p><p>
Obviously political activists do not in themselves have enough wealth to cause such a huge move in market value, but when you go after political activists, you are going to make a whole lot of wealthy people reflect that they are none too popular either. If you are a rich man, makes sense to put a significant chunk of your wealth in crypto currency in case you suddenly become a refugee. For example, if, as is looking increasingly likely, there is a pogrom against whites in the USA, a whole lot of rich people will flee to Singapore, China, Russia, Hong Kong, the Philippines, and Dubai with nothing but the clothes they stand up in, and the master secret controlling their crypto currency in their heads. </p><p>
So that Bob can contract with Ann without the transaction becoming visible to the world, the crypto currency needs to embed an encrypted overlay network, a method for people to have forbidden conversations about forbidden things. Contracts imply conversations, and secret contracts imply secret conversations. Untraceable payments imply untraceable conversations. </p><p>
Full bore totalitarianism sufficient to shut down crypto currency is not far from full bore totalitarianism sufficient to shut down the internet. </p><p>
Full bore totalitarianism sufficient to shut down the internet is going to strangle your economy. If your enemies are markedly wealthier than you are, it is likely to be a problem. North Korea is poor in substantial part because it dares not allow something like the internet to exist. Any contact with the west is used by the state department as a vector for subversion and color revolution. </p><p>
North Korea wants to open up, and has repeatedly attempted to open up, but wants it to be safe for it to open up. If it does open up, expect a lot of North Koreans to buy crypto currency. </p><p>
To create an internet where I cannot send arbitrary packets to an arbitrary machine, you are going to have to license every hub that is allowed to accept packets. Expect some serious disputes as to who gets to do the licensing. </p><p>
Turning the whole world into one big North Korea is not going to be feasible, and attempting to do so is likely to result in a large part of the world glowing in the dark. </p><p>
However, turning the US into Venezuela is entirely feasible, might well happen. We have a potential Democratic Party president who proposes to do exactly that. </p><p>
Which is exactly why wealthy Americans are buying crypto currency, so that they can run to those parts of the world that do not turn into North Korea or Venezuela. </p><p>
The best example of repression which does not bother people too much is China, and the great firewall of China. And until recently, the major demand for crypto currency came from Chinese evading currency controls. </p><p>
So, to accomplish the goal of shutting down crypto currency requires world wide internet repression at levels considerably more repressive than China, which is likely to be disruptive and damaging within a single nation and a single economy, and apt to lead to conflicts if attempted globally. </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

69
docs/crypto_currency_on_wide_area_distributed.html Normal file
View File

@ -0,0 +1,69 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Crypto Currency on wide area distributed database</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Crypto Currency on wide area distributed database</h1><p>
Much of this material is shamelessly plaigarized without <a href="http://docplayer.net/14501083-Blockchain-throughput-and-big-data-trent-mcconaghy.html">attribution.</a></p><p>
Bitcoin has dangerously few miners, subject to dangerously few political authorities, and miner interests are insufficiently aligned to currency user interests.</p><p>
The solution is to create a crypto currency that relies on weight of stake, rather than weight of processing power.&nbsp; Such a currency is equivalent to a crypto corporation, or rather the easily traded shares of a crypto corporation.&nbsp; And independently of whether we need yet another crypto currency, we need crypto corporations.</p><p>
Hence my interest in threshold signatures that do not require a "trusted" dealer.</p><p>
Because of shareholder ignorance, and scaling law problems with enormous thresholds, I envisage that ordinary shareholders, or rather the laptops and cellphones of ordinary shareholders(wallets), would grant their voting rights to a rather small number of board members (massive server farms in the cloud).&nbsp; Every time you do a transaction through some web server, the recipient of the shares(currency) by default revocably grants his voting rights to whatever web server the recipient uses, thus reducing the scale problem to a moderate number of large entities with adequate connectivity and processing power.&nbsp; From time to time one board member (server farm) is elected CEO (leader for the Paxos protocol) If it goes down, loses connectivity, loses too many packets, or engages in Byzantine deviation from the Paxos protocol (possibly as a result of being raided by the cops for money laundering), they elect a new one after twenty seconds or so.&nbsp;</p><p>
“There is only one consensus protocol, and that is Paxos” -Mike Burrows, “all other approaches are just broken versions of Paxos.&nbsp;The Paxos protocol, conceived by Leslie Lamport, is famously subtle and a bit difficult to understand.”</p><p>
The Paxos protocol is not actually a solution to the consensus problem.&nbsp; Rather it is a tool, a necessary step in the larger solution to any one particular consensus problem, one step of a great many.</p><p>
The blockchain is a DB, as are modern Big Data NoSQL and NewSQL DBs.&nbsp;They re all distributed.&nbsp;Distributing a DB by making a full copy on every node scales extremely poorly.&nbsp;Distributed DBs need a consensus algorithm and the Bitcoin consensus algorithm is a horribly broken variant on Paxos.&nbsp;</p><p>
We need a sharded <a href="./crypto_currency.html">bitcoin</a>, that can scale to arbitary sizes.</p><p>
Bitcoin is a database that sacrifices consistency for availability.&nbsp; Suppose Sam the Scammer double spends the same money to Alice and Bob:</p><p>
Immediately afterwards the database might tell you that Sam has not spent the money, or that he has spent it on Alice, or that he has spent it on Bob, or that he spent it on Alice, and then attempted to spend it on Bob, but the attempted spend on Bob was disallowed, or that he spent it on Bob, and the attempted spend on Alice was disallowed.</p><p>
After an unpredictably long time, it will eventually reach a consensus in favor of Bob, or in favor of Alice, but the consensus is unpredictable, the time required to reach consensus could be quite long, and you can never be entirely sure that you are looking at the final consensus.</p>
<p>The Paxos protocol can potentially do better than this, in that it can definitively announce the final consensus, though there may be large delays in getting to it.</p>
<p>The solution is Paxos, sharding, and sidechains.&nbsp;Sidechaining is visible to the user and explicitly organized by the user with some formal and explicit organization with a website, while sharding happens automagically and invisibly.&nbsp; No one has figured out how to sharding automatically in the background without it being possible for some shards to cheat on others.</p>
<p>You can shard within a group where the nodes trust each other to fail only in a non byzantine manner, and we will need such sharding to handle arbitrarily large numbers of transactions.&nbsp; There is no obvious way of sharding without a shard being potentially capable of cheating either some people in the shard, or else other shards.</p><p>
This suggests a system where nodes belong to an indentifiable entity, and nodes belonging to the same entity trust each other to only fail in a non byzantine manner, while suspecting nodes belonging to a different entity of potentially byzantine failure.</p><p>
Google bigtable uses chubby, which uses Paxos.&nbsp; Bigtable does pretty much what a currency database would need to do.</p><p>
The variant of Paxos you need is Generalized Byzantine <a href="https://infogalactic.com/info/Paxos_(computer_science)#Multi-Paxos">Paxos</a> (nearly all operations commute) You probably also want semi stable leadership and a distinguished learner (normally the last guy to resolve a dispute resolves the new dispute.) </p><p>
Sharding is grouped by payments made, rather than payments received, since receiving a payment always commutes</p>
<p>To reduce coordination costs, we would like the global hash to be unchanged under commutative transactions.&nbsp; The global hash should reflect the presence, absence, or failure of transactions, not their precise order.</p>
<p>We need consensus on generating a bounce, which is a rare event.&nbsp; What about the problem of attributing a time bucket to a transaction.&nbsp; I guess we generate the checksums for a time bucket sometime after that bucket, and transactions that do not make it into the appropriate bucket get discarded by consensus with a recommendation to retry.</p>
<p>Each shard should be an accounting entity, tracking the total transferred between each shard – which should follow from commutativity – should be a detail of optimizing for commutativity.</p>
<p>See also <a href="http://www.cs.yale.edu/homes/aspnes/pinewiki/Paxos.html">failure detection</a> – we would like to know what entities are currently responsive and who was leader and designated learner last time.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

215
docs/crypto_currency_transaction_volume.html Normal file
View File

@ -0,0 +1,215 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Transaction Volume</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Transaction Volume</h1>
<hr/>
<h2>Total number of bitcoin transactions </h2>
<p>Was four hundred million on 2019-05-04, occupying four hundred gigabytes
on disk. I don’t know how many spent and unspent transaction outputs that
adds up to, but probably a billion or two. Thus a hash table mapping coin
public keys to transactions occupies 64 bytes for each coin, so fits in
couple of hundred gigabytes. Not a huge problem today when four terabyte
hard disks are standard, but in early versions of our competing rhocoin
system, simpler just to store all transaction outputs in an sqlite3
database, where an unspent transaction output goes in a table with a field
linking it to its transaction, and a spent transaction output goes in
another table with a field linking it to the transaction from which it is
an output, and the transaction to which it is an input. Each transaction
will be part of the canonical Merkle-patricia tree, but the transaction
outputs will not in themselves be – a proof that a transaction output is
valid or invalid will work by will contain the hash chain deriving from
the transaction, in transactions ordered by block number, and within blocks
by hash.</p>
<p>But our canonical tree is going to have to contain namecoins ordered by name order, rather than transaction order, to enable short proofs of the valid authority over a name.</p>
<hr/>
<h2>Bandwidth</h2>
<p>A bitcoin transaction is typically around 512 bytes, could be a lot less:&nbsp; A transaction needs a transaction type, one or more inputs, one or more outputs. A simple input or output would consist of the type, the amount, the time, and a public key. Type sixteen bits, time forty eight bits bits, amount sixty four bits, public key two hundred and fifty six bits, total forty eight bytes.&nbsp; A typical transaction has two inputs and two outputs, total 192 bytes. Frequently need another hash to link to relevant information, such as what this payment is for, another thirty two bytes, total 224 bytes.&nbsp;</p>
<p>We will frequently store the transaction and the resulting balances, as if together, though likely for internal optimization reasons, actually stored separately, so 196 bytes.&nbsp; </p>
<p>Visa handles about 2000 transactions per second.&nbsp; Burst rate about four thousand per second.&nbsp; </p>
<p>Paypal 115 transactions per second.&nbsp; </p>
<p>Bitcoin four to seven transactions per second.&nbsp; </p>
<p>So, to compete with bitcoin, volume ten kbps.&nbsp; </p>
<p>So, to compete with paypal, volume two hundred kbps.&nbsp; </p>
<p>So, to compete with visa, volume six mbps.&nbsp; </p>
<p>My home connection is fifteen mbps up, forty five mbps down.</p>
<p>Common home internet connections are twelve mbps, common small business internet connections are one hundred mbps.&nbsp; So you will be able to peer with even when we reach Visa volumes, but you probably will not want to unless you are moderately wealthy or you are operating a business, so need a high capability connection anyway.</p>
<p>The i2p hidden network can handle about 30 kbps, so we can put the whole thing on the i2p hidden network, until we are wiping the floor with Paypal.&nbsp; Ideally, we want a client download, a host and peer download, and a business host and peer download, where you just say "install and next thing you know you have a website offering “&lt;item name here> for &lt;99.99999&gt; megaros”. (During initial development, we will fix the price at one megaro per US$)</p>
<p>A peer on a laptop can easily handle Paypal volumes on a typical free advertising supported cofffee shop connection, which is around 10mbs down, 5mbs up. We need to allow peers to drop in and out. If you are a client, and the peer that hosts you drops out, you can go to another peer and ask another peer to host your wallet. If you are doing seriously anonymous transactions, well, just bring the laptop running your peer to the coffee shop.</p><p>
Assuming a block happens ever five minutes, then visa is three hundred megabye blocks, 8Mbps.</p><p>
Paypal is ten megabyte blocks, 0.5Mps.</p><p>
Bitcoin is one megabyte blocks, 28Kbps.</p><p>
After two years at bitcoin volumes, our blockchain will be two hundred gigabytes, at which point we might want to think of a custom format for sequential patricia trees as a collection of immutable files, append only files which grow into immutable files, and wal files that get idempotently accumulated into the append only files.</p><p>
Initially, our volume will probably only be one transaction every thirty seconds or so, at which rate it will take two years to reach a gigabyte, and everything fits in memory, making thinking about the efficiency of disk access irrelevant. We just load up everything as necessary, and keep it till shutdown.</p><p>
During initial development, need an ICO, including a market place buying and selling megaros.&nbsp; </p>
<hr/>
<h2>Sorting</h2>
<p>Suppose two thousand transactions per second, one kilobyte per transaction, block time of two hundred and fifty six seconds. That is half a gigabyte per block, easily held all in ram in native format. Then, when block finalized, we write the block to disk in sorted order as serialized pod objects, with a range algorithm for randomly accessing the desired 4KB block within the 500kB block. For the uniformly distributed part of the address space, you guess which 4K block and hit it up to find an index at the 4K block boundary.</p>
<p>For the initial release, all these smarts about four K block boundaries are overkill. We assume the upper parts of the tree are already in memory as native form objects, and proceed directly through the densely packed sorted disk data to get whatever part of the tree we care about into memory.</p>
<p>We have a tree of native objects in memory. If we are running short of room, free them up, and restore them on demand by going through the compressed serialized pod objects.</p>
<p>We then have a mechanism for efficiently accessing a node by its key, but not however by its hash, except in the common case that the key of the node reflects the hash of the subnode that it signs.</p>
<p>Since we sort stuff onto disk in patricia order, quicker to look stuff up by index than by hash, since objects with similar indexes will be near each other.</p>
<hr/>
<h2>Storage</h2>
<p>Instead of only keeping transactions, we keep transactions and accounts. Thus peers can place old transactions in offline storage, or just plain dump them. The hash tree ensures that they are immutable, but you don’t actually have to keep old transactions and old account balances around. Thus, total chain volume bounded. We can replace branches of the Merkle tree in old blocks that lead only to used transactions by their hash – we operate with a potentially incomplete Merkle-patricia dac</p>
<p>On the other hand, perhaps I worry too much about disk storage, which has been doubling every year. Since we only plan to have a thousand or so full peers, when we have seven billion client wallets, they will be able to afford to store every transaction for everyone ever. Visa volume of 2000 transactions per second implies fifty gigabytes per day. So, if when we reach visa volumes, a typical peer has sixteen disks each of sixty four terabytes, it will take fifty years to fill them up, by which time we will likely have figured out a way of ditching old transactions.,</p>
<p>Suppose we have a thousand peers, and seven billion clients, and each client wants ten thousand transactions stored forever. Each peer has to store forty thousand terabytes of data. Each peer has seven million clients, so each peer is going to be quite large business, and by that time standard hard disks will probably be about one hundred terabytes, so each peer is going to need about four hundred hard disks on a local network of a hundred computers, twenty thousand clients per hard disk, which is not going to be a burdensome cost – other scaling problems will no doubt bite us hard before then. At present two hundred terabyte systems are common, though not among private individuals. Forty thousand is gigantic, though perhaps it will be less gigantic in a few years. OpenZFS handles hundreds of terabytes just fine. Not sure what will happen with tens of thousands of terabytes.</p>
<p>The trouble with disk storage is that sector failure rates have not been falling. When one sector fails you tend to lose everything. One bad sector can take down the disk operating system, and one bad sector will take down an Sqlite database. We can mitigate this problem by having several Sqlite databases, with the most active blocks in solid state drive storage, and the immutable consensus blocks (immutable in having root hashes that have been the subject of consensus, though they can lose some branches) spread over several very large disk drives. Perhaps Sqlite will address this problem, so that bad sectors only cause minor local losses, which can easily be replaced by data from another peer, or perhaps when we get big enough that it is a problem we will then write a system that directly writes Merkle-patricia dac to raw disk storage in such a manner that failed sectors only cause minor losses of a few elements of the Merkle-patricia dac, easily fixed, by getting replacement data from peers.</p><p>
The way Sqlite works at present, having all our data in one big Sqlite database is not going to work when the block chain gets too big, no matter how big disks become, for sooner or later one sector will fail, and we don’t want the failure of one sector to require a full rebuild of a potentially gigantic database.</p><p>
A data structure that dies on the loss of one sector becomes unusable when it reaches two terabytes or so, and the trouble is that our existing disk operating systems, and databases such as Sqlite, are frequently fragile to the loss of single sector. To scale to our target size (every transaction, for everyone in the world, forever) we have to have a system that tolerates a few sectors dropping out here and there, and replaces them by requesting the lost data on those few sectors from peers. For the moment, however, we can get by using multiple Sqlite databases, each one limited to about six hundred gigabytes. They will die infrequently, and when they die, the peers should reload the lost data from other peers. The cost of disk sector bitrot increases as the square of the size of the Sqlite database, because the likelihood of the entire database dying of bit rot of a single sector increases proportionally to size, and the cost of recopying the data from peers increases proportionally to the size. Lose one sector of an Sqlite database, you may well lose the entire database, which is an increasing problem as disks and databases get bigger, and likely to become unbearable at around two to four terabytes.</p><p>
But for the moment, three six terabyte drives don’t cost all that much, and with split databases, with some blocks in one Sqlite database, and other blocks in another, we could scale to twenty times the current size of bitcoin storage, and when we hit that limit, solve the problem when it becomes a problem. We don’t really need to purge old transactions, though we build the architecture so that it is doable.</p>
<p>The architecture is that it is all one gigantic Merkle-patricia dac organized into blocks, with the older blocks immutable, and the way this data is stored on a particular peer is an implementation detail that can differ between one peer and the next. Each peer sees the other peer’s Merkle-patricia dac, not the way the other peer’s tree is stored on disk. It sees the canonical representation, not the way the particular peer represents the tree internally.This approach enables us to be flexible about storage as technology progresses, and as the amount of data to be stored increases. Maybe we will wind up storing the tree as architecture dependent representations of records written directly to raw disk sectors without any file system other than the tree itself. By the time sector bitrot becomes a problem, Sqlite may well be fixed so that it can lose a bit of data here and there to sector bitrot, and report that data lost and in need of recovery, rather than the entire database dying on its ass. And if not, by the time it becomes a problem, the community will be big enough and wealthy enough to issue a fix, either to Sqllite, or by creating a disk system that represents arbitrarily large Merkle-patricia dacs directly on disk sectors over multiple disks over multiple computers, rather than a database stored on files that are then represented on disk sectors.</p><p>
For a database of two terabytes or so, can keep them in one Sqlite database, though probably more efficient to have tha active blocks on a solid state drive, and the older blocks on a disk drive, running on top of a standard operating system. Eight terabytes can store two billion transactions, which will fail horribly at handling all the world’s transactions, and can only keep up with visa for a few days, but we can keep up with paypal for long enough to hack up something that can handle massive disk arrays, and ditches stale transactions.</p><p>
Assume clients keep their transactions forever, peers keep their own client transactions for a long time, but dump the transactions of other clients after a month or so.&nbsp; </p>
<p>Then to compete with Bitcoin, need about three gigabytes of storage, ever, about the size of a movie.&nbsp; Typical home hard disks these days are one thousand gigabytes.&nbsp; </p>
<p>Then to compete with Paypal, need about fifty gigabytes of storage, ever, about the size of a television series.&nbsp; Typical home hard disks these days are one thousand gigabytes.&nbsp; </p>
<p>Then to compete with Visa, need about one terabyte of storage, ever, about the size of a typical home consumer hard disk drive.&nbsp; </p>
<p>So when we are wiping the floor with visa, <em>then</em> only wealthy people with good internet connections will be peers.&nbsp; </p>
<p>If keeping only live transactions, and assume each entity has only a hundred live transactions, then an eight terabyte hard drive can support a billion accounts. Paypal has about three hundred million accounts, so we can beat paypal using Sqlite on standard disk drives, without doing anything clever. And then we can start correspondent banking, and start using a custom storage system designed to support Merkle trees directly on raw disks.</p>
<p>If we put a block chain Merkle tree oriented storage system on top of Sqlite, then we can shard, write direct to disk, whatever, without disturbing the rest of the software, allowing us to beat visa. We always query the Merkle tree of the current block, with most of the lower branches of the Merkle tree pointing back into previous blocks. So if you ask, what is the record whose identifier is such and such in the current block, you will probably get the answer, "it is record such and such in a previous block", which will likely go through several steps of recursion, as if we had a billion sqllite databases. And why not have a billion Sqlite databases, in which a hundred are in one sqllite database, and hundred in another? And many processes. If we have one block every 256 seconds, then in ten years we have a million blocks, and a table locating each block in some arbitrary place, associated with some arbitrary channel to some arbitrary process is manageable, even without the trival optimization of handling ranges of blocks. This implies that once a block is immutable, it is handed off to some process whose job is to resolve read only Merkle queries on blocks on a certain range. So we have a table locating immutable blocks, and the processes that can read them, which allows us to trivially shard to many databases, each on its own hard disk, and near trivially shard to clusters of computers. Assume a per peer table that assigns groups of blocks to directories on particular disks on particular hosts with only one of these groups being mutable. Then we can have shardable storage on day one. And assume we can have multiple processes, some responsible for some blocks and some responsible for others. Each peer could be a large local network over many machines. Of course, we are still potentially bottlenecked on assembling the current block, which will be done by a single cpu attached to single local disk, but we are not bottlenecked for disk space.</p>
<hr/>
<h2>Storage and transmission structure</h2>
<p>We will not have a Bitcoin style chain of blocks, instead a binary Merkle-patricia dac.&nbsp; But operations on this tree will be grouped into 256 second phases so we will be doing something very like a block every 256 seconds. (Or whatever time the global consensus configuration file specifies – there is global consensus config data, per peer config data, and per client config data, all of them in yaml.)</p>
<p>For block syncronization we need a tree of transaction events organized by block, hence organized by time, at least for the high order part. To prove balance to a client without giving him the entire tree, need a tree of balances. To prove to a client name key association, need a tree of names. To prove no monkey business with names, need a tree of events affecting names organized by names. To prove no monkey business with balances, need a tree of transactions organized by client. ((Leaves on the tree of transactions would consist of the key to the actual transaction) And, of course, a rather trivial tree to hold the global config data. There will be a chain of leap seconds in anticipation of the day that the standards authorities pull their fingers out of their ass. The leap second data has to be signed by an authority specified in the global configuration data, but this will serve no actual useful function until the day there really is such an authority. For the moment the world represents time as if leap seconds never happened, as for example in communication between mail servers, and no one cares about the precise value of durations – it only matters that time is monotonic and approximately linear.</p>
<p>When we want more precise time comparisons, as when we are synchronizing and worried abouth the round trip time, we just get data on both computer’s clocks as relevant and give up on a global true time. So if one computer ticks a thousand times a second, and the other two fifty six times a second, then, for round trip concerns, no biggie.</p>
<p>Data will be ordered, both in storage and transmission, by key, where the high order bits of the key are block number, which is the high order bits of the time. Transactions are applied according to the time designated by the sender, rounded to some multiple of a thousand milliseconds, and then the public key of the recipient. Order in which transactions are applied matters for bouncing transactions. Transactions between the same sender and the same recipient shall be limited to one per block period. If someone wants to transact more often than that, has to batch transactions using the microtransaction protocol. For internal optimization, there will be additional indexes, but that is what we are going to hash over, and that will be the order of our hash tree, our storage, and our transmissions.&nbsp; </p>
<p>Our global hash will be a binary Merkle-patricia dac of hashes, with the leaf hashes corresponding to the above.&nbsp; </p>
<p>We use two kinds of time – millisecond time modulo 2^32 for managing connections, and second time for times that go into the global consensus block chain.</p>
<p>C++11 <code>std::chrono::</code> seems to be the library that actually fixes these problems, with a steady clock for duration, which we will access in milliseconds modulo 2^32, and a system clock which we will access for global time in seconds since the epoch modulo 2^64</p>
<p>Both kinds of time ignore the leap second issue. Whenever seconds are presented for human readership, then ISO 8601 format which evades the leap second issue. Whenever durations are employed internally, we use milliseconds past the epoch modulo 2^32, and do not assume computer clocks are synchronized, or even both running at the same rate, though we do assume that both are measuring something rather close to milliseconds.</p>
<p><code>boost::posix_time::ptime</code> sucks.</p>
<p>We give up on handling leap seconds until the standards people get their act together and make it easy for everyone.</p>
<p>Time will be stored as a binary UT1 value, and not stored as local time. When displayed for humans, time will be displayed as if UTC time, in accordance with <a href="https://www.ietf.org/rfc/rfc3339.txt">RFC 3339</a> though it is actually an approximation to UT1. If the data is being displayed to the local user momentarily, will be displayed as local time plus the offset to UT1, for example 2019-04-12T23:20:50.52-5:00, representing 2019 April the twelfth, 8:50.52PM UT1 time in New York. If the data is not just being displayed momentarily, but will be recorded in a log file, it will always be recorded as UT1 time, as for example 2019-04-12T15:50.52Z, not UT1 time plus local time offset, because humans are likely to compare log files in different time zones, and when looking at logs long after the event, don’t care much what the local time was.</p>
<p>If we are recording the local time plus offset, remember that confusingly 1996-12-19T15:39:57-08:00 means that to get universal time from local time, we have to add eight hours, not substract eight hours.<br/>
<code>1996-12-19T15:39:57-08:00</code> is, surprisingly and illogically, the same moment as:<br/>
<code>1996-12-19T23:39:57+00:00</code> add it, don’t subtract it.</p><p>
<code>1996-12-19T24:00:00+00:00</code> is, unsurprisingly and logically the same moment as:<br/>
<code>1996-12-20T00:00:00+00:00</code></p>
<p>We can store in any format, and transmit in any mutually agreed format, but the protocol will hash as if in full length binary. Any protocol is transmitting representation of the binary data, which should be uniquely and reversibly mapped to a human representation of the data, but we do not need global agreement on a human representation of the data. Because multiple human representations of the data are possible, any such representation should contain an identifier of the representation being used. Similarly storage and transmission.&nbsp;. Since global agreement on storage, transmission, and human representations of the data is not guaranteed, format identifiers for storage and transmission formats such will be 128 bits in the binary representation. Human readable formats will be in yaml.&nbsp;</p>
<p>For a hash to be well defined, we need a well defined mapping between a yaml text stream, and a binary stream. A single yaml document can have many equivalent text representations, so we have to hash the binary data specified by the yaml document. Which means a yaml document must be stored in an object of specific type defined outside the document, and we hash the canonical form of that object. The object type will be identified by a yaml directive %<code>&lt;typename&gt;</code>, and if the named fields of the yaml document fail to correspond to the location fields of the binary object, it is an error, and the document is rejected.&nbsp;</p>
<p>The yaml document representing a binary object has a human readable type name in the form of a percent directive, and human readable field names in the form of a mapping between namesd values, but the binary object it represents does not contain these field names, and its type identifier, it has one, is an integer.&nbsp; The mapping between human readable names in the yaml document and offset locations within the binary object occurs outside the object, and outside the yaml document.&nbsp;</p>
<p>Different compilers tend to wind up implementing object padding differently, and of course there is always the endianness issue, big endian versus little endian. For a binary object to have one unique representation really requires ASN.1.&nbsp;</p>
<p>ASN.1 can generate aligned Canonical Packed encoding, which is what we are going to need to hash, and aligned packed encoding, which is what we will need for everything except human readability.&nbsp; It can also generate JSON encoding rules, which is type information in JSON, which we manually edit into a human readable description of how the object should look in yaml, and manually edit into a yaml to and from Canonical Aligned packed encoding.
For the data represented by a yaml document to have a unique well defined hash, the yaml document has to reference an ASN.1 specification in a percent directive. Try the III ASN.1 Mozilla library to compile ASN.1 into C++. Our yaml library should generate code to read yaml into and out of an object whose representation in memory is compiler and machine dependent, and our ASN.1 library should generate code to read data into and out of the same object whose representation in memory is compiler and machine dependent.&nbsp;</p>
<p>A connection between two peers will respresent the data in a ASN.1 PER format, but not necessarily canonical aligned PER format. The representation will be idiosyncratic to that particular connection. Every connection could use a different representation. They probably all use the same representation, but nothing requires them to do so.&nbsp;A machine could have a hundred connections active, each with a different representation, though it probably will not.&nbsp;</p>
<p>A branch our immutable binary tree, or the portion of the entire global immutable tree leading to a particular branch, can be output as yaml, or input from yaml in order that we can figure out what the machines are doing, and when we read a branch in yaml, we can always immediately learn whether than branch chains to the global consensus, albeit a portion of that chain may run through a local wallet, then to a transaction in that wallet, which transaction is globally known.&nbsp;</p>
<p>Our immutable tree can only contain types known to the code, and compiled into the code. ASN.1 and yaml can represent arbitrary structures, but our code will not be able to handle arbitrary structures, and shall swiftly reject lots of valid, but unexpected, yaml, though a wallet might well know types that are not globally known. ASN.1 canonical aligned PER can only represent types that are expected by the code, thus everything that can be read, has to be expected and capable of beig handled by canonical aligned PER.&nbsp;</p>
<p>A conversation involving many people is a tree in reverse temporal order to hash tree. However, we are only going to link such conversations into the block chain in relation to a financial transaction, in which case we want to link it in hash chain order – the bill or offer, and any documents explicitly included in the bill or offer. Texts in chat contain a time, an author, a chatroom identifier, and that they are a reply to a previous text. Constructing a tree forward in times involve a search for all replies.&nbsp; It is not stored in tree form, texts do not contain links to what replies to them.&nbsp; Within wallet storage such a text is globally identified by its hash. Which is globally meaningful for any participant in the conversation. Of course for payments, there are usually only two people in the conversation, but if a text is referenced by a transaction in the global consensus chain, you can send it to anyone, and what it is a reply to, and what that it is a reply to, whereupon they become meaningful, and immutable, for the recipients. So you can send a text to a third party that includes another text, or several such texts. If you include a third party text, and what this third party text is a reply to, then the reply link will become meaningul to the recipient. Otherwise, when he clicks on the reply link, will get an error. The wallet contains a bunch of records that are indexed by hash, the hash globally and uniquely identifying immutable data. Texts are almost free from, having a time, an orginator, a title of under 140 characters, which is likely to be the entire content of the text, and a destination, which may be a chatroom, or a particular sutype of chatroom, a chatroom with only two permitted members, and free form text which may contain references to other texts, generally in the form of a quote or title, which links to the actual prior in time text.&nbsp;</p>
<p>Clicking on the link expands it inline with a four tab indent, and a tree outline rooted on the left. If the tree gets too deep, say four tabs deep (configurable) we collapse it by hiding sister expansions, collapsing parent nodes, and applying tail recursion.&nbsp; The tree of a conversation thread is similarly displayed, also in correct time order (collapsing and tail recursing as needed to prevent it drifting too far right) but it is not a hash tree, and you cannot link it into the block chain.&nbsp; You can only link a particular text, and prior texts that it explicitly includes by hash, into the blockchain.&nbsp; Only their root hash is actually stored in the blockchain.&nbsp; The actual texts, though their hash globally identifies them across all wallets, are only stored in some particular wallets, and can easily wind up lost or erased.&nbsp;</p>
<p>When peers negotiate a protocol, they negotiate a representation of the data, which may be different for any pair of peers, but what is being represented is globally agreed.&nbsp; </p>
<p>What is being represented is a global binary Merkle-patricia dac of blocks of variable length binary data. In transmission we generally do not transmit the entire hash if the entire subtree is available, but a sample of the hash, which sample is different in every connection between every pair of peers. This means that a peer cannot easily fake keeping the data. Since the entire tree represents a global consensus, the content of every block must be understandable to every peer so that every peer can determine that every block is compliant with the global rules, so every block begins with a type identifier, which normally defines a fixed length for the block and the rule for generating a hash for that block. The tree never carries opaque data, though it may well carry a hash code that identifies off block chain opaque data.</p>
<p>Whatever protocol is employed, the software can and will routinely express the representation in its global canonical binary form, and in human readable form, so that when disagreements occur in reaching consensus the human masters of the machines can agree on what is going on and what should be done about it, regardless of the representation used internally to store and transmit data..&nbsp; </p>
<p>Although the consensus will be represented by both a human and a robotic board and CEO, there shall be no automatic rule update mechanism, except according to individual human choices. Each new consensus shall represent a consensus of peers managing a majority of the shares, and to change the rules will require that the board and the CEO persuade a substantial majority of the human masters of the peers to install new software, which they may do, or may refrain from doing.&nbsp; The consensus will be continually updated according to robotic choices, but the rules the robots are following are installed by humans – or not.</p>
<p>During each block period, peers will be accumulating and sharing transactions for the current and previous block periods.&nbsp; </p>
<p>They will be trying to reach consensus for earlier block periods by sharing transactions <em>or by excluding transactions that did not get widely shared.&nbsp;</em> </p>
<p>They will attempt the Paxos protocol to announce a hash reflecting a widely shared consensus for block periods before that (more than three block periods before the present), starting with the block for which no widely shared consensus has yet been announced..&nbsp; </p>
<p>So, they don’t even attempt to announce a consensus until ten minutes at the earliest.&nbsp; </p>
<p>When a consensus exists for the previous block period, the hash is performed as if each transaction was associated with the resulting account balances, and as if the transmission of a transaction was transmitted with the ensuing account balances, though for internal optimization reasons, they are not necessarily stored or transmitted in this fashion.&nbsp;</p>
<p>This potentially allows a peer to throw away all data on which there is a consensus, except the most recent transaction balances and key names, since clients rely on local storage to prove a transaction has taken place, and what it was for.&nbsp; The peer has to prove to clients that the recent balance changes were correct, so has to keep those transactions and show them on demand.</p>
<p>A peer must be able to produce any block related to a client that was generated while that client was hosted by the peer, and any block that is part of a very recent consensus, so cannot throw those away, but is only required to produce the hashes linking that to the global hash, not required to produce any block that ever there was.&nbsp; </p>
<p> A client’s wallet should contain all blocks relevant to that client, and all hashes relating those blocks to the global hash, but if for some reason, for example back up and restore, his wallet does not, and he changes hosts, part of his history may simply become inaccessible.&nbsp; Everything shall continue to function correctly, even if that portion of the history is forever lost to everyone, and represented only by a hash, with the items that the hash represents forever lost.&nbsp; He will know his balance is such and such, but how it came to be such and such may be forever lost.</p>
<p>For reasons of speed efficiency, we will maintain a table of accounts, and several tables of transactions one of them ordered by recipient, one them by sender, but the system shall act as if we had a single table, in which transactions held balance data and links to the previous transactions for both accounts, and hashes shall reflect this fictitious and storage efficient but speed inefficient structure.&nbsp; </p>
<p>We shall locally employ 64 bit hash tables of 256 bit quantities, wherever a 256 bit quantity would otherwise have to be internally stored multiple times.&nbsp; </p>
<hr/>
<h2>Micro and nano transactions</h2>
<p>Micro and nano transactions are trust based.&nbsp; </p>
<p>In nano transactions, the parties keep a running tab, but do not generate any unforgeable cryptographic record of the tab. If something goes wrong, the wronged party breaks the connection, and temporarily blocks the other party.&nbsp; </p>
<p>From time to time, they record the tab into a micro transaction, one or both parties cryptographically sign.&nbsp; </p>
<p> Between any two parties there can only be one tab, and only one tab record can be entered into the global consensus in any one time period.&nbsp; </p>
<p>Each party knows his tabs most recently recorded in the global block chain with all other parties – they have a local image of the part of the global block chain that is relevant to themselves.&nbsp; </p>
<p>If there is no existing tab, the parties agree to start it at zero.&nbsp; From time to time the party being billed signs a new tab balance. If both parties are being billed, if the balance moves both up and down, they both independently sign it.&nbsp; </p>
<p>When a tab record is entered in the block chain, that transfers the difference between the most recent tab record, if any, and the new tab record.&nbsp; It is just an ordinary transaction like any other, but the payment conversation it chains to records the interaction of the parties, and they can prove it to third parties.; </p>
<p>The parties generate tab records at frequent intervals, but only infrequently submit them to the global block chain.&nbsp; </p>
<p>It may well happen however, that when the tab record goes into the block chain, there is no money to pay. When this happens the defaulting party’s cannot make expenditures until the money is paid – his account is locked until more money goes into it.&nbsp; (Which will probably never happen, so we want to minimize storage associated with such accounts.)&nbsp; But this does not in itelf do much good, since identities are extremely cheap.&nbsp; </p>
<p>To generate positive reputation, an account must have existed for a long time with positive money and no defaults, which is not cheap, and must have made payments to lots of other accounts which have existed for a long time with positive reputation, which is also not cheap.&nbsp; But how does this square with throwing away the records?&nbsp; </p>
<p>A user’s wallet and host retains his positive records, and the global blockchain only keeps the most recent default, forever, or for a very long time before altogether throwing away the dud account.&nbsp; The wallet knows what has gone into the global chain, and keeps a record of what should go into the global chain, and the normal wallet refrains from any micro or nano transactions that would result in default.</p>
<hr/>
<h2>Zooko’s quadrangle, human readable names</h2>
<p>The root of the identity of every client and peer will be a public key, or the hash thereof. A client can reserve a human readable name, provided that they have &lt;<code>name_reservation_deposit</code>&gt; amount of money in the account.&nbsp; </p>
<p>The client UI will not let the user accidentally spend this money and lose the name, so it will be presented separately from the rest of his balance. A peer has to have such a name, which is also the name of the special client account that controls the peer.&nbsp; </p><p>
Retaining a human readable username require a minimum balance, which may be changed from time to time with due warning. This implies global consensus on a configuration YAML file. We have a rule that a new configuration file takes effect &lt;<code>transition_time</code>&gt; days after being voted in, provided that it is never voted out in the meantime, where &lt;<code>transition_time</code>&gt; is a value set by the configuration file currently in effect.&nbsp; </p><p>
You can reserve as many names as you please, but each requires a not altogether trivial amount of money.&nbsp; </p><p>
You can sell a username to another public key.&nbsp; </p><p>
The blockchain keeps the usernames, the owning key, and keeps the host for the owning key. You have to ask the host for further details, like contacting the actual owner of the user name.&nbsp; Host links you to the wallet, wallet links you to a small graphic, a 140 character text, optionaly a larger text, and a web page.&nbsp; The guy who controls the web page will be able to create a websocket connection to his wallet that logs you in, and sends messages to both wallets.&nbsp; </p><p>
You can look up something like a blog page of the user, which blog page is not necessarily kept on the host. You can message the user, but unless you get on the whitelist, this involves a very small fee.&nbsp; </p><p>
You can also access a chatroom, by invitation, or by knowing the chatroom name and a shared secret. Messaging someone creates a chatroom to which the sender and all recipients have access, to which any party can give a name and a shared secret, or invite others. If you message some people in the chatroom but not others, you create a new chatroom, which forms a tree of chatrooms.&nbsp; </p><p>
The point, purpose, and intent of this infrastructure is to enable secure encrypted conversations, and to allow people to make and accept offers within the system. Chat with money.&nbsp; But we want to integrate with the web, after the fashion of the payment processor. You send the client, and his order, to the payment processor, and the payment processor comes back with a page hit saying he has paid for order such and such.</p><p>
The browser is inherently insecure, so your wallet client will allow encrypted non html secured chat. It will also provide a websocket connection (socketio) so that web pages can deal with it.</p><p>
It is useless to attempt immutable records of html pages, since they can, and do, mutate according to circumstances. We can, however, create immutable records of pdf pages, which should live, not in the blockchain, but in the wallet’s associated directory tree. HTMLDOC will convert html to pdf. The wallet, the client, and the blockchain, will set up a browser server connection between two blockchain names, but anything that is going to chain into the blockchain, such as a record of what is being paid for, cannot be html. All html data and authentication shall be transient, shall be local to the parties, and shall go away at end of session. If a web page wants to create a durable record for the wallet, has to be pdf, plain text, or YAML plain text. (Which it sends to the wallet by websocket or socketio.)</p><p>
To get a logged on browser to server connection between two blockchain identities, your wallet client will talk to the other guy’s wallet client, which will talk to his webserver, and your wallet will launch the browser with a regular https connection with logon cookie representing that a browser obeying a wallet with one blockchain key is logged on to a webserver that obeys a wallet with the other blockchain key.</p><p>
When the time comes to do a transation, the wallet clients will exchange encrypted non html messages, in response to websocket messages by browser and webserver, and the payment will be linked to one such signed message, held off blockchain by both parties in their wallets. Logging on will always be done in the blockchain client, not the browser and the keystroke that actually agrees to make the payment will be done in the blockchain client, not the browser.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

175
docs/cypherpunk_program.html Normal file
View File

@ -0,0 +1,175 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
p.center {
text-align:center;
}
</style><title>The Cypherpunk Program</title></head><body>
<p><a href="./"> To Home page</a> </p>
<h1>The Cypherpunk Program</h1><p>
Timothy C. May summarized the plan as</p>
<blockquote><p>
“Crypto Anarchy: encryption, digital money, anonymous
networks, digital pseudonyms, zero knowledge,
reputations, information markets, black markets,
collapse of government.&nbsp; </p></blockquote><p>
Which is intentionally obscure.&nbsp; The plan is to strike
at the state from the jungle of complexity, to strike at
the state from beyond the state’s intellectual and
temporal horizons.&nbsp; The evil minions of the state will
not be coming after cypherpunks, because they will not
understand what cypherpunks are doing, and because when
things start going bad for them the will not be able to
link cause and effect.&nbsp; </p><p>
Cryptography alone is insufficient to implement
crypto-anarchy.&nbsp; Correct understanding and
implementation of cryptography has proven to be hard, as
numerous embarrassing failures have demonstrated, but
correct understanding and implementation of cryptography
turned out to be only the beginning of what was
needed.&nbsp; </p><p>
Often secure cryptographic algorithms have been used to
construct insecure cryptographic protocols, as for
example the wifi protocol WPA personal, but worse than
that, correct cryptographic protocols, such as SSL, have
resulted in insecure behavior, because the protocol flow
failed to fit the user’s task flow. </p><p>
Successfully designing such systems requires a whole
system viewpoint – cryptographic protocols <em>and</em>
user interface <em>and</em> business models <em>and</em>
accounting principles <em>and</em> economic understanding
<em>and</em> understanding of computer mediated social
networking.&nbsp; </p><p>
The cypherpunk movement collapsed in the realization that
the problem was harder than it seemed, that mere
cryptography was insufficient.&nbsp; </p><p>
The cypherpunk movement produced a lot of cryptographic
tools, among them by own Crypto Kong, only to realize
that no one wanted <em>cryptographic</em> tools.&nbsp; To
use a <em>cryptographic</em> tool, you have to
understand and think about what it is doing, understand
and think about the cryptographic primitives involved
every time you use it.&nbsp; Unfortunately, even committees
of experts tend to screw up when they attempt to
specify correct use of cryptographic primitives.&nbsp; For
example the Wifi consortium got it badly wrong, then
having discovered their error as large numbers of
people started freeloading on other people’s wifi,
proceeded to get it wrong again.&nbsp; Then they yet
another try, and proceeded to get it wrong all over
again.&nbsp; The latest incarnation of Wifi, as I write this,
is WPA personal which is vulnerable to offline
dictionary attack, an attack that has been well known,
well understood, and the solutions to it well known for
a very long time.&nbsp; Similarly for DNSSEC, and IPSEC,
where time after time they got the cryptography correct,
unlike Wifi, but managed every time to produce non
solutions that no one could use or would use.&nbsp; </p><p>
No way can end users be expected to burden themselves
with such a task, when the experts fail over and over.&nbsp;
Rather, cryptography needs to be embedded invisibly in
tools that do user tasks, and make those tasks secure
without the end user ever thinking about cryptography.&nbsp;
SSH is the best example of a tool that works like this.
You never see a dialog box that relates to cryptographic
matters.&nbsp; It is just secure.&nbsp; It acts the way people
expect it to act, and they don’t need to think about
the messy details of how it ensures that hostile
adversaries cannot meddle and make things fail in
unexpected ways.&nbsp; Similarly, Skype’s encryption is
invisibly embodied in a utility that people use to
communicate with each other, and no one should ever be
aware of it.&nbsp; </p><p>
If people use secure tools to mediate cooperation, and
the storage and creation of value, to do business, then
those tools will not only be secure against ordinary
criminals, but against governments – whereupon it becomes
hard for governments to collect taxes or regulate business,
hard for governments to intrude themselves in honest
peaceful activities.&nbsp; </p><p>
As soon as we produced the first not very satisfactory
versions of such tools, and early adopters came to use
them, we hit the second problem.&nbsp; The cypherpunk
program requires heavy reliance on value, exchange, and
promises to pay and deliver being computer mediated.&nbsp;
But computers are extremely insecure.&nbsp; One’s
computer is apt to come under the control of hostile
criminals.&nbsp; The computer virus and Trojan problem
makes it impractical to keep large amounts of value on
a computer.&nbsp; Similarly, the phishing problem makes it
difficult to have internet mediate relationships of
economic value.&nbsp; The anonymity that gives protection
against governments makes it alarmingly easy for people
to pretend to be what they are not.&nbsp; And then
we discovered that net centric anonymous or weakly
nymous money was violently unpopular because of
criminals flocking to it, provoking governments to shut
it down.&nbsp; </p><p>
And so, the cypherpunk movement collapsed.&nbsp; The remaining cypherpunks patiently
studied solutions to these problems, and, by and large,
solutions have been discovered, though these solutions
are not yet implemented, or the implementations are
not yet widely adopted, perhaps not yet ready for
wide adoption.&nbsp; </p><p>
The problems that shut down the cypherpunk movement are
</p><ol><li>Cryptography is hard, cryptographic protocols
that actually work are harder, and embedding those
protocols invisibly in utilities that do useful things
without the end user needing to know or think about
cryptography considerably harder still: To solve this we
need <a href="replacing_TCP.html">higher level tools
which automatically apply known sound protocols to the
particular case</a>, so that good cryptography can be a
routine and invisible part of good applications, without
requiring as much thought as it now does.</li>
<li>Computer insecurity, Trojans and malware: To
solve this, we need to restrict programs using the
<a href="./safe_operating_system.html">powerbox software
pattern</a></li>
<li>Phishing</li>
<li>Violently unpopular criminal misuse of net centered
money</li> </ol><p>
Few people use encryption technology today, because few
people have real need of it. </p><p>
Few people have real need of it, because there is no
reasonably liquid net money. People are not making, spending,
transferring, and promising, money through the net, so they
have little need to encrypt their messages or care for the
reputation of their nyms. </p><p>
And that is the big remaining battle and design issue: <a
href="net_money.html">net money</a> though even if we
designed and deployed a satisfactory net money, it would not
come to be widely used for large value transactions until
a <a href="safe_operating_sytem.html">secure operating
system</a> is created and deployed, it can still be created
and deployed for low value transactions such as file
sharing and spam control – one message client would charge
a very small amount to accept messages from people not one one’s white
list. The fee would be refunded if one does not classify
the message as spam.</p>
</body></html>

119
docs/delegated_proof_of_stake.html Normal file
View File

@ -0,0 +1,119 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Crypto currency</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Delegated proof of stake</h1>
<h2>The consensus problem</h2>
In blockchains we call it <em>the consensus problem</em>. In the financial cryptography world, it’s <em>the double spend problem</em>, and in databases, <em>atomicity</em>. Which is to say this is a fundamental problem in all of computing science, not just blockchain.<p>
But with crypto currency, and replacements for the corporate form, we want to solve this problem in ways that prevent someone powerful from capturing the system.</p><p>
Let’s work through the evolution of this problem.</p>
<h3>Centralised Double Spend Protection</h3>
<p>The original mechanism in financial cryptography is the simple client-server or trusted third party (like <a href="http://www.systemics.com/docs/sox/overview.html" rel="noopener">SOX</a>), which is to say that the issuer of a double-spendable value like a coin runs a single server that mediates the double spends. Typically, the requests are queued up on a first in, first out (FIFO) basis, which is standard in databases these days.</p>
<p><img src="https://steemitimages.com/DQmWcZi1t2sDxb5vPqMrxfdf19ebAU8yqSA7XQWKGnswqrJ/DPOS-1-sox-cash.png" alt="SOX – an early digital cash" /></p>
<h3>Voting</h3>
<p>Replicated servers became the in-thing typically for purposes of reliability. For example, the early NASA space shuttles had a voting ring of 3 primary IBM mainframes (and a couple of standbys). On every important act in a voting circle, a majority would win, and a minority could be disconnected and replaced. Early simple majority voting schemes proved to be a lot of trouble, and now the ruling buzzwords are Paxos and PBFT (<em>practical byzantine fault tolerant</em>), but do note that behind them there are lashings of Lamport, theory, bickering Byzantine Generals, PhDs, papers and Turing Prizes, oh my!</p>
<p>Trouble is that the various <em>Byzantine Generals Solutions</em> assume that we know who the generals are. And the mechanism that we use to decide who the Byzantine generals are is going to be subject to centralized attack.</p>
<h3>Proof of Work</h3>
<p>Bitcoin is a brilliant and elegant solution because it opens our thinking to the possibility of fully distributed applications, with money. But Proof Of Work burns up energy to the value that the market can bear, which amounts to a horrible tax on the entire value of the currency (as of time of writing, 4% on Bitcoin, and 11% on Ethereum, big ouch!) and as the Bitcoin chain moves to a fee base this means fees will bite hard, lifting Bitcoin out of reach of most people. High rewards and the rising price also resulted in economies of scale for mining, resulting inevitably in the concentration of miners. Although the system itself happily carries on, a perverse consequence of the censorship-resistant design is that the power of censorship now rests in the hands of about a dozen businesses, with most in one country that is not famous for resisting the urge to censor.</p>
<p>Trouble with proof of work is that lot of money and power is wasted on pointless work.</p>
<p>Right now, Bitcoin is using more electricity than Ireland and minting several billion worth of new currency to process fewer transactions than a moderately busy CostCo.
Obviously, blockchain should work on proof of stake.</p>
Proof of work, to be secure, requires a great deal of work. A great deal of work is going to be inherently expensive, and if you try to keep the cost down to something reasonable, <a href="https://marginalrevolution.com/marginalrevolution/2019/01/bitcoin-much-less-secure-people-think.html">double spending attacks become feasible</a>.
<h2>Proof of Stake</h2>
<p>It was observed by someone (?) that we could simply replace the <em>voting-with-CPU</em> with <em>voting-with-value</em> in order to choose who makes the decision on (the next block of) double-spends. After all, the blockchain precisely establishes who owns what currency, and those who have more skin in the game are more likely to preserve the system, so it is an aligned bias. </p>
<p>I have proposed the following system.</p>
<p>Stake is registered with peers, of which there are a few hundred, which tend to be very large machines with very high bandwidth connections, but stake is owned by clients, who are hosted by peers. Clients tend to be small machines with low storage and low bandwidth connections. Client signatures can move stake from one peer to another. Stake is client money, so that power is ultimately in the hands of the clients, though a peer somewhat resembles a bank from the point of view of clients, and banks tend to acquire dangerously great and disruptive power.</p>
<p>We use Merkle-patricia to somewhat limit the power of the peers over the clients.</p>
<p>Paxos protocol with peers holding fifty percent of stake get to decide on which transactions are committed and which are rolled back.</p>
<p>I also have a plan for making this system anonymous, through transaction pooling, where each transaction is a pool of payments made by several public keys to several other public keys, and the block chain does not reveal which key in the pool were paying which other key in the pool, just the total going in and out, but I intend to publish the full details when I have something working.</p>
<p>Bitcoin payments are pseudonymous, but when money goes in and out of the system, apt to connect pseudonyms to true names, and when bitcoin goes from one nym to another, reveals connections between nyms. Pooling would hide connections between nyms, because you would not know which of the many nyms in the pool was paying which of the many other nyms in the pool. </p>
<p>Because the pools cannot be very large, and will often be quite small, this still leaks some information, giving people trying to follow the money clues and hints, but it leaks far less information than the bitcoin blockchain.</p>
<h2>Let’s go to a Mining Centralisation Conference</h2>
<p>When we look at Bitcoin’s current state of a dozen or so well-known mostly Chinese miners, it is clear that they are all known, to us and to each other, and they can and do communicate. When we get to mining pools the size of today’s country-warming rigs, Bitcoin’s assumption of psuedonymity for miners becomes tenuous – just <em>follow the electricity</em>. Or go to any bitcoin scaling conference.</p>
<p>The miners could easily collude to do bad things. Of course they have no strong incentive to collude to do bad things, since that would damage the value of the currency they mine, but they could easily be forced by the state to do bad things in favor of the state. In particular, and especially, the state is likely to disfavor strong anonymity in the crypto currency. And we want to implement a crypto currency with strong anonymity </p>
<h2>Strong anonymity</h2><p>
Each transaction has many inputs from many participants, and many outputs to many participants, and a possibly hostile outside party cannot tell which input came from which participant, and which output went to which participant.</p><p>
The hostile outside observer might well observe that an output from one transaction appeared as an input in another, and notice that these transactions had only one participant in common, and conclude that was the participant received that output, and subsequently spent it in the second transaction. But that participant may well have several nyms and does not have to have the same identity receiving the transaction as spending the transaction. Likely the pastor will use one identity for receiving his Church stipend, and another identity for paying off the girlfriend who is blackmailing him, and another identity for purchasing grey market drugs over the internet.</p>
<p>All value will be owned by client wallets hosted by peers. A client wallet identity is <code>UserName@PeerName</code> And the client may well use several servers, and have a username on each server, each server being a peer in the crypto currency system, thus crypto currency received on one server will be impossible to connect to crypto currency spent on another server.</p>
<p>Each transaction input/output has its own unique public key that identifies it. If most transactions have only a single payer and single recipent, it is possible observe the flow of transactions and associate a group of transaction input/output with a particular user, and with transactions between those particular users.</p>
<p>If each transaction has several payers and several recipients, you cannot track this on a strictly peer to peer system. But a peer to peer system has scaling problems, so I envisage a system that at scale has a few hundred to a few thousand peer, but billions of clients, which creates the possibility of tracking client logins. If, however, each client has several logins, then a hostile outsider cannot track the flow of money, nor know how much money a particular client has. A hostile outsider cannot figure out which client knows the private keys corresponding to the public keys of the transaction input/outputs.</p>
<h2>Delegated Proof of Stake</h2>
<p>We instantiate the ledger as a Merkle-patricia dac. Each new block of the block chain contains the root of a new Merkle-patricia dac incorporating all the previous Merkle-patricia dacs, and consists of those nodes of the trie that are new and different from the previous Merkle-patricia dac.</p>
<p>The entire state, and entire history of the system is represented by the hash of the root node, and any time a peer makes a claim about some fact of the block chain to a client, it gives the client the chain of hashes leading to the root, proving that this view of what public keys own what transaction outputs and what human readable names is the consensus view.</p>
<p>The new block references all the old trees in a binary trie, so that if any client has the root of an old block, a proof that the new block is derived from the old is only log (current block number – old block number)long.</p>
<p>The client does not verify that the new block is validly derived from the old block, for to verify that it was derived in accordance with the rules requires the entire block chain. Each peer verifies this, which means each peer has to download the entire block chain, and the client relies on the peer with whom it has a login relationship.</p>
<p>Suppose one peer tells one client one story, claims that the consensus root hash is one thing, and another peer tells another client a different story, claims that the consensus root hash is another thing. Then, when the two clients attempt to interact, things will break.</p>
<p>That things do not break guarantees that the peers are all subscribing to the one consensus, that everyone sees the same history of every transaction, and that everyone agrees on which public key is associated with which human readable name, but does not tell us which proposed new block should become the consensus block. It tells us that the past block chain is good, but does not tell us how to add new blocks to the block chain.</p>
<p>Suppose a transaction input is double spent, appears in two different transactions. One transaction must succeed for everyone, and the other fail for everyone. Suppose a human readable name is assigned to two different public keys. One assignment must succeed for everyone, and the other fail for everyone. But which one? And how does everyone know it succeeded or failed?</p>
<p>We will employ the Paxos protocol with distinguished proposer (leader)
<p>Peers have stake in proportion to the crypto currency controlled by their clients. The consensus view has to be approved peers by holding the majority of the stake controlled by active peers who have recently provided evidence of liveness.</p>
<p>Obtaining a consensus is potentially slow and costly, and apt to produce very bad outcomes. How does a group act as one?</p>
<p>The way humans do it, when they do it successfully, is that they choose a leader. They keep an eye on him, but they don’t jostle his elbow. They follow him, until something goes badly wrong. And when things are working, it is as if the leader owns the group. But when something goes bad, then they choose a new leader, and it is then revealed he does not own the group. And that is how the Paxos protocol works. The Paxos protocol is computers on the network coordinating their actions by similar mechanism. Every peer checks the new block, and then votes for it, and if there is nothing terribly wrong, the new block becomes effective when it gets votes represent the majority of stake held by clients with a peer that is active on the network. Normally they only check the block provided by the leader. If the leader goes down (perhaps someone pulled tbe plug, or its network connection went down) then there is a complex, and potentially slow, process for choosing a new block, and with it a new leader.</p>
<p>When all goes well, every peer assumes that the peer that set the consensus last time will succeed in setting the consensus this time, and if there is nothing wrong with the proposed consensus, if it is derived from the previous consensus in accordance with the rules, accepts it as the consensus. When this works, it is as fast as a fully centralized system. And large scale fully centralized systems have to implement failover and multi homing anyway, so even when it fails, is not enormously slower than a fully centralized system that suffers a failure.</p>
<p>If the leader goes down, perhaps due to hardware failure or for maintenance, or there is excessive packet loss on the internet, or if the leader turns evil and proposes a consensus that differs from the rules, is not validly derived from the previous Merkle-patricia dac, then the Paxos protocol with distinguished proposer becomes excruciatingly complex, and potentially slow. But most of the time, it is simple and fast as a simple fully centralized system with redundancy.</p>
<p>On initial release there are only going to be a few peers and a few wallets, but the architecture of the system has to be capable of scaling to billions of wallets and hundreds of peers</p>
<p>All wallets will be client wallets, and will only hold their own transactions and a small part of the block chain. At scale their will be billions of wallets, a few hundred or a few thousand peers, each peer storing all the data of the block chain and checking that subsequent blocks are validly derived from past blocks, and one leader, that changes when necessary.</p>
<p>The stake of each peer, its voting power in the Paxos consensus process, its weight in the Paxos consensus process, will be approximately proportional to the weight of stake of its client wallets..</p>
<p>Each wallet needs to be able to prove to itself and to other wallets that it transacts with that the transactions that it cares about are valid. To this end it receives a chain of hashes leading to the root of the blockchain, a few branches of the very large Merkle-patricia tree.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

96
docs/development_plan.html Normal file
View File

@ -0,0 +1,96 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 1em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Development Plan</title> </head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Development Plan</h1><p>
First we implement the Merkle-patricia dac – a Merkle dac in which links between items correspond to fields in query.</p><p>
We create a command line program that takes an input stream consisting of a collection of bitstreams, where binary is escaped as hexadecimal (\x followed by a stream of hex digits, followed by a space, \b followed by a stream of binary digits, followed by a space.) Bitstreams are terminated by carriage return or line feed, but not by a \x0D or \x0A. (\u must always be followed by exactly four hexadecimal digits) It parses it into records, constructs the hashes of those records, sorts it into a Merkle-patricia tree, and outputs it as a canonical Merkle-patricia tree of records in depth first tree order with leadig tabs indicating tree depth, composed of field values each field being displayed in a format appropriate to that field.</p><p>
In the input, leading tabs indicate a bitstream that whose prefix is the preceding (one less tabbed) bitstream. The bitstream always starts off with a schema identifier. A schema identifier is a sequence of bytes with the high order bit set, followed by a byte with the high order bit cleared. Records also typically have a schema identifier for their child records so we can add new kinds of child records.</p><p>
Our schema will probably always be byte oriented, but if it is not, we have the \b type for bit fragments.</p><p>
We then create a variant that treats any bitstreams that are prefixes of previous bitstreams as queries, and any bitstreams that are affixes of previous bitstreams as errors, and for each query outputs a proof a denial that the query belongs in the tree, the first full value in the tree matching the query, and a proof that that that full value belongs in the tree.</p><p>
We also create a variant that can check such a proof.</p><p>
We also implement the inverse of this – a client sends in his partial tree, with hashes leading to a hash of the previous value, and the blockchain sends back an amended partial tree, which leads to the current value – which usually proves that the data the client cares about, near the leaves of his partial tree, is unchanged. (the client checks the proof) If it does not prove that, he makes another query to get the new data that he may well care about.</p><p>
Then we create one where the records are Zooko identities, and the petnames are, being subject to the proof, authoritative.</p><p>
Then we create one where if you query with the private secret, you get the proof for public key. (This has a separate database table linking keys to Zooko identities, implemented in SQLite.</p><p>
And one where, for a public key, you get Merkle proof about what network address will serve that public key, or what public key or authoritative petname will serve the network address for that public key.</p><p>
Then a simple command line single threaded single client tcp time server, which we test using Putty in raw mode, and a simple command line client to test it, where the client outputs the result then shuts down the connection immediately.</p><p>
Then, a simple command line multi client tcp time server, and a simple command line client to test it, where the clients shuts down the connection when the user hits carriage return.</p><p>
And then, implement the Merkle-patricia stuff, only with queries over the network between one keyed identity and another.</p><p>
And then, implement the same thing, only with key chains over the network, and the capacity to look up rapidly changing keys from an unchanging authority.</p><p>
Then, a client that runs a unit test when executed with the command line argument <code>test</code>, and displays all test results <code>test v</code>, only fail results <code>test a</code>, or halts awaiting user input at each fail <code>test</code>. The unit test, if run with an output file argument, outputs a file containing all failed test results.</p><p>
Then, finally, transactions in a block chain, where each transaction threads to the previous transactions. And then we have a cash and name system – but not yet a decentralized distributed name system.</p><p>
Then we implement Paxos, peers, and clients, a truly decentralized fully scalable system, and start selling it.</p><p>
There is an obvious problem with this, in that you have to manually launch the server in one command line window, and manually launch the clients in their own test windows. C++17 knows nothing about multiprocess, making it hard to automate multiprocess tests. CTest, however, does know about multiprocess, and can run multiple tests in multiple processes. We have it run the server in self test mode, and multiple instances of the client in test mode. Not at all sure how portable a CMake based self test is going to be, and in any case, should only create it after we have the system running without CMake. Furthermore, looks that CMake fails to play nice with wxWidgets, may be useful only for command line programs – though we can implement most of model view with command line clients and servers and test them from Putty raw mode.</p><p>
Then, a <a href="https://www.johnlamp.net/cmake-tutorial-1-getting-started.html">CMakeLists.txt routine that supports CTest.</a>.</p><p>
We build a client server architecture that utilizes Zooko identities, each Zooko identity based on a passphrase that is manually maintained off database. A client needs to be launched with its passphrase.</p><p>
Then we integrate SQLite (using their own wrapper), and build a database of Zooko identities. Then we build a trivial chat system whereby Zooko identities can chat client <-> peer <-> peer <-> client. The database now contains data on which Zooko identity is associated with which peer, and the IP or peer or domain name at which a peer can be found. Clients can be contacted through peers, and peers can be found by IP, by domain name, or by another peer.</p><p>
We integrate Cap'n proto, then implement Merkle-patricia trees based on data hashed in Cap'n proto format, then we flood fill contact information through the system in Cap'n proto format.</p><p>
We also introduce global true names with no mechanism for resolving true name conflicts. (at which stage true names are worthless).</p><p>
We now return to wxWidgets to make our chat system almost useful (assuming mystery consensus on true names by some as yet undefined process).</p><p>
Now that we have a secure communication system, secured by Zooko names, though totally insecure on true names, an integrated database, Cap'n Proto, and a flood fill system based on Merkle-patricia dacs, we implement global consensus by (arbitrarily defined) weight of stake, with each named peer somehow having some stake that is already part of the previous consensus.</p><p>
At this point we actually have something useful, since we weave the past consensus by multiple paths into the future consensus, so any time anyone communicates with anyone he is checking that that everyone is on the same consensus. So, one guy once gets a forked consensus, then everything stops working when he interacts with people who are still on the main consensus. The entity fooling him has to continue corrupting all his communications with everyone, or else will be detected. A furtive fork will cause stuff to fail, and thus such misconduct will be detected, and people will stop using that entity as a source of information on the consensus.</p><p>
In order to perform a man in the middle attack, have to tell one party the global consensus is one thing, represented by one hash chain, and the other party that the global consensus is another thing represented by another hash chain. And since everyone is passing around signed data to everyone else that includes references to the past global consensus, that links into the past global consensus hash chain, everything is going to break. And when people investigate to fix the break, it will be revealed that the primus inter pares peer was responsible for signing off on two different and incompatible stories about which zooko key owned which human readable name, will lose reputation, and people will stop using their services because their services cause stuff to break, with the result that a different peer will become primus inter pares.</p><p>
The difference between this system and the certificate authority system is that there are a one hundred and one certificate authorities that could provide a false certificate and millions of certificates, while there is only one global consensus, and this global consensus is distributed to a one hundred and one places, and checked by a one hundred and one peers, hence providing a false consensus is more likely to be detected, and more likely to have consequences.</p><p>
So we now have a system for associating keys with human readable names that provides security that certificate authority system fails to provide.</p><p>
At which point we go public, releasing the software as beta for secure communication, but pre-alpha for payments – payment interface does not work, due to bugs and unimplemented features, and if it did work, would be unreliable as a store of value, due to unimplemented features and unimplemented security.</p><p>
At which point we release the software as alpha, then beta, then release but incomplete, release version of name system, pre alpha version of money system. (Stake is not yet usable as money. Stake in alpha and beta releases of the stake system is unlikely to be conserved between releases. Names are likely to be preserved, but may will eventually fees in the release version of the money system. These fees are likely to be very small.).</p><p>
And then we give clients ownership rights over portions of peer stake, and the capacity to transfer it from one peer to the next.</p><p>
And then we give clients the capacity to transfer that ownership stake from one client to the next.</p><p>
We make such transfers chat linked, so that a client can prove that the transfer is associated with a human to human text.</p><p>
And then we give clients the capacity (completely visible and on the block chain) to transfer that ownership stake from one client to the next, which is a little bit anonymous, in that one real person could have a zillion zooko identities.</p><p>
And then we introduce an anonymized mix process in making that transfer, so that a human party to the transaction can prove connection to chat, but an outsider cannot.
.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

82
docs/electronic_wallet.html Normal file
View File

@ -0,0 +1,82 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Electronic Wallet</title>
</head>
<body>
<p><a href="./index.html">To Home page</a> </p>
<h1>Electronic Wallet</h1>
<p>We are moving towards a system where people use a cell phone as their
wallet, or a smart card with screen and some buttons.</p>
<p>A cell phone is used two handed, one hand holding it, one hand pressing the
buttons. A dedicated wallet would be used one handed, held by one’s palms and
fingers, with a thumb click accepting or rejecting a transaction. The dedicated
wallet would be able to talk to any other wallet, or to one’s cell phone, or
indeed any cell phone, if touched to it, or nearly touched to it.</p>
<p>The wallet communicates primarily by near field communications, the wireless
equivalent of whispering in someone’s ear. Nearfield is a communication method
that guarantees that the entities communicating are very close together – with
radio you want the greatest possible range, but nearfield is for those
situations where for security reasons you want the least possible range.
Nearfield is radio with the antenna twisted to pick up the quadrupole field and
ignore the dipole field. Ideally, an near field communication chip should only
be able to talk to something that is almost touching, and it should be
impossible to eavesdrop from more than a foot or so away. </p>
<p>This device should function wallet, as car key, atm card, credit card,
computer login device, and employee door opening device. It enables you to
login to websites.</p>
<p>To buy groceries, you would touch the device to the cash register, the cash
register would show it was asking for a certain sum of money, the device would
show it was being asked for that sum and vibrate or beep, you would thumb
acceptance, and money would be transferred to the cash register, and a receipt
transferred to the wallet.</p>
<p>Money would be represented to the user as if it was a tangible object that
could reside in the wallet, in the cell phone, or in an account. One’s cell
phone can transfer money between these places, with the transfer taking a short
but finite time – money leaves one account before it arrives in another
account.</p>
<p>The device would also handle non monetary receipts – you put your coat in
storage, you get a receipt that enables you to collect it back again.</p>
<p>Of course if the wallet is thumb controlled, it is as easily stolen as a
real wallet, or real keys. A cell phone functioning as a wallet can be made
resistant to theft.</p>
<p>A *spoken* passphrase is both something I know, and something I am. Of
course someone could unobtrusively record it – but he would need to record it
*and* steal the phone. Easy to do one, easy to do the other, not quite so easy
to do both.</p>
<p>Further, a spoken passphrase can comply with the principle of Not One Click
for Security. You set up the user interface so that speaking the passphrase is
used in place of clicking OK. </p>
<p>The way the that the user interface should work, is that the smartphone has
speech recognition and NFC. To authorize payment, or login, or whatever, you
bring the smartphone close to the NFC device, for example the cash register.
When the NFC handshake is complete, the phone makes a beep and displays the
proposed transaction, and then you speak the magic passphrase for that
transaction.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

158
docs/functional_specification.html Normal file
View File

@ -0,0 +1,158 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Functional Specification</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Functional Specification</h1>
<p><br/>
</p>
<p>A functional specification is a pile of mockups of the user interface,
telling a story of what the software will do for users, explaining how the
program will behave externally. </p>
Humans have been identifying themselves with shibboleths for thousands of
years, and frequently killing each other in large numbers on the basis of
shibboleths.
<p> So it seems to me that the way to go is to have the front end, the user
interface for most users, shibboleth based (username and password), while
the backend uses public keys, and all the other tools at our disposal, to
make shibboleths resistant to dictionary attacks and man in the middle
attacks. The user, therefore, should ordinarily control the private key by
username and password. </p>
<p> Here is one such proposed system, intended to implement Zooko’s
triangle: </p>
<p> The end user creates an account with username and password on an
identity server, which may be running on the cloud, or on his company
server, or on his home network. He gets the hash of a rule identifying
public keys that are valid for him, and his username, and how to contact
him while he is logged in. </p>
<p>Now if any user actually sees that hash, contact information, and so
forth, they will reel back in horror.&nbsp; It absolutely has to be
hidden, or else users will boggle.&nbsp; We stick it in the avatar icon,
and/or reference it by the petname.</p>
<p> Many people can have similar or seemingly identical avatars, and people
on different servers can have the same nickname, one’s nickname being
one’s username on a particular identity server. </p>
<p> When he is logged in to that identity server, he can message other
people, and other people can message him. To message someone, you need
their avatar containing their public key. Any such avatar will be assigned
a petname that is unique for any end user, so if someone communicates with
two different people, with two different public keys, they will always be
identified as having two different names, even if they both have same
nickname. </p>
<p> So if I get two people whose nickname is Bob, my software will insist on
me differentiating them with different names before I can message them. </p>
<p> The end user should have on his local computer and on his identity
server data structures that looks like a browser bookmarks list, except
that the favicons can be quite large (can be user avatars), the entry
generally contains public key information about the target (or the hash of
the rule identifying public keys valid for the target), and the entry may
contain username and password information for mutual identification, after
the fashion of otr. </p>
<h3>Communicating public keys:</h3>
<p> The problem is that you want to tell someone over the phone, or on a
napkin, or face to face, information that will enable his client to
securely obtain your public key and network location so that end to end
secured communication can take place.</p>
<p> Also a chatroom’s public key and network location.</p>
<p> We do not necessarily protect against security agencies figuring out
which public key is talking to which public key.&nbsp; That issue is out
of the scope of a functional specification, but we somewhat reduce the
usefulness of this information by allowing people to have lots of public
keys.&nbsp; So you probably have one key for activities that show your
unusual sexual preference, another key for job related activities, another
key for tax evasion related activities, another key for gun running, and
yet another for attempts to overthrow the regime.</p>
<ul>
<li>
<p> Face to face:</p>
<blockquote>
<p>Identifying information is nym, face, and location.</p>
<p> Recipient looks up the nym, sees a bunch of faces grouped by
geographic area.&nbsp; Geographic are usually, but not necessarily,
has some relation to users actual location, and may be very
specific, or very broad.&nbsp; It is a tree.&nbsp; One guy may
locate his face at the node "North America", another at the node New
York, North America.&nbsp; You may, of course, employ a well known
cartoon character or movie star as your avatar instead of your
actual face.&nbsp;&nbsp; Fictional places are permitted, but to
avoid filling the namespace, not on the tree that represents the
real planet earth.</p>
</blockquote>
</li>
<li>
<p>Over the phone.</p>
<blockquote>
<p>Recipient looks up phone number.&nbsp; Finds a bunch of named keys
associated with the phone number – usually one key or a quite small
number of named keys.</p>
</blockquote>
</li>
<li>
<p> Web or email.</p>
<blockquote>
<p>Send a link that contains a 256 bit identifier, but the UI should
not show anyone the identifier.</p>
</blockquote>
</li>
</ul>
<p>The ordinary user by default finds himself using at least one key for
face to face key introductions, a different key or keys for phone
introductions, and yet more for web or email introductions.&nbsp; If he is
clever and reads the manual, which no one will ever do, he can use the
same key for multiple purposes.</p>
<p> All of these named keys have the same behavior when you click on them,
they are intended to be perceived by the user as being the same sort of
thing.</p>
<p> He can use the link, the named key, to attempt to contact, or buddy it,
or bookmark it.</p>
<p> The identifying link information looks like a web link, and is the
nickname of the public key.&nbsp; By default the nickname is the
petname.&nbsp; The user is free to edit this, but usually does not.</p>
<p> When he attempts to contact, this automatically buddies it and/or
bookmarks it.</p>
<p> When he finds a named key, he may "bookmark" it, together with one of
his own private keys – it goes into a datastructure that looks like, and
works like, browser bookmarks.&nbsp; He can also put it in his buddy list.</p>
<p> When you look at an item in your buddy list or bookmarks list, You see a
pair, the other guys key identifying information, and your own key
identifying information.&nbsp; You don’t see the keys themselves, since
they look like line noise and will terrify the average user.</p>
<p> When you click on one of these bookmarks, this creates a connection if
your key is on the other guy’s buddy list and he is online.&nbsp; You can
chat, video, whatever, end to end secured.&nbsp; Otherwise, if you are not
on his buddy list, or he is not presently online, you can send him
something that is very like an email, but end to end secure.</p>
<p> When you send a bunch of people a text communication, chat like,
chatroom like, or email like, they are cc or bcc.&nbsp; If cc, all
recipients of the communication get links, which they can, if they feel so
inclined, message, bookmark or buddy.<br/>
<br/>
Text communication software vacuums up and stores all links, so if you get
an incoming communication from someone whose public key you have not
buddied or bookmarked, the software will tell you any past contacts you
may have had with this public key.<br/>
<br/>
Buddied public keys are white listed for immediate online communication,
Bookmarked and buddied public keys are white listed for offline text
communication, public keys with past information about contacts are grey
listed, public keys with no previous contact information are blacklisted.<br/>
<br/>
Because of automatic blacklisting, to contact, you have to <i>exchange</i>
keys.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

27
docs/furtive_fork_attack.html Normal file
View File

@ -0,0 +1,27 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Furtive Fork Attack</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Furtive Fork Attack</h1>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

339
docs/generic_client_server_program.html Normal file
View File

@ -0,0 +1,339 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style><title>generic client server program</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Generic Client Server Program</h1><p>
Need a MIDL like language which specifies messages, and
generates skeleton program with key handling and
protocol negotiation, in which the distributed public
keys are hashes of rules for recognizing valid full
asymmetric encryption public keys, which interface with a
key distribution and key management system, and which
generates skeleton client server programs with full
protocol negotiation, DDoS resistance, end to end
encryption, support for once and only once messaging,
with or without in order messaging support for at least
once messaging, with or without in order messaging. 
</p><p>
A single endpoint is displayed to the user with a
single name, and for all communications and all
protocols with an endpoin under all applications that
that should conceived of by the particular user a single
site with a single name, and for all applications
displaying information from that site to a single user,
there should be a single encryption and authentication
key per session, many channels per protocol, many
protocols per session, one key for all – thereby avoiding
the security holes that result from the browser
recreating keys many times in what is perceived by the
user to be single session with a single entity. In the
brower, web pages nominally from the same origin can
modify web pages secured using a different certificate
and a different certificate authority.  To avoid the
endless security complications that ensue, all
connections in a single session should rest on a single
shared secret – we should never recreate shared secrets
from public keys in the course of a session or a
transaction. </p><p>
The keying mechanism should support secret handshakes,
for the core revolutionary problem is the long march
through the institutions.  </p><p>
The keying mechanism should also support the corporate
form – not sure if anything special needs to be done to
support signatures that represent shareholder votes.
</p><p>
The protocol negotiation mechanism should enable anyone
to add their own protocol without consulting anyone and
without disruption or significant inefficiency
ensuing, while guaranteeing that once a connection is
set up, both ends are talking the same protocol. 
</p><p>
The keying mechanism shall start with a hash type
identifier, followed by the hash.  The hash is a hash of
a rule prescribing a valid key in full binary. 
Permissible rules are</p><ul><li>
The hash is the hash of full key itself.  </li><li>
The hash is the hash of a full key plus a name path.
This rule implies that a valid key consists of that key
signing another key, which signs another key, which signs
another key, which keys are named according to the name
path, and have expiry dates that are mutually consistent
(a key cannot sign a key that expires beyond its own
expiry) and have not expired yet.  Each key in the
sequence except the first is declared by the preceding
signature to have a name, creation date, and expiry date,
and that name agrees with the name path in the hash. 
The highest key in the chain has a name and creation
dates specified by the hash, but no expiry date. Where
successive keys in the chain of signatures have the same
name, it corresponds to a single link.
The full key itself with an expiry date and preceding
hash key.  We can then change short keys – which
implies many short keys can correspond to the same
identity.  </li></ul><p>
.  </p><p>
.  </p><p>
Whenever one writes a client server program, and whenever
one writes multi threaded software on the shared-nothing
model, for example python with threads connected by
queues, one tends to wind up violating the <a href="http://c2.com/cgi/wiki?DontRepeatYourself">Don’t
Repeat Yourself</a> principle, and the <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">Once And
Only Once</a> principle, eventually leading to total code
meltdown in any very large and very long lived project, so
that it eventually becomes impossible to make any further
substantial changes to the project that involve changing
the interface between client and server, even when it
becomes apparent that the architecture contains utterly
disastrous failings that are complete show stoppers.
</p><p>
The present browser crisis with https is an example of
such an insoluble show stopper, one example of a great
many.  </p><p>
Many of the requirements for a generic server program
are discussed in Beowulf’s <a href="http://qmail_security.pdf">retrospective on
Qmail</a>.  The Unix generic server program is inetd.
</p><p>
A server program has to recover from crashes, and give
performance that degrades gracefully in a resource
limited situation rather than crashing and burning. 
</p><p>
Inetd listens for network connections.  When a
connection is made, inetd runs another program to handle
the connection.  For example, inetd can run qmail-smtpd
to handle an incoming SMTP connection.  The qmail-smtpd
program doesn’t have to worry about networking,
multitasking, etc.; it receives SMTP commands from one
client on its standard input, and sends the responses to
its standard output.  </p><p>
If a particular instance of qmail-smtpd crashes or
hangs, it is not a problem.  Each instance does limited
processing, stuffs the result into a queue, activates the
program that processes the queue if it is not presently
running, and shuts down.  The queue is processed with
limited parallelism, thus is somewhat resistance resource
limited crash and burn.  </p><p>
I envisage something much more capable – that instead
of specifying an IO stream, one specifies an interface,
which gets compiled into message crackers, a skeleton
program with protocol negotiation, and unit tests. 
</p><p>
In accordance with the <a href="http://c2.com/cgi/wiki?DontRepeatYourself">Don’t
Repeat Yourself</a> principle, the specification is human
readable, and records the history of changes and variants
in the specification.  The history of changes and
variants is compiled into protocol negotiation code for
both sides of the interface, and the specification itself
is compiled into message generators and message crackers
for both sides of the interface. The generated code
is regenerated every major make, and is never checked
into source code control, nor edited by humans, though
the generated skeleton code may be copied by humans as a
starting point.  </p><p>
We use a compiler compiler such as CoCo/R to generate a
compiler that compiles the interface specification to the
program.  An interface specification specifies several
interface versions.  In the absence of C code, it
generates a skeleton program.  In the presence of C code
for the previous version of the protocol, it adds a
skeleton for the new version of the protocol to the
existing program.  (I favor CoCo, because it can compile
itself, though it does not seem a very popular choice.)
</p><p>
This functionality is akin to MIDL.  MIDL was a
Microsoft compiler that compiled interface description
language into C++ code that implemented that interface
and interface negotiation – thereby ensuring that
everyone used the same methods to find out what
interfaces were available, and to advertise what
interfaces they made available.
MIDL/IDL/COM was designed for calls within a single
address space and a single thread, and worked great for
this problem, but their efforts to extend it to inter
thread, inter process, and across network calls varied
from bad to catastrophic.  </p><p>
Google’s protobuf is designed to work between threads -
it is a message specification protocl, but lacks the
key feature of MIDL: Protocol negotiation – no run time
guarantee that data was serialized the way it will be
deserialized.  </p><p>
We can also use a meta programming system such as Boost,
which gives C++ lisp like meta programming
capabilities.  Unfortunately Boost, though a no doubt
excellent language, runs on the virtual machine provided
by compilers to implement templates, and the most trivial
operations suck up large amounts of stack space and
symbol space, so despite the coolness of the language, I
expect it to die horribly in real world applications.
</p><p>
We want message crackers, so as to protect against the
buffer overflow problem.  But what about the resource
limit problem? </p><p>
Launching a new program for every connection is costly,
even in Unix, and much more costly for Windows.  I
envisage that the server program will use the TBB,
creating a new thread for each connection.  That is
efficient, but it means that a failure in one connection
can inconvenience all others, that a bug can allow one
thread to access information from other threads.  For
the latter problem, I think the answer is just "no bugs"
- or at least no bugs that allow access to random memory,
but there is one bug we are bound to have: Resource
exhaustion.  </p><p>
How does the generic server program, the program
generated for a particular interface specification,
handle resource exhaustion? </p><p>
We need our program to be neutral to DDoS – does not
allow anything that is cheap for an anonymous
attacker’s machine but expensive for the server
machine, and we need our program to degrade gracefully
when legitimate usage exceeds its capability.  </p><p>
First, when establishing new connections, we have a
limited cache for connections in the process of being
established.  If that cache is exceeded, we send an
encrypted cookie to the client, and stop holding state
for connections in progress – see the discussion of
defenses against a distributed denial of service attack
on TCP – syn flooding and TCP cookies.  </p><p>
Our address space for connections is large and variable
precision.  Each incoming packet contains a clear index
to a shared secret, which is used to decrypt the first
block in the incoming packet, which has to be correct
format and in window for the connection stream, or the
packet gets discarded.  We now, after the decryption,
have the connection stream identifier, which may contain
an index to a larger set of shared secrets, a set of
connections and streams larger than the in memory list
for shared secrets for the initial block.  </p><p>
Having identified that the stream is legit, we then
check if the packet of the stream corresponds to a
presently running thread of a presently running
protocol interpreter.  If it is, we dispatch the packet
to that program.  If it is not, but the protocol
interpreter is running, we dispatch the packet, and the
protocol interpreter recovers the state from the database
and launches a new thread for that stream.  Similarly,
if the protocol interpreter is not running .  .  .
</p><p>
Each thread in the protocol interpreter times out after
a bit of inactivity, and saves its state to the
database.  Persistently busy threads time out
regardless, to discriminate against needy clients.  When
no threads remain, the protocol interpreter shuts down.
From time to time we launch new instances of the protocol
interpreter, (we being the master interpreter that
handles all protocols) and failure of the old instance to
shut down within a reasonable time is detected and
presented as an error.  </p><p>
The master interpreter monitors resource usage, and
gracefully declines to open new connections, and shuts
down hoggish old connections, when resources get
sparse.  The skeleton interpreter generated for each
protocol has a cache limit and database limit for the
number of connections, and an idle and absolute time
limit on cache and database connections – when the cache
limit is exceeded, the connection information goes to
database, when the database limit is exceeded, the
connection is terminated.  </p><p>
Internet facing programs will always encounter malicious
data.  The two huge problems in C and C++ internet
facing programs are buffer overflow and malloc failure.
It is possible to take care of buffer overflow just by
tightly vetting all string inputs.  All string inputs
have to have a defined format and defined maximum length,
and be vetted for conformity.  This is doable, problem
solved – and the protocol definition should specify
restraints on strings, with default restraints if none
specified, and the code generated by the protocol
interpreter should contain such checks, guaranteeing that
all input strings have defined maximums, and defined
forbidden or permitted characters.  Malloc, however is a
harder problem.  No one is going to write and test error
recovery from every malloc.  We therefore have to
redefine malloc in the library as malloc_nofail.  If
someone <em>is</em> going to write error recovery code,
he can explicitly call malloc_can_fail.  If
malloc_no_fail fails, program instance shuts down,
thereby relieving resource shortage by degrading service
if the malloc failure is caused by server overload, or
frustrating the attack if the malloc failure is caused by
some clever attack.</p><p>
We cannot ensure that nothing can ever go wrong, therefore
we must have a crash-and-restart process, that detects
process failure, and auto relaunches.  Unix encourages
this code pattern, by providing Inetd.  This is perhaps,
overly costly, but continually spawning and killing off
new processes is inherently robust.  Therefore, ever so
often, we must spawn a new instance, and every so often,
old instances must be destroyed.  </p><p>
The protocol interpreter should automatically generate
such a robust architecture – a working skeleton program
that is internet facing and architected in ways that make
programs derived from it unlikely to fail under attack.
The experience with web servers is that the efficient and
robust solution is multiple instances, each with multiple
threads.  For robustness, retire an instance after a
while.  One thread per client session, new sessions with
same client in the same instance where possible (what is
a session is sometimes unclear) and after a while, an old
instance gets no new threads, and is eventually forcibly
shut down, if it does not shut itself down when out of
client threads and no prospect of getting new ones. 
</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

342
docs/generic_test.html Normal file
View File

@ -0,0 +1,342 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style><title>generic client server program</title></head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Generic Client Server Program</h1><p>
Need a MIDL like language which specifies messages, and
generates skeleton program with key handling and
protocol negotiation, in which the distributed public
keys are hashes of rules for recognizing valid full
asymmetric encryption public keys, which interface with a
key distribution and key management system, and which
generates skeleton client server programs with full
protocol negotiation, DDoS resistance, end to end
encryption, support for once and only once messaging,
with or without in order messaging support for at least
once messaging, with or without in order messaging.&nbsp;
</p>
<p>We already have such a message specification language, Cap'n Proto, which will generate message crackers and message builders, but we don’t have a client server generator for conversing on the generated messages. But Cap'n Proto can generate quite a bit of stuff. We also have the Boost Asynch library, and the wxWidget library. all of which overlap to some substantial extent with what is being proposed here.</p>
<p>A single endpoint is displayed to the user with a
single name, and for all communications and all
protocols with an endpoint under all applications that
that should conceived of by the particular user a single
site with a single name, and for all applications
displaying information from that site to a single user,
there should be a single encryption and authentication
key per session, many channels per protocol, many
protocols per session, one key for all – thereby avoiding
the security holes that result from the browser
recreating keys many times in what is perceived by the
user to be single session with a single entity. In the
brower, web pages nominally from the same origin can
modify web pages secured using a different certificate
and a different certificate authority.&nbsp; To avoid the
endless security complications that ensue, all
connections in a single session should rest on a single
shared secret – we should never recreate shared secrets
from public keys in the course of a session or a
transaction. </p><p>
The keying mechanism should support secret handshakes,
for the core revolutionary problem is the long march
through the institutions.&nbsp; </p><p>
The keying mechanism should also support the corporate
form – not sure if anything special needs to be done to
support signatures that represent shareholder votes.
</p><p>
The protocol negotiation mechanism should enable anyone
to add their own protocol without consulting anyone and
without disruption or significant inefficiency
ensuing, while guaranteeing that once a connection is
set up, both ends are talking the same protocol.&nbsp;
</p><p>
The keying mechanism shall start with a hash type
identifier, followed by the hash.&nbsp; The hash is a hash of
a rule prescribing a valid key in full binary.&nbsp;
Permissible rules are</p><ul><li>
The hash is the hash of full key itself.&nbsp; </li><li>
The hash is the hash of a full key plus a name path.
This rule implies that a valid key consists of that key
signing another key, which signs another key, which signs
another key, which keys are named according to the name
path, and have expiry dates that are mutually consistent
(a key cannot sign a key that expires beyond its own
expiry) and have not expired yet.&nbsp; Each key in the
sequence except the first is declared by the preceding
signature to have a name, creation date, and expiry date,
and that name agrees with the name path in the hash.&nbsp;
The highest key in the chain has a name and creation
dates specified by the hash, but no expiry date. Where
successive keys in the chain of signatures have the same
name, it corresponds to a single link.
The full key itself with an expiry date and preceding
hash key.&nbsp; We can then change short keys – which
implies many short keys can correspond to the same
identity.&nbsp; </li></ul><p>
.&nbsp; </p><p>
.&nbsp; </p><p>
Whenever one writes a client server program, and whenever
one writes multi threaded software on the shared-nothing
model, for example python with threads connected by
queues, one tends to wind up violating the <a href="http://c2.com/cgi/wiki?DontRepeatYourself">Don’t
Repeat Yourself</a> principle, and the <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">Once And
Only Once</a> principle, eventually leading to total code
meltdown in any very large and very long lived project, so
that it eventually becomes impossible to make any further
substantial changes to the project that involve changing
the interface between client and server, even when it
becomes apparent that the architecture contains utterly
disastrous failings that are complete show stoppers.
</p><p>
The present browser crisis with https is an example of
such an insoluble show stopper, one example of a great
many.&nbsp; </p><p>
Many of the requirements for a generic server program
are discussed in Beowulf’s <a href="http://qmail_security.pdf">retrospective on
Qmail</a>.&nbsp; The Unix generic server program is inetd.
</p><p>
A server program has to recover from crashes, and give
performance that degrades gracefully in a resource
limited situation rather than crashing and burning.&nbsp;
</p><p>
Inetd listens for network connections.&nbsp; When a
connection is made, inetd runs another program to handle
the connection.&nbsp; For example, inetd can run qmail-smtpd
to handle an incoming SMTP connection.&nbsp; The qmail-smtpd
program doesn’t have to worry about networking,
multitasking, etc.; it receives SMTP commands from one
client on its standard input, and sends the responses to
its standard output.&nbsp; </p><p>
If a particular instance of qmail-smtpd crashes or
hangs, it is not a problem.&nbsp; Each instance does limited
processing, stuffs the result into a queue, activates the
program that processes the queue if it is not presently
running, and shuts down.&nbsp; The queue is processed with
limited parallelism, thus is somewhat resistance resource
limited crash and burn.&nbsp; </p><p>
I envisage something much more capable – that instead
of specifying an IO stream, one specifies an interface,
which gets compiled into message crackers, a skeleton
program with protocol negotiation, and unit tests.&nbsp;
</p><p>
In accordance with the <a href="http://c2.com/cgi/wiki?DontRepeatYourself">Don’t
Repeat Yourself</a> principle, the specification is human
readable, and records the history of changes and variants
in the specification.&nbsp; The history of changes and
variants is compiled into protocol negotiation code for
both sides of the interface, and the specification itself
is compiled into message generators and message crackers
for both sides of the interface. The generated code
is regenerated every major make, and is never checked
into source code control, nor edited by humans, though
the generated skeleton code may be copied by humans as a
starting point.&nbsp; </p><p>
We use a compiler compiler such as CoCo/R to generate a
compiler that compiles the interface specification to the
program.&nbsp; An interface specification specifies several
interface versions.&nbsp; In the absence of C code, it
generates a skeleton program.&nbsp; In the presence of C code
for the previous version of the protocol, it adds a
skeleton for the new version of the protocol to the
existing program.&nbsp; (I favor CoCo, because it can compile
itself, though it does not seem a very popular choice.)
</p><p>
This functionality is akin to MIDL.&nbsp; MIDL was a
Microsoft compiler that compiled interface description
language into C++ code that implemented that interface
and interface negotiation – thereby ensuring that
everyone used the same methods to find out what
interfaces were available, and to advertise what
interfaces they made available.
MIDL/IDL/COM was designed for calls within a single
address space and a single thread, and worked great for
this problem, but their efforts to extend it to inter
thread, inter process, and across network calls varied
from bad to catastrophic.&nbsp; </p><p>
Google’s protobuf is designed to work between threads -
it is a message specification protocl, but lacks the
key feature of MIDL: Protocol negotiation – no run time
guarantee that data was serialized the way it will be
deserialized.&nbsp; </p><p>
We can also use a meta programming system such as Boost,
which gives C++ lisp like meta programming
capabilities.&nbsp; Unfortunately Boost, though a no doubt
excellent language, runs on the virtual machine provided
by compilers to implement templates, and the most trivial
operations suck up large amounts of stack space and
symbol space, so despite the coolness of the language, I
expect it to die horribly in real world applications.
</p><p>
We want message crackers, so as to protect against the
buffer overflow problem.&nbsp; But what about the resource
limit problem? </p><p>
Launching a new program for every connection is costly,
even in Unix, and much more costly for Windows.&nbsp; I
envisage that the server program will use the TBB,
creating a new thread for each connection.&nbsp; That is
efficient, but it means that a failure in one connection
can inconvenience all others, that a bug can allow one
thread to access information from other threads.&nbsp; For
the latter problem, I think the answer is just "no bugs"
- or at least no bugs that allow access to random memory,
but there is one bug we are bound to have: Resource
exhaustion.&nbsp; </p><p>
How does the generic server program, the program
generated for a particular interface specification,
handle resource exhaustion? </p><p>
We need our program to be neutral to DDoS – does not
allow anything that is cheap for an anonymous
attacker’s machine but expensive for the server
machine, and we need our program to degrade gracefully
when legitimate usage exceeds its capability.&nbsp; </p><p>
First, when establishing new connections, we have a
limited cache for connections in the process of being
established.&nbsp; If that cache is exceeded, we send an
encrypted cookie to the client, and stop holding state
for connections in progress – see the discussion of
defenses against a distributed denial of service attack
on TCP – syn flooding and TCP cookies.&nbsp; </p><p>
Our address space for connections is large and variable
precision.&nbsp; Each incoming packet contains a clear index
to a shared secret, which is used to decrypt the first
block in the incoming packet, which has to be correct
format and in window for the connection stream, or the
packet gets discarded.&nbsp; We now, after the decryption,
have the connection stream identifier, which may contain
an index to a larger set of shared secrets, a set of
connections and streams larger than the in memory list
for shared secrets for the initial block.&nbsp; </p><p>
Having identified that the stream is legit, we then
check if the packet of the stream corresponds to a
presently running thread of a presently running
protocol interpreter.&nbsp; If it is, we dispatch the packet
to that program.&nbsp; If it is not, but the protocol
interpreter is running, we dispatch the packet, and the
protocol interpreter recovers the state from the database
and launches a new thread for that stream.&nbsp; Similarly,
if the protocol interpreter is not running .&nbsp; .&nbsp; .
</p><p>
Each thread in the protocol interpreter times out after
a bit of inactivity, and saves its state to the
database.&nbsp; Persistently busy threads time out
regardless, to discriminate against needy clients.&nbsp; When
no threads remain, the protocol interpreter shuts down.
From time to time we launch new instances of the protocol
interpreter, (we being the master interpreter that
handles all protocols) and failure of the old instance to
shut down within a reasonable time is detected and
presented as an error.&nbsp; </p><p>
The master interpreter monitors resource usage, and
gracefully declines to open new connections, and shuts
down hoggish old connections, when resources get
sparse.&nbsp; The skeleton interpreter generated for each
protocol has a cache limit and database limit for the
number of connections, and an idle and absolute time
limit on cache and database connections – when the cache
limit is exceeded, the connection information goes to
database, when the database limit is exceeded, the
connection is terminated.&nbsp; </p><p>
Internet facing programs will always encounter malicious
data.&nbsp; The two huge problems in C and C++ internet
facing programs are buffer overflow and malloc failure.
It is possible to take care of buffer overflow just by
tightly vetting all string inputs.&nbsp; All string inputs
have to have a defined format and defined maximum length,
and be vetted for conformity.&nbsp; This is doable, problem
solved – and the protocol definition should specify
restraints on strings, with default restraints if none
specified, and the code generated by the protocol
interpreter should contain such checks, guaranteeing that
all input strings have defined maximums, and defined
forbidden or permitted characters.&nbsp; Malloc, however is a
harder problem.&nbsp; No one is going to write and test error
recovery from every malloc.&nbsp; We therefore have to
redefine malloc in the library as malloc_nofail.&nbsp; If
someone <em>is</em> going to write error recovery code,
he can explicitly call malloc_can_fail.&nbsp; If
malloc_no_fail fails, program instance shuts down,
thereby relieving resource shortage by degrading service
if the malloc failure is caused by server overload, or
frustrating the attack if the malloc failure is caused by
some clever attack.</p><p>
We cannot ensure that nothing can ever go wrong, therefore
we must have a crash-and-restart process, that detects
process failure, and auto relaunches.&nbsp; Unix encourages
this code pattern, by providing Inetd.&nbsp; This is perhaps,
overly costly, but continually spawning and killing off
new processes is inherently robust.&nbsp; Therefore, ever so
often, we must spawn a new instance, and every so often,
old instances must be destroyed.&nbsp; </p><p>
The protocol interpreter should automatically generate
such a robust architecture – a working skeleton program
that is internet facing and architected in ways that make
programs derived from it unlikely to fail under attack.
The experience with web servers is that the efficient and
robust solution is multiple instances, each with multiple
threads.&nbsp; For robustness, retire an instance after a
while.&nbsp; One thread per client session, new sessions with
same client in the same instance where possible (what is
a session is sometimes unclear) and after a while, an old
instance gets no new threads, and is eventually forcibly
shut down, if it does not shut itself down when out of
client threads and no prospect of getting new ones.&nbsp;
</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

127
docs/hello_world.html Normal file
View File

@ -0,0 +1,127 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Hello World</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Hello World</h1>
<p>In this day and age, a program that lives only on one machine, and a program without a gui (possibly a gui on another machine a thousand kilometers away) really is not much of a program</p>
<p>So, the minimum hello world program has to request the indentifier of another machine, creat a connection to that machine, and then display the response that machine.</p>
<p>And the minimum hello world program should preserve state from one invocation to the next, so should have an SQLite database.</p>
<p>And we also have to support unit test, which requires a conventional procedural single thread with conventional unix style output stream.</p>
<p>So the minimum hello world program is going to have a boost.asio multi thread event handler for IO events, io_service and boost::thread_group, and an event oriented GUI thread, which may well be running under boost::thread group. To communicate with the GUI, we use <code>std::packaged_task, std::promise,</code> and <code>std::future.</code> The GUI OnIdle event checks if the packaged task is ready for it to do, and executes it. Any thread that wants to talk to the GUI waits for any existing <code>std::packaged_task</code> waiting on OnIdle to be completed, sets a new packaged task, and awaits the future to be returned, the future typically being a unique smart pointer containing a return struct, but may be merely an error code.</p>
<p>Create an io_service:<pre>boost::asio::io_service io_service;
// This object must outlive the threads that are
// attached to it by the run command, thus the threads
// must be created in an inner scope</pre>
Create a work object work to stop its run() function from exiting if it has nothing else to do:<pre>
{ boost::asio::io_service::work work(io_service);
// The work object prevents io_context from
// returning from the run command when it has
// consumed all available tasks.
// Start some worker threads:
// Probably should use C++14 threads,
// but the example code uses boost threads.
boost::thread_group threads;
for (std::size_t i = 0; i &lt; my_thread_count; ++i)
threads.create_thread(boost::bind(&amp;asio::io_service::run, &amp;io_service));
// This executes the run() command in each thread.
// Boost::bind is a currying function, that converts a function
// with arguments into a function with no arguments.
// A half assed substitute for lambda
// Post the tasks to the io_service so they can be
// performed by the worker threads:
io_service.post(boost::bind(an_expensive_calculation, 42));
// Surely we should be able to replace bind with lambda.
// io_service.post(
// [](){
// an_expensive_calculation(42);
// }
// );
io_service.post(boost::bind(a_long_running_task, 123));
// Finally, before the program exits shut down the
// io_service and wait for all threads to exit:
... Do unit test, wait for the ui thread to join
io_service.stop();
// Stop will prevent new tasks from being run, even if they have been queued.
// If, on the other hand, we just let the work object go out of scope,
// and stop new tasks from being queued,
// the threads will return
// from the io_service object when it has run out of work
}
threads.join_all();
//Thread group is just a vector of threads Maybe should just use a vector,
//so that I can address the gui thread separately.
// Now we can allow io_service to go out of scope.</pre>
So the starting thread of the program will run GUI unit tests through interthread communication to the OnIdle event of the GUI.
<p>Alternatively we could have a separate daemo process that communicates with the GUI through SQLite, which has the advantage that someone else has already written a wxSQLite wrapper.</p>
<p>So we are going to need a program with a UI, and a program that is a <a href="https://stackoverflow.com/questions/12810717/boost-asio-as-a-template-for-a-daemon#12825992">true daemon</a>. The daemon program will be network asynch, and the UI program will be UI asynch, but the UI program will get and send network jobs that are complete in very short time with the daemon, its networking operations will be procedural. This is acceptable because interprocess communication is high bandwidth and highly reliable</p>
<p>We are going to need to support chat capability, to combat seizure of names by the state, and to enable transactions to be firmly linked to agreements, and to enable people to transfer money without having to deal directly with cryptographic identities. The control and health interface to the daemon should be a chat capability on IPC. Which can be configured to only accept control from a certain wallet. Ideally one would like a general chatbot capability running python, but that is a project to be done after the minimum viable product release.</p>
<p>We will eventually need a chat capability that supports forms and automation, using the existing html facilities, but under chat protocol, not under https protocol. But if we allow generic web interactions, generic web interactions will block. One solution is a browser to chat interface. Your browser can launch a chat message in your wallet, and a received chat message may contain a link. The link launches a browser window, which contains a form, which generates a chat message. End user has to click to launch the form, fill it out, click on the browser to submit, then click again to send the chat message to submit from username1 to username2. End user may configure certain links to autofire, so that a local server and local browser can deal with messages encapsulated by the chat system.</p>
<p>We don’t want the SSL problem, where the same client continually negotiates new connections with the same host, resulting in many unnecessary round trips and gaping security holes. We want every connection between one identity on one machine, and another identity on another machine, to use the same shared secret for as long as both machines are up and talk to each other from time to time, so every identity on one machine talks to other identities through a single daemon on its own machine, and a single daemon on the other identity’s machine. If two identities on the same machine, talk though the one daemon. Each client machine talks IPC to the daemon.</p>
<p>There might be many processes, each engaging in procedural IPC with one daemon, but the daemon is asynch, and talks internet protocol with other daemons on other systems in the outside world. Processes need to talk through the daemon, because we only want to have one system global body of data concerning network congestion, bandwidth, transient network addresses, and shared secrets. System Ann in Paris might have many conversations running with System Bob in Shanghai, but we want one body of data concerning network address, shared secrets, cryptographic identity, flow control, and bandwidth, shared by each of these many conversations.</p>
<p>We assume conversations with the local daemon are IPC, hence fast, reliable, and high bandwidth. Failure of a conversation with the local daemon is a crash and debug. Failure of conversations across the internet is normal and frequent – there is no reliability layer outside your local system. Sending a request and not getting an answer is entirel normal and on the main path.</p>
<p>The one asynch daemon has the job of accumulating block chains which implement mutable Merkle-patricia dacs out of a series of immutable Merkle-patricia dacs. Sometimes part of the data from transient mutable Merkle-patricia trees is extracted and recorded in a more durable Merkle patricial trie. Every connection is a mutable Merkle-patricia dac, which is deleted (and some of the information preserved in another mutable Merkle-patricia tree) when the connection is shut down.</p>
<p>Every connection is itself a tree of connections, with flow control, bandwidth, crypto key, and network address information at the root connection, and every connection is the root of a mutable Merkle-patricia dac.</p>
<p>Each daemon is a host, so everyone runs a host on his own machine. That host might be behind a NAT, so to rendevous, would need a rendevous mediated by another host.</p>
<p>See also <a href="./generic_client_server_program.html">Generic Client Server</a> Program, and <a href="./generic_test.html">Generic Test</a>.</p>
<p>And in this day and age, we have a problem with the name system, 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 currency domain names.</p>
<p>So we not only need a decentralized system capable of generating consensus on who owns what cash, <a href="./name_system.html">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>.</p>
<p>Both a gui and inter machine communication daemon imply asynch, an event oriented architecture, which we should probably base on boost asynch. <a href="https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/reference/signal_set.html">Have to implement the boost signal handling for shutdown signals</a>.</p>
<p>If, however, you are communicating between different machines, then the type has to be known at run time on both machines – both machines have to be working of the identical Cap'n Proto type declaration – but might, however, not know until run time which particular type declared in their identical Cap'n Proto declarations is arriving down the wire.</p>
<p>When setting up a communication channel at run time, have to verify the hash of the type declaration of the objects coming down the wire at run time, so that a connection cannot be set up, except both bodies of source code have the identical source for values on the wire on this particular connection.
<p>Obviously in this day and age, a program isolated on one solitary machine is kind of useless, so, what is needed is a machine that has a host of connections, each connection being an object, and the one running thread activates each connection object when data arrives for it, and then the object requests more data, and the thread abandons the object for a while, to deal with the next object for which data has arrived. When an object issues a request that may take a while to fullfill, provides a block of code, a function literal for that event.</p>
<p>A language that has to handle Gui and a language that has to handle communication is event oriented. You continually declare handlers for events. Each handler is a particular method of a particular object, and new events of the same kind cannot be processed until the method returns. If handling the event might take a long time (disk access, user interface) the method declares new event handlers, and fires actions which will immediately or eventually lead to new events, and then immediately returns.</p>
<p>And when I say "immediately lead to new events", I mean "immediately after the method returns" – the method may add a new event handler and possibly also a new event to the event queue. Steal Boost asynch, if Cap'n Proto has not already stolen something like Boost Asynch.</p>
<p>Each event is a message, and each message is a Cap'n Proto buffer, whose precise type may not necessarily be known until it actually arrives, but which has to be handled by code capable of handling that message type.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

220
docs/how_browser_security_should_be_done.html Normal file
View File

@ -0,0 +1,220 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>How Browser Security Should be Done</title>
</head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>How Browser Security Should be Done</h1>
<p>
Cryptography should be written around user concepts, not
cryptographer concepts.&nbsp; </p>
<p>
The cryptography should be written underneath session
management and logon management, instead of session
management being written on top of the cryptography.
The cryptography should be written to give effect to
user expectations, rather than trying to get the users
to behave like Ann and Bob in the text book
illustrations of how to use cryptography correctly.&nbsp;
</p>
<p>
The process whereby things go wrong is that one produces
a completely sound solution to one part of the problem,
waves away the all the rest of the problem as mere
details, and then a gigantic mud brick ziggurat
gradually accretes around that perfectly sound solution,
as for example ssl-https-pki.&nbsp; </p>
<p>
When the disastrous abortion know as https was first
designed it should have been obvious that everything
really important relates to logins and sessions and that
the rest can be treated as a login by "anon 37283" with
the null password, and that therefore the cryptography
<em>and the browser user interface</em> needs to
implement logins and sessions, rather than providing a
pile of matchsticks and glue with which the website can
implement something that sort of mostly behaves rather
like logins and sessions.&nbsp; </p>
<p>
It <em>should</em> have been obvious that logging in on
a user interface provided by a web page, provided by
html code, was entirely insecure – the problem of
spoofed logins was well known at the time.&nbsp; So what we
needed, from day one, was a secure login that was in the
browser chrome, not the web page – and no other form of
secure login supported.&nbsp; </p>
<p>
When the user creates a username and password, this
should by default automatically create a bookmark in his
contacts folder, much as an email client usually does
when you post a reply.&nbsp; To reduce the risk that
the user may be fooled into using a hostile
client, the user interface for entering password
and username should never pop up except by the
user clicking on a login button in the browser
chrome, or clicking on a login bookmark. Not only
should the user never enter his password and user
name on a web page, but also there should never be login
buttons on a web page.&nbsp; </p>
<p>
To make this chrome based login cryptographically secure
against active and passive attacks on the wire,
phishing, and social engineering.&nbsp; </p>
<ul>
<li><p>
If the user enters the user name and password incorrectly,
then he has to pass a reverse Turing test before entering
the password again, to prevent scripts from trying
millions of passwords.&nbsp; So if an attacker has tried to
guess passwords, the website will inform the user that n
unsuccessful login attempts have taken place against his
user name and ask him to pass the reverse Turing
test.&nbsp; </p></li><li><p>
The user interface to create a connection never pops up
spontaneously, but only as a direct result of the user
choosing to cause it to pop up, typically by clicking
on a bookmark in his account list, or by clicking on
the login widget in the browser chrome.&nbsp;
</p></li><li><p>
We use password-authenticated key agreement to construct a strong frequently changing
secret from the short infrequently changing secret
password. Thus if the user logs in to the wrong host –
or to an adversary pretending to be the correct host in a
man in the middle attack, the false server does not get
the password or the session secret.&nbsp; We also hash
the password with server global key. </p></li><li><p>
Password-authenticated key agreement also ensures that a passive eavesdropper will not
discover the password or the strong session secret.&nbsp; </p>
</li>
</ul>
<p>
This tells us how the login will avoid being phished,
but how shall we set up a login in the first place.&nbsp;
The user needs a secure connection to the correct
website. We know how to do secure connections, trouble is
identifying the correct website.&nbsp; </p>
<p>
To ensure that the website is that which is
intended, we use yurls, a form of Zooko identity.&nbsp;
</p>
<p>
The person using the client needs to login and has to
know and manage their logged in status.&nbsp; The user
login status should be displayed in the chrome on every
logged in web page, and the server has to know that the
user knows his login status, has to know the login
status not only of the user, but of the web page that
the user has clicked on that generated this request to
this server.&nbsp; </p>
<p>
The state of being logged in should guarantee privacy
and authenticity – that only the client and the server
can know what they are communicating, and that no one
else should be able to pass himself off as client or
server, or modify their communications.&nbsp; </p>
<p>
Everything should have been written around the user
concepts of "logging in" "a logged in page", and
"logging out", and should have made those user concepts
real, made them into pages with appropriate built in
cryptographic behaviors.&nbsp; </p>
<p>
The user concept of "logged in" has to be real rather
than superficially simulated by server side code, and
thus has to really have the cryptographic
characteristics that the user expects – which at present
it generally does not, leading to such attacks as the
session fixation attack.&nbsp; </p>
<p>
The user should have a list of contact web sites as he
does in Skype and AIM, and when he clicks on that
bookmark, the logon page, provided by his browser rather
than the website, should provide the true name of the
web site, if it has a certified true name, and/or the
title of the bookmark, the petname, if it has one.&nbsp; And
when logged on, any logged on page should show in the
chrome the petname, or truename of the website, and the
logon name – who the website thinks is logged on.&nbsp;
</p>
<p>
Single signon should work like Skype, and should be
built into the protocol at the base level, in the
cryptography, and in the chrome, and in the
bookmark/petname management.&nbsp; You click on a petname in
the Skype contact list – the Skype folder of the login
folder of your bookmark folder, and lo, because you are
securely logged in to Skype, and the web site also
securely logged into Skype, you come to be securely
connected to each other under your Skype names without
any further mucking around with passwords.&nbsp; The web
page then displays in the chrome the web site’s Skype
name, and your Skype name.&nbsp; Single sign on should also
allow web site push, if the end user is logged in to the
single sign on server and the website is in his contact
list and the end user has not prohibited such push.&nbsp;
Thus the browser should be, or be tightly integrated
with, a messaging service provided by the single sign on
service.&nbsp; </p>
<p>
The web application framework should ensure that code
providing a response to a user’s click on a web page
that is not logged in does not have write access to
database records corresponding to that user – that only
a click on a logged in web page in the user’s browser
can result in changes to user records on the server.&nbsp;
</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

198
docs/how_to_do_VPNs.html Normal file
View File

@ -0,0 +1,198 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style><title>How to do VPNs right</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>How to do VPNs right</h1>
<h2>This web page obsolete. VPN’s are now relatively easy to use</h2>
Most existing VPNs are extremely hard to set up correctly
– and rather too easy to set up incorrectly.&nbsp; <p>
Part of the problem is that many of them imitate or copy
SSL’s X.509 key negotiation. X.509 throws up its hands in
despair at the key distribution problem and abandons it
to the end user.&nbsp; SSL session setup performance is poor,
and no one has succeeded in making SSL user friendly to
use it in a way that is actually safe. If using SSL or
its various successors, the end user must himself grapple
with cryptographic concepts that give cryptographers a
hard time, and which professional cryptographers
frequently screw up. So inevitably, the end user gets it
wrong almost all the time, even expert highly motivated
users.&nbsp; </p><p>
If you start from SSL or DTLS you are going to wind up
with the sort of hopelessly difficult VPN setups that we
have in fact wound up with. It is completely unacceptable
to tell your end users to use OpenSSL to create
certificates, certify them and then install the
certificates, which is the sort of thing we are all too
frequently instructed to do.&nbsp; </p><p>
Instead, one needs to devise the user interface, then work
backwards from the user interface to key negotiation, and
then use SSL/TLS, or SSL/TLS concepts only to the extent
that TLS fits the actual solution, rather than trying to
build a solution out of TLS. In this page, I will
describe VPN setup done right.&nbsp; </p><p>
In any VPN system, each packet within a session must have
its own unique IV (nonce), and each session must have its
own symmetric encryption secret and authentication
secret.&nbsp; We have to have a new session every client
restart, every server restart, and every 2^64 bytes.&nbsp; At
the beginning of each new session, new strong secrets,
large truly random numbers, have to be negotiated for
symmetric encryption and authentication.&nbsp; </p><p>
The problem is that humans are not going to carry around
large strong secrets every time either end of the
connection restarts.&nbsp; In fact they are not going to
transport large strong secrets any time ever, which is the
flaw in SSL and its successors such as IPSec and DTLS.&nbsp;
</p><p>
Humans have long relied on shibboleths for security
against treachery by outsiders. Thus the computer
interface to our clever cryptographic algorithms must
resemble as closely as possible the ancient human
reliance on shibboleths for security.&nbsp; </p><p>
What humans <em>are</em> going to do, and what the user
interface must support, and the cryptography somehow make
secure, is set up a user name and a rather short password,
and enter that password on request – rather too easily
enter it on request without necessarily checking who they
are giving it to.&nbsp; Our security has to work with humans
as they are, and make what humans are naturally inclined
to do secure, rather than try to change what humans are
naturally inclined to do.&nbsp; </p><p>
So the VPN setup is this:.&nbsp;</p><ul><li><p>
Server starts VPN server program, client starts VPN client
program for the very first time.&nbsp; Human at client enters
a URL for the server program.&nbsp; If it connects to the
server (or something pretending to be the server) it
requests user name and password, which of course does not
yet exist, and offers the user the choice of creating a
new user name and password. </p></li><li><p>
User at the client creates a new user name and password.&nbsp;
Client logs in, and reports that user so and so has
absolutely no privileges, needs to talk to the
administrator on the server.&nbsp; The user at the client
contacts the administrator on the server out of band, this
being the standard way VPNs are in fact set up in
practice.&nbsp; Our security ultimately rests on this out of
band human to human discussion, which relies on standard
human to human security, which humans are naturally quite
good at, thanks to several million years of evolution
involving frequently lethal treachery.&nbsp; The administrator
then looks at the gui of the server program (yes, it has
to have a gui, unlike most existing VPNs) which lists the
various user names (but not their passwords, for, as we
shall see, the server program does not in fact know the
password).&nbsp; The administrator then gives user name the
necessary privileges. </p></li><li><p>
Obviously we do not want to repeat this scene every time
either end of the connection restarts. So the client
gives the end user the option that the client will
remember the server address, user name and password, and logon
automatically on startup – in which case anyone with
physical access to the computer can steal the password,
which can be strongly obfuscated but not truly hidden,
but that is the kind of threat the end user can
understand and properly evaluate. All existing VPNs have
similar problems, as does email.&nbsp; </p><p>
Also, anyone that installs malware on the end user’s
computer can steal the password, which threat the end user
cannot be expected to understand or properly evaluate. We
know <a href="safe_operating_system.html">how to defeat
malware</a> – Polaris and Bitfrost show how to make
malware almost impossible, but malware resistant operating
systems still have some rough edges.&nbsp; Regardless, SSL
certificates and email programs have the same problem, so
we are just going to live with the node weakness until the
day that every operating system works the way that
Bitfrost is intended to work. </p></li></ul><p>
Now we look at making this system cryptographically secure
against active and passive attacks on the wire, phishing,
and social engineering.&nbsp; </p><ul><li><p>
If the user enters the user name and password incorrectly,
then he has to pass a reverse Turing test before entering
the password again, to prevent scripts from trying
millions of passwords.&nbsp; So if an attacker has tried to
guess passwords, the VPN network will not automatically
login on client startup, but will instead require user
intervention to respond to the reverse Turing test. The
user will be informed by the server that n unsuccessful
login attempts have taken place against his user name, thus
notifying him he is under attack.&nbsp; So the fact that the
attacker can force manual intervention on client restart
is hereby declared to be a feature, not a bug.&nbsp;
</p></li><li><p>
The user interface to create a connection never pops up
spontaneously, but only as a direct result of the user
choosing to cause it to pop up, typically by clicking
the create-a-connection icon on his start menu.&nbsp;
</p></li><li><p>
We use password-authenticated key agreement to construct a strong frequently changing
secret from the short infrequently changing secret. Thus
if the user logs in to the wrong host – or to an
adversary pretending to be the correct host in a man
in the middle attack, the false server does not get the
password or the session secret.&nbsp; </p></li><li><p>
Password-authenticated key agreement also ensures that a passive eavesdropper will not
discover the password or the strong session secret.&nbsp; </p>
</li></ul><p>
The short password is OK, because offline attacks are
impossible due to password-authenticated key agreement.&nbsp; The total lack of security on
the URL is OK because phishing attacks are impossible due
to password-authenticated key agreement.&nbsp; Of course they are only impossible due to password-authenticated key agreement
if the end user is using his own client with a hostile
address and is therefore <em>using</em> password-authenticated key agreement. If he is using
a hostile client, he is hosed.&nbsp; To reduce the risk that
he may be fooled into using a hostile client, the user
interface to create a connection should never pop up
spontaneously.&nbsp; If the connection is needed, but not
present, the operation should just fail.&nbsp; </p><p>
The client software should always mangle the user
passphrase with the unchanging server public key, so if
the user uses the same password for accounts with
multiple entities, those entities cannot use this against
each other.&nbsp; </p><p>
The reverse Turing test protects against scripted online
password guessing attacks. The various retry, leakage,
and replay attacks on symmetric encryption do not work
because we always have a nonce for each and every packet,
we password-authenticated key agreement renegotiate new shared secrets for every session
and we have new sessions as often as cryptographically
needed.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

46
docs/iff.html Normal file
View File

@ -0,0 +1,46 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style><title>IFF</title>
</head>
<body>
<h1>IFF</h1>
<h2>Identification Friend or Foe</h2>
<p><a href="./index.html"> To Home page</a> </p><p>
The objective is to provide Identity Friend or Foe information, while leaking as little individual identity information as possible – to identify oneself as a member of a group, for example employees entitled to access certain information, or guests entitled to access certain services, without flagging their specific individual identity far and wide.</p><p>
This outlines a scheme capable of being used for world domination and replacing everyone’s car keys, house keys, employee identification badge, and military dog tag, but before attempting that, we are going to start small by moving the corporate form to the blockchain, and putting your employee id in your crypto currency wallet, using it to escape dominion, rather than enforce it, a multiplicity of separate groups, rather than one enormous group. Then we conquer the world and enslave all the women, but our more modest initial target market is to support freedom of association, to put the corporate form on the blockchain.</p><p>
Any id scheme has potentially totalitarian uses, and I can easily imagine a whole lot of oppressive ways for using this scheme, but a scheme that links every interaction to one unique identity rooted in state documents, which is what we have now, is a lot more totalitarian than this proposal, because this proposal only shows you are fellow member of the group, or a person authorized to use a certain facility. Unlike the current system, it does not show which particular member of the group you are to all.
<h3>Large group IFF is constructed out of small group IFF</h3><p>
Each member of the small group has an infrequently changed secret key whose public key uniquely identifies him to a small number of other people, among them the leader of the small group (meaning the leader of the group’s computer. He has a frequently changing secret key, whose corresponding public key gets signed by the leader of the group’s less frequently changing secret key at frequent intervals. The list of frequently changing public keys identifying members of the group gets frequent signed updates from the leader which are sent out to all members of the small group, and members of the small group identify someone as a member of the group by checking to see if he is on the current or recent list.</p><p>
This is no good to members of an outgroup, which is a desirable feature, and no good to members of the larger group, which feature needs to be added.</p>
<h3>Large group IFF</h3><p>
The large group is a group of groups. The leader of each of small groups similarly has a frequently changing secret key, with which he signs each member’s frequently changing public key. To identify yourself as a member of the larger group, you sign your message with your frequently changing secret key, and show that your corresponding frequently changing public key was signed by someone on the list of frequently changing public keys of subgroup leaders within the larger group. Repeat for as deep a hierarchy as needed.</p><p>
If a member of the larger group misbehaves to another member of the larger group, the leader of the larger group can identify the subgroup that has a misbehaving member, and the leader of the subgroup can identify the particular member. For purposes of control, we may well, once we scale to embracing all of society, have a fairly deep hierarchy with a correspondingly small list of top level frequently changing keys, going all the way from king, to military officers and employers, to employees, to wives and children. </p><p>
This scheme inherently identifies you as a fellow member of a subgroup to another member of the same subgroup, but only identifies you as a member of the larger group to a member of the larger group who is not a member of your subgroup. We are going to start small (Hail fellow thought crime thinker, hail fellow black marketeer, hail fellow mafia member, hail fellow plotter, hail fellow employee of grey market block chain based business) but when we scale to embracing all of society someone is likely to be a member of multiple groups (reservist, employee, club member, family member) and will respond with the group of the pinger, if he is a member of that group as well. Your employee iff will unlock the door of your employer’s office building, and your family iff will unlock the door of your dad’s house.</p>
<h3>Fine grained control</h3><p>
The signature on the individual member’s frequently changing public key may contain additional information, above and beyond "friend", and he may receive several such signatures, each of which contains a different item of information. However, a basic ping should only reveal the information necessary.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

39
docs/ifpfs.html Normal file
View File

@ -0,0 +1,39 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>IPFS</title>
</head>
<body><a href="./index.html"> To Home page</a>
<h1>IPFS</h1><p>
is a distributed storage and communication system, Git plus bittorrent. It is used by various entities, notably filecoin and bit.tub</p><p>
It may well give you the shared global data storage you need for your global blockchain, without having to write low level communication protocols yourself.</p><p>
Trouble is, written in Go, and uses 4096 bit RSA keys. I lack confidence in people who use 4096 RSA keys, but it is a great deal of impressive (alpha) software. It is also a lot of well thought out design, for example the rules whereby peers can deal fairly with each other. Even though alpha, you can put your website on IPFS and browse it through IPFS</p><p>
IPFS plus filecoin is doing most of the things you were planning to do, except proof of stake, the corporate form, and names.
Filecoin raised 200 million, and its currency, FIL, provides real and substantial value in that you can buy file storage with it. Coinbase and like exchanges allow you to trade one cryptocurrency with another – providing massive loss of privacy in the process. And you can, of course, buy cryptocurrency on coinbase. It is still in beta, but it is one crypto currency where mining provides real value. It is on the ethereum blockchain, which kind of sucks, but truth is they wanted to raise money in a hurry, and the ethereum network is where you raise money in a hurry.</p><p>
IPFS supports the web – there is a javascript application that runs on your browser, without being installed as an extension, that can browse IPFS files.</p><p>
There is, as yet, no massive piracy system using IPFS, and there should be.</p><p>
IPFS interfaces to ethereum. The IPFS browser should be able to look at the ethereum blockchain, and the ethereum wallet should be able to look at the IPFS data structure</p><p>
IPFS has support for Merkle dag.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

141
docs/implementation_steps.html Normal file
View File

@ -0,0 +1,141 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Implementation Steps</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Implementation Steps</h1>
<p>Network addresses shall be opaque blobs, which may in practice consist of
an IP4 address plus some variable precision additional subnetwork address,
or may consist of an IP6 address&nbsp; some variable precision additional
subnetwork address, or some unknown future implementation for some non
standard network.. Only the lowest level software knows or cares. To
everything above, a network address is an opaque blog of unknown length
and unknown internal format, which is by default non human readable and
non human writeable, though some subtypes may be human readable and
writeable.&nbsp; <br/>
</p>
<p>There is a member function which may yield a derived class that is human
readable and writeable, but likely yields the null pointer.&nbsp; The
additional subnetwork information is used to handle the now common case
that there are many entities on a single machine.<br/>
</p>
<p>Which is to say, network addresses are implemented as a set of classes
whose internal details are as far as possible hidden, derived from an
interface base class, and all other software calls the methods of the
interface base class.</p>
<p>Similarly for public keys, and indeed everything else.&nbsp; Exposing the
internal structure of network addresses and port numbers and so on and so
forth to everything was a huge mistake.</p>
<p>The base classes of these heterogenous objects with common behaviors are
of course, abstract classes.&nbsp; Our networking system shall be built on
top of abstract classes, unlike the existing system where class internals
are exposed.<br/>
</p>
<ol>
<li>
<p>Given a network address, a member of our opaque classes, be able to
send unreliable messages in the clear.&nbsp; UDP equivalent, but as
yet no TCP equivalent.&nbsp; At this point, we make absolutely no
attempt to deal with NAT barriers.</p>
</li>
<li>
<p>Client knows server public key and server network address.&nbsp;
Client and server construct strong shared secret despite the possible
presence of an active man in the middle adversary.&nbsp; To deal with
replay attacks, establish shared global time and shared probabilistic
offset from that time. (Server and client agree to disagree on global
time, but know how big a disagreement they have.&nbsp; Everyone tries
to have their shared global cryptographic time to be the median
offset)<br/>
</p>
</li>
<li>
<p>Client knows server network address and server public key.&nbsp;
Client and server know username and weak password or hash
thereof.&nbsp; Client and server construct strong shared secret
despite the possible presence of an active man in the middle
adversary.</p>
</li>
<li>
<p>Client knows server network address but does not know server public
key, or anything that would allow it to reliably identify the server
public key.&nbsp; Client and server know username and weak password or
hash thereof. Client and server construct strong shared secret despite
the possible presence of an active man in the middle adversary.</p>
</li>
<li>
<p> Unite all the above code as derived from a single abstract base
class, which caches the connection between client and server,
regenerates a shared secret as needed.&nbsp; </p>
</li>
<li>
<p>We define the class &#8220;connection&#8221;.&nbsp; A connection is a member of a
class containing shared secret and network address information.&nbsp;
We have not yet, however, got to a concept replacing port number, or
even got anywhere near being able to build user interface. We have
however, placed what we need for encryption where it belongs, at close
to the most foundational level.&nbsp; Encryption first, port number
equivalent and TCP equivalent on top of encryption.&nbsp; Then we get
to UI later, and then we will get to how to know these public keys, or
hashes of rules identifying public keys. </p>
</li>
<li>
<p>The encrypted connection, and, finally ports. The encrypted
connection is a connection with encryption information. Packets arrive
with position information as to the order in which they were sent,
though not all packets arrive, and not in original order and some are
garbled. Packets are authenticated then decrypted and assigned to
their appropriate port, so when they get to the port they are
authentic, correct, and have known positions within the port stream
and connection stream, though not all make it to the port, and not in
order.</p></li></ol>
<p>Ports are an encrypted connection plus <a href=".%5Cprotocol_negotiation.html">protocol
agreement information</a>. For every connection, there are usually
two ports, one to manage the creation and destruction of ports and the
connection, and at least one to actually transport useful information.</p>
<p>A port references an encrypted connection, probabilistic information
about the current state of information exchange, and a protocol
description.</p>
<p>Thus, the very first protocol is a protocol to negotiate new ports
and thus new protocols, and to shut down this connection.</p>
<p>This could potentially create additional round trips, thus we have
have a general rule for collapsing round trips, "Assuming you agree to
the proposed protocol, here is first packet of that protocol." If
server does not agree, then client adjusts its assumptions about
server state.</p>
<p>Each side transmits on its best guess about the state of the other,
but can back up to an earlier point in the state machine if such
provisional transmissions are revealed to be in error.</p>
<p>In the present tcp implementation, the client is a state machine, and
the server is a state machine, and they try to tend to corresponding
states. Thus the client state embodies knowledge about the server
state. I suggest that instead the client maintains a list of possible
server states, and as events happen, updates the weightings of each
guess as to server state.</p>
<p>The client also needs to model server guesses about client state, and
the server needs to model client guesses about client state, an
estimate about an estimate.</p>
<p>Server ids contain a link to a list of protocols they accept, signed by an authority responsible for those protocols. Protocols are identified by stream of bytes, in which zero or bytes have their high bit set, the stream being terminated by a byte with the high bit cleared. Lists of protocols are maintained by the system responsible for the list of server ids, with new lists only being added by a human decision at the distinguished proposer.</p>
<p>These lists only identify protocols capable of setting up a connection. When a connection is made, the client offers a list of subprotocols that it wants, and the server accepts the first one in the list that it recognizes and wants to handle. We will have no central authority for such subprotocol lists. Anyone can roll there own, and in the event that there come to be a lot of them, the implementer just chooses an identifier long enough and random enough that the risk of collision is small.</p>
<p style="background-color : #ccffcc;
font-size:80%">These documents are licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a> </p>
<p style="background-color :
#ccffcc; font-size:80%"> And, in any case, are a proposal for software that can
be used to massively copy copyrighted material. </p>
</body>
</html>

75
docs/interlockedxxx.html Normal file
View File

@ -0,0 +1,75 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Write your own InterlockedXxx
operation</title> </head> <body>
<p><A href="./"> To Home page</A> </p>
<h1>Write your own InterlockedXxx
operation</h1><p>
It has long been known that InterlockedCompareExchange can be
used to write any Interlockedxxx operation.  </p>
<pre>
long InterlockedXxx(
__inout long volatile *Target,
, whatever parameters we need for Xxx
)
{
long prevValue, prevCopy;
prevValue = *Target;
do {
if Xxx operations is illegal on prevValue, return with error code
prevCopy = prevValue;
//
// prevValue will be the value that used to be Target if the exchange was made
// or its current value if the exchange was not made.
//
prevValue = InterlockedCompareExchange(Target, Xxx operation on prevCopy, prevValue);
//
// If prevCopy == prevValue, then no one updated Target in between the deref at the top
// and the InterlockecCompareExchange afterward and we are done
//
} while (prevCopy != prevValue);
//
// [value] can be anything you want, but it is typically either
// a) The new value stored in Target. This is the type of return value that
// InterlockedIncrement returns
// or
// b) The new value is the previous value that was in Target. This si the
// type of return value that InterlockedOr or InterlockedExchange return
//
return [value];
}</pre><p>
Structures larger than a long can be handled by
using InterlockedCompareExchange to add to a
linked list, or remove stuff from a linked
list. Of course you should not be writing such
things yourself, when Intel has already written
it for you.  </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

45
docs/libraries/scripting.html Normal file
View File

@ -0,0 +1,45 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Scripting</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Scripting</h1><p>
Initially we intend to implement human to human secret messaging, with money that can be transferred in the message, and the capability to make messages public and provably linked with an identity</p><p>
But obviously we are eventually going to need bot responses, and bot scripts that can interact with the recipient within a sandbox. Not wanting to repeat the mistakes of the internet, we will want the same bot language generating responses, and interacting with the recipient.</p><p>
There is a <a href="https://github.com/dbohdan/embedded-scripting-languages">list</a> of embeddable scripting languages.</p><p>
Lua and python are readily embeddable, but <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/">the language shootout</a> tells us they are terribly slow.</p><p>
Lisp is sort of embeddable, startlingly fast, and is enormously capable, but it is huge, and not all that portable.</p><p>
ES (javascript) is impressively fast in its node.js implementation, which does not necessarily imply the embeddable versions are fast.</p><p>
Very few of the scripting languages make promises about sandbox capability, and I know there is enormous grief over sandboxing Javascript. It can be done, but it is a big project.</p><p>
Angelscript <em>does</em> make promises about sandbox capability, but I have absolutely no information its capability and performance.</p><p>
Tcl is event loop oriented.</p><p>
But hell, I have an event loop. I want my events to put data in memory, then launch a script for the event, the script does something with the data, generates some new data, fires some events that will make use of the data, and finishes.</p><p>
Given that I want programs to be short and quickly terminate, maybe we do not need dynamic memory management and garbage collection. Maybe arkscript would handle it.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

95
docs/libraries/serialization_and_canonical_form.html Normal file
View File

@ -0,0 +1,95 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
padding: 6px;
border: solid 1px black;
}
</style>
<link rel="shortcut icon" href="../../rho.ico">
<title>Serialization and Canonical form</title>
</head>
<body>
<p><a href="../libraries.html"> To Home page</a> </p>
<h1>Serialization and Canonical form</h1><p>
On reflection, using a serialization library is massive overkill, since we are serializing records that always have a record type identifier, and we are serializing hashes, signatures, and utf8 strings, which should already be in network order, so the only thing we have to serialize is ints, for which we might as well write our own serialization code, in an object of type serialization buffer<pre>
namespace ro {
template&lt;class T&gt; class iserial : public gsl::span&lt;uint8_t&gt; {
public:
static_assert(std::is_integral&lt;T&gt;::value, "iserial is only for serializing integers");
std::array&lt;uint8_t, (sizeof(T)*8+6)/7&gt; blob;
iserial(T i) {
if constexpr (std::is_signed&lt;T&gt;::value) {
// Don’t serialize an integer unless you know for sure it is positive;
assert(i &gt;= 0);
}
uint8_t* p = &amp;blob[0] + sizeof(blob);
*(--p) = i & 0x7f;
i &gt;&gt;= 7;
while (i != 0) {
*(--p) = (i & 0x7f) | 0x80;
i &gt;&gt;= 7;
}
assert(p &gt;= &amp;blob[0]);
*static_cast&lt;gsl::span&lt;uint8_t&gt;*&gt;(this) = gsl::span&lt;uint8_t&gt; (p, &amp;blob[0] + sizeof(blob));;
}
};
template&lt;typename T&gt; std::enable_if_t &lt;std::is_integral&lt;T&gt;::value, ro::iserial&lt;T&gt; &gt;serialize(T i) {
return iserial&lt;T&gt;(i);
}
inline auto ideserialize(uint8_t* p) {
uint_fast64_t i{ 0 };
while (*p & 0x80) {
i = (i | (*p++ & 0x7F)) &lt;&lt; 7;
}
return uint64_t(i | *p);
/* The serialized number format supports positive integers of any size, but interpretation of unreasonably large integers is limited by the implementation. */
}
inline auto ideserialize(gsl::span&lt;uint8_t&gt; in) {
return ideserialize(&amp;in[0]);
}
}
</pre><p>
But all our money amounts will typically be around 32 bits or longer, maximum 64 bits, hence untranslatable to valid utf8. Might represent them as a decimal exponent and small integer.</p><p>
We might need floating point for graph analysis, but that is a long way in the future. Sqlite3 uses big-endian IEEE 754-2008 64-bit floating point numbers as its canonical interchange format, (no longer widely used by modern computers) but even if we do the analysis in floating point, we may well find it more convenient to interchange the data as integers, since the floating point values of groups of interest are all likely to be in a narrow range, and we may not care to interchange the graph analysis data at all, only the groupings and rankings. Really you only care about one group, the cooperating group.
We also need to serialize signatures to human readable format, for embedding in human readable messages – base 58, because we are suppressing O, o, I, and lower case l, or base 64, which we get by including -+_$!* (permitted in urls) For error check, prefigure with enough hash bits to round up to a multiple of six bits. and make the output fixed size. Human readable messages that include sensitive records will always end with a hash of the entire human readable message, truncated to a multiple of three bytes, hence a multiple of six bits. Perhaps thirty bytes, two hundred and forty bits, forty u characters of u encoding, and the signed transaction output inside the message will always have the full signature of the full record. A full signature of a full record will thirty three bytes, 32 bytes of signature and one byte of hash of the signature, to make human transmission of signatures possible, though very difficult. </p><p>
<a href="https://github.com/thekvs/cpp-serializers">Review of serializers</a>.</p><p>
We don’t want the schema agility of protobuf and Avro. We want header only, and do not come with half a dozen tools that do half a dozen complicated things. We just want to serialize stuff to canonical form so that it can transported between different architectures and code generated by different compilers, and so that the same object always generates the same hash.</p>
<h2><a href="https://github.com/niXman/yas">yas</a></h2><p> is the fastest when compressing to ordinary density, and most compact when compressing to high density. And is header only, unit tested, and compiler agnostic.</p>
<table>
<tr><td>yas</td> <td>17.416 gigabytes</td> <td> 3.152 seconds</td></tr>
<tr><td>yas-compact</td> <td>13.321 gigabytes</td> <td>24.878 seconds</td></tr></table>
(implying about two terabytes per hour for yas-compact)<p>
A typical high speed connection is 1Gbps one Gigabit per second. (GBps is gigabyte persecond, Gbps is gigabit per second.</p><p>
Yas compact can handle 4Gbps, so storage and bandwidth are likely to be bottlenecks – and we can probably throw more cpus at the system easier than more bandwidth and storage. So we make canonical yas-compact, or a variant thereof, with customization on index fields.</p>
<h2>libnop: C++ Native Object Protocols</h2><p> only seems to support Clang compiler. Visual Studio throws up.</p>
<h2><a href="./capnproto.html">Cap'n Proto</a></h2><p>Overkill. Too much stuff. But their zero compression is cool.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

83
docs/logon_protocol.html Normal file
View File

@ -0,0 +1,83 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<link rel="shortcut icon" href="../rho.ico">
<title>Logon protocol</title> </head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Logon Protocol</h1>
<h2>User functionality</h2><p>
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.
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

74
docs/multicore.html Normal file
View File

@ -0,0 +1,74 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Multicore</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Multicore</h1>
<p> At the same time as the security crisis has hit, the multicore crisis
has hit.&nbsp; A short while ago we were dealing with isolated serial
machines, now our programs must utilize a sea of machines.&nbsp; </p>
<p> Multithreading is hard.&nbsp; Doing it routinely, doing it with large
programs, invariably fails.&nbsp; </p>
<p> Intel, NVIDIA, and Google however have this crisis well in hand.&nbsp; </p>
<p> Big Businesses are attacking the problem, with competence and success,
and we can leave them to it and not worry too much. Google is pioneering
the way, and Intel and NVIDIA are making similar tools available to the
masses.&nbsp; </p>
<p> Since massive parallelism is a hard problem, requiring good people, much
thought, and much care, the meta solution is to solve that problem as few
times as possible, and re-use the resulting solutions as much as
possible.&nbsp; If, for example, one uses the hash table provided by
Intel’s threaded building blocks library, the Intel library and Intel
compiler takes care of hash table related coordination issues that
otherwise the programmer would have to take care of, and would probably
foul up.&nbsp; </p>
<p> Intel has provided a bunch of utilities that make it a good deal easier,
Vtune, thread checker, OpenMP, compiler auto parallelism, Intel Thread
Checker, Intel VTune Performance Analyzer, and most importantly, Threaded
Building Blocks.&nbsp; it is still hard – but no longer damn near
impossible.&nbsp; </p>
<p> Back in the days when there was one hardware thread of execution driving
multiple software threads, locking worked well. These day, not so
well.&nbsp; Rather, it is often more desirable to use a lockless
transactional approach to handle any shared state.&nbsp; Shared state is
hard, better to share nothing – or to leave any sharing to those utilities
that someone else has already written and debugged.&nbsp; If rolling your
own, better to use InterlockedXxx than Lock.&nbsp; Note that you construct
your <a href="interlockedxxx.html">own InterlockedXxx</a> operation for
any Xxx using InterlockedCompareExchange. </p>
<p> The big solution, however is that pioneered by Google. Rather than each
programmer designing his own multithreading and multicore design, one has
a small number of very general massively parallel algorithms embodied in
useful software for massaging masses of data.&nbsp; The programmer then
calls that software and lets it handle the parallelism.&nbsp; Google’s Map
Reduce is the classic example of this, but every database servicing a web
application is also an example of this, since one typically has many web
servers running many processes all of which might potentially update the
same data at the same time, and the database is supposed to sort out any
resulting problems, while the developers write in single threaded python
or ruby on rails, and let the database handle any problems related to
massive parallelism.&nbsp; </p>
<p> Google’s “app engine” allows programmers to write straightforward single
threaded python code in the easy to use Django framework that can be
executed in a massively parallel manner with coordination between many
parallel processes being performed by Google’s datastore.&nbsp; </p>
<p> In short, the multicore crisis, unlike the other crises I describe in
this group of web pages, is well in hand.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

174
docs/net_money.html Normal file
View File

@ -0,0 +1,174 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style><title>Net Money</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Net Money</h1><p>
Net money. Net money that is reasonably liquid, that many
people acquire, that many people spend, money that is
readily convertible to worthwhile goods and services. Don’t
worry about blinding and all that. Once any sort of net
money is flowing in large amounts, all that stuff then
becomes possible and desirable. If there is no liquidity,
nobody cares about blinding, and if you have blinding it
does you no good anyway without liquidity. </p><p>
Once we get that, we will shortly get it all. As long as we
do not have that, we have very little. </p><p>
Digicash failed because it was proprietary. For net money to
be a success we need a standard for transferring promises to
pay that is separate from the software issuers, and thus
separate from the issuers of promises to pay or deliver. It
has to be a standard such that anybody can play, anyone can
write software that will interoperate with software written
by others, and anyone can issue promises to deliver anything,
so that Ann, Bob, and Carol can transfer and exchange
promises between each other subject only to the need to trust
each other, without needing permissions or licenses from
anyone else. </p><p>
And it has to have software that is competitive with existing
methods of transferring value. </p><p>
Credit cards are very competitive for transactions of modest
size, because of the additional services, in particular
dispute arbitration and resolution provided by the card
issuers, and because of their large installed base. Smaller
players cannot hope to compete in that area. </p><p>
We have however no adequate means for small payments, five
dollars to fractions of a cent. This offers a fertile
opportunity for the development of net money. </p><p>
We also have no entirely satisfactory means for large low
margin payments. </p><p>
The large payment problem could be addressed by some system
that provided a tight connection between internet money and
US dollars in US banks, or, better, a system that provided a
tight connection between internet money and US dollars in non
US banks, or, if we had a large and liquid micropayment
system, it could be provided by a tight connection between
micro and macropayments. </p><p>
If several banks in some moderately popular banking haven
allowed people to transfer funds instantly and cheaply from
one account to another within the haven, through digitally
signed messages passing through https protocol, this would
make it possible to readily solve the large payment problem
by offering the means to create a tight connection between
net dollars and offshore dollars. If this were done then the
revolution would ensue within a few years. So far none have
been willing to do this, perhaps out of fear of reprisals,
more likely out of sheer inertia. </p><p>
The offshore dollar system is probably larger and more
liquid, and is certainly considerably more free, than the
onshore dollar system, but it is inconvenient for modest
payments. People use it primarily for transfers of many
thousands of dollars. Also the connection between the
offshore dollar and the onshore dollar is weak, because it is
inconvenient, slow, and costly, to transfer dollars between
the offshore and onshore banking systems. </p><p>
I see no possibility that anyone will be permitted to create
a strong connection between an internet dollar and the
onshore dollar, whereas it is quite possible that someone
will get away with creating a strong connection between the
internet dollar and the offshore dollar. </p><p>
Alternatively, (and perhaps more likely) a satisfactory
solution to the micropayment problem automatically brings in
its train a solution to the large payment problem, since the
software must accumulate many small promises into a few large
promises, and provide means to transfer these large promises
through numerous intermediaries, thus a large volume of
micropayments will create the liquidity for macropayments.
We do not need the banks to win this one, though they would
be very handy. </p><p>
Large promises to pay could acquire value not through a fast
and cheap connection to the banking system, whether onshore
of offshore, but through a fast and cheap connection to the
micropayment system, resulting in an internet dollar that
derives its liquidity from the internet market, and is
coupled to the US dollar no more strongly, and no less
strongly, than the offshore dollar is coupled to the onshore
dollar. </p><p>
Of course for this to work, we will need a large and liquid
market for aggregated micropayments. The existing finance
systems for self publishing, dirty pictures, and gambling,
really do not work very well, so there seems an obvious and
large market for micropayments. </p><p>
One cent, or half a cent, is probably the sweet spot for
pages and dirty picture, with quarters being the sweet spot
for games and gambling. </p><p>
Obviously pay pages cannot and should not be searched by
search engines, so the typical design would be a free,
searchable, index page containing lead in paragraphs and pay
links to the non free pages on the site, or a collection of
free summary pages each containing a pay link to the
corresponding non free page, or (better) both a free index
page and also a collection of free summary pages. </p><p>
We want the payment system to introduce no additional delays
when we click on a link, so the index page should cause any
necessary negotiations between the browser and server so that
the server is ready to accept the coins of this particular
user, so that the user can get the pay page with a single
message, a single URL containing a coin. The server then
immediately starts downloading the page without waiting for
any further messages to complete, and simultaneously attempts
to deposit the coin. </p><p>
Suppose you are browsing dirty pictures, and both you and the
server are clients of the same token issuer. Then the token
issuer knows that you are browsing the dirty picture pages,
and knows how much money the dirty picture issuer is making.
</p><p>
But for the scheme to be successful, we need many token
issuers, and the means to transfer aggregated token values
between issuers, so that in general the entity that takes
your bank money and provides you with net money, and the
entity that takes the dirty pictures servers net money and
provides it with bank money, will be very different entities,
probably in very different jurisdictions, separated by a
chain of intermediaries, who have an economic incentive to
aggregate transactions, thus obscuring individual spending
and getting. </p><p>
If any creditworthy person can issue tokens, privacy is not
such a big problem, and if the aggregated values representing
large numbers of tokens are readily transferable in a large
liquid market intermediary market, it is not a problem at
all, since the dirty picture issuer and the guy looking at
the dirty pictures are likely to be anonymous to the token
issuer. </p><p>
Micropayments have not failed. They have not yet been tried.
We still have not seen a scheme attempted that had all the
requirements that real net money will need. It is simply
quite a bit of work to design these things, and to get them
deployed in a form that ordinary mortals can use. </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

144
docs/network_operating_system.html Normal file
View File

@ -0,0 +1,144 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style><title>Network Operating System</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Network Operating System</h1>
<p>The network should be stupid, and the applications smart as argued in the
1984 paper <a href="http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt">End-to-End
Arguments in System Design</a> by Reed, Saltzer, and Clark.</p>
<p>The question then, is how do applications find each other and talk
securely to each other?</p>
<p>End-to-end as an ideal in network design has come under attack from
network suppliers.</p>
<p>to paraphrase Trotsky, the endpoints may not be interested in the middle,
but the middle is interested in the endpoints.</p>
<p>Providing optimized service, providing degraded service (for example to
collect rents to restore service to normal levels), and surveillance are
all reasons for the network to take an active interest in what its
endpoints are doing.</p>
<p>The solution is end to end encryption at the packet level, encryption on
top of udp, with reliable encrypted transport on top of unreliable
encrypted transport rather than SSL on top of TCP – but, as experience has
proven, end to end encryption does not work with unique true names, which
is what DNS was designed to support. Need Zooko’s triangle in place of
DNS, rather than on top of DNS, so that you find the network address of an
entity from the hash of the rule that its public key satisfies.</p>
<p>In other words, for the end points to enforce the end to end ideal a
whole new infrastructure on top of UDP and in place of TCP, DNS, and CAs
is needed.</p>
<h2>Solution</h2>
<p>Build a crypto currency with the equivalent of namecoin built in.</
<p>Link in the </p>
<p><br/>
</p>
<p><br/>
</p>
<p>Naming system follows Zooko’s triangle. </p>
<p>Because humans cannot themselves perform cryptographic operations, nor
remember public keys as names of entities, the user interface becomes part
of the security problem.&nbsp; It is typically the unsecured part of a
secured channel, the weak link in the chain.</p>
<p> Thus a security proposal needs to be described with a description
centered on its user interface and perceived behavior.&nbsp; The security
behavior should reflect the user interface – it should behave as the user
expects.</p>
<p> Many of our security problems arise because the email interface is
inconsistent with its actual security properties:&nbsp; An email that
appears to come from Bank Alice does not necessarily come from Bank Alice.</p>
<p> Thus general security requires a secure name system, Zooko’s triangle,
which requires not just a bunch of cryptographic algorithms, but a bunch
of tools for managing and sharing information about names – requires a
whole lot of secure user interface.</p>
<p> Your browser bookmark list, and your various contacts lists <i>almost</i>
support Zooko’s triangle, and <i>almost</i> have Zooko like behavior, but
have various small subtle deviations in their behavior that make them not
quite suitable.</p>
<p> This is in part because they were built without concern for security,
and in part because they are built on top of a system that is wildly
different from Zooko’s triangle.</p>
<p> In a system based on Zooko’s triangle, you would not have DNS, for DNS
exists to render true names for network addresses humanly memorable, and
in Zooko’s triangle, true names for network addresses are not humanly
memorable.&nbsp; Thus building a Zooko system on top of the existing
system turns out to be problematic, even though in practice DNS urls are
seldom all that humanly memorable, so that actual usage and actual user
interfaces have become Zooko like, it insecurely maps non unique human
memorable names to unique, non human memorable, insecure names.&nbsp; A
secure naming system would securely map non unique human memorable names
to unique non human memorable cryptographically secure names.</p>
<p> DNS requires a center, since the supply of human memorable true names is
limited, and therefore true names have to have a price.&nbsp;&nbsp; This
center leads to no end of security problems.&nbsp;&nbsp; A system in which
true names are or contain hashes of rules identifying public key chains
can be centerless, and therefore end to end.</p>
<p>Globally unique names for mutable items are a public key plus some
network hinting non human readable information, plus non human readable
distinguishing information for all the many mutable items associated with
a single public key.&nbsp; Immutable items are a hash plus some network
hinting non human readable information. .</p>
<p>These get converted into a network address and shared secrets.&nbsp; The
conversion process should support NAT penetration.&nbsp; The network
address and shared secrets constitute a connection, which may then, for
some objects, get converted into a local copy of the object. </p>
<p>At this point protocol negotiation occurs, in which the protocol is
identified absolutely, and in a duck type sense.&nbsp; (You don’t want to
make a connection that is then going to crash for failure of <a href="./duck_typing.html">duck
typing</a> – you want such failure to occur immediately, where it will
give a version error, rather than in the middle of the interaction, where
it will give an obscure <a href="./duck_typing.html">duck type</a>
error.&nbsp; Remember, end users, not programmers, will be making
connections, thus the flexibility of <a href="./duck_typing.html">duck
typing</a>, which causes much grief for programmers, would cause
intolerable grief for end users. </p>
<p>Since we automatically have end to end encryption, we can transmit
capabilities, including capabilities with monetary value.&nbsp;</p>
<p>Capabilities with monetary value are a low level concept, a software
primitive that all applications can easily and routinely use.&nbsp; A bank
account is a swiss numbered account, and all you need to “open” an account
is to invent a public key, private key pair.&nbsp; </p>
<p>Everything in the system is an object, in the sense of uniting data and
code, and exposing some interfaces&nbsp;</p>
<p>The code that implements those interfaces is downloaded with the data -
but, as with Caja, it is limited by the capability discipline so that it
cannot take over your computer.&nbsp; It can only do stuff through
capabilities you pass in, or that it brings with it.&nbsp; It does not
have access to the rest of your computer, except through such capabilities
as you pass in, as in Caja.&nbsp;</p>
<p>Every object can be inspected by other objects, in that other objects can
see its methods and the argument types that its methods require, as in the
Go language’s duck typing.&nbsp;</p>
<p>With some objects, you can interact with them over the network, passing
them object identifiers as arguments, with other objects, you download a
local copy, and with some objects, you can do either one and it is
optimized on the fly.&nbsp; The distinction is translucent, but not
transparent. </p>
<p>The most trivial objects, and one of the most common arguments, is an
immutable string or number, which can be represented by its hash, but for
small strings, is usually identified by the string itself.&nbsp;&nbsp;
However, if what you are passing is, for example, access to a routine that
makes available resources on another computer, a high level object, duck
typing means that it is known to be a high level object, not a string that
the program applies ad hoc code to to turn into a high level object.&nbsp;
If it is an object of the wrong type, duck typing will generate a
relatively meaningful error message.</p>
<p>Objects interact by message, rather than by call – every object has a
message pump.&nbsp; If you want to have call semantics, have to
laboriously put in Send message, handle reply.<br/>
</p>
<p>&nbsp;</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

68
docs/networking_protocol.html Normal file
View File

@ -0,0 +1,68 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Networking Protocol</title> </head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Networking Protocol</h1><p>
This is focussed on Bitcoin and everything blockchain is a centralized ledger. Worse than that – it’s the One True Ledger. It isn’t like gold. Gold one can have directly on one’s person or indirectly in a vault somewhere. </p><p>
It is possible to have a crypto currency similar to bitcoin where though there is one global ledger recording what public keys own what, there is no way to tell which human actors know the private keys corresponding to those public keys. </p><p>
The downside of Chaumian e-cash is very simple. You need a single centralized trusted server holding a small number unshared secrets. At two in the morning Mueller kicks down your door and demands you alter the behavior of your server in ways that make it profoundly untrustworthy. While he is at, holds a gun to your head and takes the secrets, charges you with tax fraud, money laundering, etc, and puts you in solitary confinement pending trial so as to make it impossible to organize your defense. </p><p>
A crypto currency needs to be centerless – it needs to able to survive the seizure of key servers by a hostile powerful party. </p><p>
Trouble with bitcoin is that it is not centerless – proof of work winds up being centralized in a small number of extremely powerful and extremely expensive computers. </p><p>
Thus we need a system with proof of stake, and not only proof of stake, but proof of client stake – the power over the system needs to reside with peers that have a lot of wealthy clients – and it needs to be hard to find who the clients are, and where they are keeping their secrets, so that even if Mueller seizes important peers on charges of tax evasion and money laundering, does not thereby gain control. </p><p>
If the system handles an enormous number of transactions, peers are going to be big and expensive, thus vulnerable to people like Mueller armed with vague and open ended charges of tax evasion and money laundering. Hence the power of peer over the currency needs to be proportional to the wealth controlled by the secrets held by that peer’s clients. And that peer’s clients need to be free to move from one peer to the next, and apt to move to peers that make it difficult for Mueller to find their clients. </p><p>
Need a crypto currency where Bob can prove to the whole world that he paid Ann such and such amount, in accord with such and such a bill, but no one else can prove he paid Ann, nor that there ever was such a bill, except he shows them. Bitcoin is far too traceable. We need controlled traceability, where the parrticipants can prove a transaction to third parties and the world, but the world cannot. And Bob needs to be able to prove what the payment was about, that it was part of a conversation, a meeting of minds. </p><p>
The reason we have end user demand for crypto currency is the same as the reason we have end user demand for gold. </p><p>
When quasi governmental entities started freezing the accounts of "Nazis", "racists", "Russian trolls", and suchlike, a lot of "Nazis" and "Russian trolls" moved to crypto currency, shortly thereafter followed by a great many very wealthy men who were worried that when they needed their wealth in a hurry, they would suddenly become Nazis and Russian trolls also, and their wealth would suddenly become inaccessible or worthless. </p><p>
For a long time the big demand for crypto currency has been wealthy Chinese evading currency controls, but with the recent crackdown on hate speech, we are seeing massive American and European demand, which directly resulted in the recent spike in crypto currency values. </p><p>
Another substantial source of demand for crypto currency, which has been around since the beginning, is buying steroids and suchlike over the internet, but the really huge move in crypto currency demand came during the recent crackdown on political activists. </p><p>
Obviously political activists do not in themselves have enough wealth to cause such a huge move in market value, but when you go after political activists, you are going to make a whole lot of wealthy people reflect that they are none too popular either. If you are a rich man, makes sense to put a significant chunk of your wealth in crypto currency in case you suddenly become a refugee. For example, if, as is looking increasingly likely, there is a pogrom against whites in the USA, a whole lot of rich people will flee to Singapore, China, Russia, Hong Kong, the Philippines, and Dubai with nothing but the clothes they stand up in, and the master secret controlling their crypto currency in their heads. </p><p>
So that Bob can contract with Ann without the transaction becoming visible to the world, the crypto currency needs to embed an encrypted overlay network, a method for people to have forbidden conversations about forbidden things. Contracts imply conversations, and secret contracts imply secret conversations. Untraceable payments imply untraceable conversations. </p><p>
Full bore totalitarianism sufficient to shut down crypto currency is not far from full bore totalitarianism sufficient to shut down the internet. </p><p>
Full bore totalitarianism sufficient to shut down the internet is going to strangle your economy. If your enemies are markedly wealthier than you are, it is likely to be a problem. North Korea is poor in substantial part because it dares not allow something like the internet to exist. Any contact with the west is used by the state department as a vector for subversion and color revolution. </p><p>
North Korea wants to open up, and has repeatedly attempted to open up, but wants it to be safe for it to open up. If it does open up, expect a lot of North Koreans to buy crypto currency. </p><p>
To create an internet where I cannot send arbitrary packets to an arbitrary machine, you are going to have to license every hub that is allowed to accept packets. Expect some serious disputes as to who gets to do the licensing. </p><p>
Turning the whole world into one big North Korea is not going to be feasible, and attempting to do so is likely to result in a large part of the world glowing in the dark. </p><p>
However, turning the US into Venezuela is entirely feasible, might well happen. We have a potential Democratic Party president who proposes to do exactly that. </p><p>
Which is exactly why wealthy Americans are buying crypto currency, so that they can run to those parts of the world that do not turn into North Korea or Venezuela. </p><p>
The best example of repression which does not bother people too much is China, and the great firewall of China. And until recently, the major demand for crypto currency came from Chinese evading currency controls. </p><p>
So, to accomplish the goal of shutting down crypto currency requires world wide internet repression at levels considerably more repressive than China, which is likely to be disruptive and damaging within a single nation and a single economy, and apt to lead to conflicts if attempted globally. </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

36
docs/normalizing_unicode_strings.html Normal file
View File

@ -0,0 +1,36 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Normalizing unicode strings</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Normalizing unicode strings</h1><p>
I would like strings that look similar to humans to map to the same item. Obviously trailing and leading whitespace needs to go, and whitespace map a single space.</p><p>
The hard part, however is that unicode has an enormous number of near duplicate symbols.</p><p>
Have you already read<br/>
<a href="https://www.unicode.org/reports/tr15/tr15-45.html">https://www.unicode.org/reports/tr15/tr15-45.html</a> ?</p><p>
Our normalization code is in<br/>
<a href="http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=libraries/liblunicode;h=4896a6dc9ee5d3e78c15ed6c2e2ed2f21be70247;hb=HEAD">http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=libraries/liblunicode;h=4896a6dc9ee5d3e78c15ed6c2e2ed2f21be70247;hb=HEAD</a></p><p>
I am going to have to use NFKC canonical form for the key, and NFC canonical form for the display of the key.</p><p>
Which once in a blue moon will drive someone crazy. "Its broken" he will say </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

62
docs/openvpn.html Normal file
View File

@ -0,0 +1,62 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Openvpn</title> </head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Openvpn on the cloud</h1><p>
Figure out what version of debian you are running:<pre>
cat /etc/*-release && cat /proc/version
</pre><p>
Browse to <a href="https://openvpn.net/download-open-vpn/">openvpn downloads</a>. Find the file you want, in this case <code>http://swupdate.openvpn.org/as/openvpn-as-2.6.1-Debian9.amd_64.deb</code><pre>
wget http://swupdate.openvpn.org/as/openvpn-as-2.6.1-Debian9.amd_64.deb
dpkg -i openvpn-as-2.6.1-Debian9.amd_64.deb</pre><p>
Setup program will echo:<pre>
Please enter "passwd openvpn" to set the initial
administrative password, then login as "openvpn" to continue
configuration here: https://172.245.71.242:943/
</pre><p>
You should now have an admin webserver on port 943 with username openvpn and the password you just created.</p><p>
Upon logging in with your recently created username ane password, you should see:<pre>
To download the OpenVPN Connect app, please choose a platform below:
OpenVPN Connect for Windows
OpenVPN Connect for Mac OS X
OpenVPN Connect for Android
OpenVPN Connect for iOS
OpenVPN for Linux
Connection profiles can be downloaded for:
Yourself (user-locked profile)</pre><p>
The user locked profile is your client.ovpn file, the OpenVPN Connect for windows is your client program that uses it.</p>
<hr><p>
To set up OpenVPN, need tun and tap enabled. This is done from the control panel of the virtual server, not by installing software as root.</p><p>
All the <a href="https://nikinuryadin.wordpress.com/2010/04/16/step-by-step-setting-up-openvpn-in-debian-with-routing-tun-connection/">tutorials on openvpn</a> assume TUN is installed</p><p>
Tap is hugely better than TUN if your vpn host is just one machine, rather than a vpn network. And I suspect it is going to be hugely harder for anti vpn measures to detect it. </p><p>
These days, every package and its little brother has gui elements, and you cannot walk through a Debian 9 configuration and setup tutorial without being asked to pop up something graphically.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

35
docs/passphrases.html Normal file
View File

@ -0,0 +1,35 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Passphrases</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Passphrases</h1>
<p>Passphrases are of course stronger and easier to
remember than passwords, but whitespace causes endless
problems, which in turn cause endless support calls</p>
<p>Whitespace in a passphrase should therefore be
canonicalized before hashing. Multiple spaces, tabs, and
carriage returns should become a single space. Leading and
trailing whitespace should be stripped.</p>
<p style="background-color :
#ccffcc; font-size:80%">These documents are licensed under
the <a rel="license"
href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

46
docs/payments_contracts_invoices_and_reputational_data.html Normal file
View File

@ -0,0 +1,46 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Payments, Contracts, Invoices, and Reputational data</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Payments, Contracts, Invoices, and Reputational data</h1>
<h2>The problem to be solved</h2>
<h2>*****</h2>
<p>.&nbsp;</p>
<p>.&nbsp;</p>
<p>.&nbsp;</p>
<h2>*****</h2>
<p>.&nbsp;</p>
<p>.&nbsp;</p>
<p>.&nbsp;</p>
<h2>Value and Exchange</h2>
<p>An exchange of value consists of a contract to exchange ("trade"), two
transfers of value (value for value), coordination problems
("settlement"), and dispute resolution services ("failure").</p>
<p> Hence, reliability of exchange is dominated by reliability of transfers.
And, transfers of value are dominated by reliability of basic issues of
value, including storage.</p>
<p> What might be seen as sort of semantic short-cut is that a value system
may be considered reliable if and only if it can participate in an
exchange. </p>
<p>&nbsp;</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
<p>.&nbsp;</p>
</body>
</html>

120
docs/protocol_negotiation.html Normal file
View File

@ -0,0 +1,120 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Protocol Negotiation</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Protocol Negotiation</h1>
<p> Once a protocol is in use, it becomes very hard to change. If one person
updates the server, and the client is not updated, everything breaks. </p>
<p> And so, we are stuck with a lot of frozen protocols, many of which are
in urgent need of change, but to change, requires wide consensus, which
requires a big bunch of people showing up at a meeting, but at such
meetings very little gets done, and what gets done is stupid.</p>
<p> If a standard is successful, more and more people want to be in the
committee, many of whom represent business profit centers and government
special interests, and who really do not understand much about the
technology, except that any change might be adverse to the very important
people who sent them there.</p>
<p> As the committee gets larger, it gets more unworkable, and as it
represents more and more special interests, it gets more unworkable</p>
<p> In order to have to have a system where the internet’s protocols can be
upgraded, and new protocols introduced, without central coordination,
protocol negotiation, where client and server first discuss what protocol
version they will be using, has to be part of every protocol, all the way
down to the level of TCP and UDP.</p>
<p>These days everyone builds in protocol negotiation, often on top of SSL, which is on top of TCP, resulting in three additional round trips.</p>
<p>And then a widely distributed client or server breaks the protocol negotiation, which no one notices because it interorperates with all existing implementations, until someone tries to introduce a new protocol, whereupon the new code implementing the new protocol is blamed for its failure to interoperate with the existing clients and/or servers, and then we get another layer of protocol negotiation on top of all the existing layers of protocol negotiation.</p>
<p>TCP has built in protocol negotiation, eight bits worth, which turned
out, unsurprisingly, to be inadequate.</p>
<p> For the content of the internet to be free from central control, we need
to ensure that the address spaces and protocols are free from central
control.</p>
<p> When an old protocol is broken, clients and servers that have not
upgraded to a new improved protocol will remain forever, so the old
defective protocol has to be supported forever – without, however,
allowing an attacker a downgrade attack. </p>
<p>To prevent a downgrade attack, there has to be some way of disabling
protocols in the field, where the signed ban on certain protocols flood
fills from one program to the next.</p>
<p> Often, it is impossible to support the old clients, because protocol
negotiation was never adequately designed in, or because it was designed
in but was designed vulnerable to a downgrade attack.</p>
<p>But let us suppose the protocol negotiation was well designed:&nbsp; The
committee has to assign a code.&nbsp; And of course, they will only assign
this code to a protocol that they agree is right – and nothing gets done,
for there is always some vested interest that for some strange and obscure
reason does not want this protocol to exist.</p>
<p>One solution is to have quite large protocol identifiers, or arbitrarily
large variable length protocol identifiers, so that anyone can whip up a
protocol and assign it an identifier, and hack a client and server to use
it, without having to walk it past three dozen members of the committee. </p>
<p>But then, of course, we would probably wind up with a lot of protocols.
&nbsp;This could potentially lead to a lot of protocol negotiation round
trips </p>
<blockquote>
<p>Do you speak protocol A? No.</p>
<p>Do you speak protocol B? No.</p>
<p>Do you speak protocol C? No.</p>
<p>Do you speak protocol D? No.</p>
<p>Do you speak protocol E? Yes. </p>
</blockquote>
<p>One solution to this problem is to have complete lists of protocols, call
it a protocol dictionary, which dictionary maps the long probabilistically
globally unique protocol names to short deterministically unique local
protocol names, and gives an order of preference.&nbsp; If the client
names a dictionary that it supports, and/or the server names a dictionary
that it supports, then they can usually come to immediate agreement. <br/>
</p>
<p>If, for example, the client wants to talk protocol X, it proposes one or
more dictionaries of updates to protocol X, implying that it can talk all
the updates listed in each dictionary, and an order of preference among
dictionaries</p>
<p>If the server recognizes one or more of the dictionaries, it then
responds with one of the protocols listed in the first dictionary that it
recognizes, by its short dictionary name, and the conversation proceeds.</p>
<p>An ordered list of dictionaries is identified by a public key and a short
human readable type name.&nbsp; The typename is only unique with respect
to the dictionaries signed by this public key, thus ftp version 1, ftp
version 2, ftp version 4 ... </p>
<p>The globally unique identifier of a dictionary is the hash of the rule
identifying its public key, plus its typename and version number.</p>
<p>If the server recognizes the hash of the rule identifying the dictionary
public key, but not the version number, it responds with the highest
version number that it does recognize, and the most favored protocol in
that dictionary.&nbsp; Thus if the client requests a protocol of
dictionary version n, it has to know dictionaries versions 1 to n, and be
able to deal with all protocols in versions 1 to n, if only to the extent
that it is able to fail the protocol gracefully. </p>
<h3>The one true ciphersuite</h3>
<p>Why would you want multiple ciphers?</p>
<p>In case one turns out to be weak. </p>
<p>OK, suppose one turns out to be weak.&nbsp; Oops, Malloc can now launch a
downgrade attack.</p>
<p>So, if supporting multiple ciphers, you need a floodfill mechanism where
you can disable the bad ciphersuite in the field.</p>
<p>Each program supporting a set of ciphersuits has a set of signatures it
recognizes as authoritative.&nbsp; If another program that it talks to has
a revocation of ciphersuite, and it recognizes one of the signatures on the
revocation, the revocation floodfills.</p>
<p>So, ideally you should support multiple ciphersuites – but if you do,
have a mechanism for field revocation.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

145
docs/protocol_specification.html Normal file
View File

@ -0,0 +1,145 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Protocol Specification</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Protocol Specification</h1><p>
In general, supposing your server, written in Javascript in the node.js environment, is assembling a response to an end user from services provided by other servers, is there any reasonable alternative to having them all talk JSON?</p><p>
RPC calls usually use XDR, which is binary, or JSON, which is ascii. There are handy libraries to take care of all the boring sockets stuff for you for these cases.</p><p>
Node.js tools to use RPC are available for RPC in JSON, but is there any easy way to access RPC calls in binary formats such as XDR, ASN.1 PER, or Avro Apache from node.js. Or to do something similar?</p><p>
I am not asking what is the best way, or what can be done, because anything can be done with enough hard work, but rather what ways have standards to avoid reinventing the wheel, and libraries to do as much of the work as possible.</p><p>
<a href="https://stackoverflow.com/questions/47298905/binary-rpc-in-node-js/47368469#47368469">asked Nov 15 at 3:33</a></p><p>
<a href="https://github.com/mtth/avsc">avsc</a> implements Avro’s RPC specification, you can use it to expose "type-safe" services over any transport (e.g. HTTP, TCP, WebSockets). The <a href="https://github.com/mtth/avsc/wiki/Quickstart#services">quickstart guide</a> goes through a simple example that should help you get started.</p><p>
Your avro is in javascript, and is, I assume, expected to run under node.js Apache provides avro to run as compiled C++, Java, Python, and C#. So it looks like an Avro service communicating in binary can communicate between any two environments – also avro can serialize to memory, which should make possible operating system and compiler independent hashing of data. Looks like a standardized solution. So this would seem to imply that Avro services adequately cover anyone who wants to talk to anyone in any environment. </p><p>
This question turned out to be problematic and insoluble, because I want hashes defined independently of a particular computer and compiler. Which turns out to be hard. ASN.1 theoretically solves this problem, but in practice sucks horribly.</p><p>
I wish I had a MsgPack that was not dynamic, but would guarantee predefined MsgFormats. Human generation of on the wire message formats case by case should also be considered. Let us see how cryptonote deals with this problem. </p><p>
Looks like Avro gives me what I want: Predefined message formats.</p><p>
To render them human readable output them as YAML, but reading YAML is problematic, because YAML could represent anything, including something hostile. So any message from outside has to be presented in Avro.</p><p>
Cryptonote: https://github.com/cryptonotefoundation/cryptonote</p><p>
https://cryptonotestarter.org/create-wallet.html</p><p>
What is a protocol? Protocols wind up being defined by implementations,
which people attempt, not very successfully, to reverse engineer. By trial
and error they get their client to work with the existing server, and
their server to work with the existing client, and so an ill defined
protocol becomes over time even worse defined.</p><p>
To address this problem, we have ASN.1, ASN.1 PER, and ASN.1 DER</p><p>
ASN.1 is a language for describing data.</p><p>
It is also a compiler for generating C code to process the data described. Some people complain that DER is too complex for anyone to get right.</p><p>
The library https://github.com/vlm/asn1c supports canonical per, but does not entirely support Visual Studio.</p><p>
On the other hand Avro apache seems to be a more complete solution, addressing the problem of protocol negotiation, RPC calls, and map reduce calls. I don’t think the ASN.1 crowd have even thought of map reduce.</p><p>
And there is the oldie but goodie, XDR, which is just the simplest possible way of avoiding compiler and endian dependancy. <a href ="https://www.cprogramming.com/tutorial/rpc/remote_procedure_call_start.html">There is a nice XDR RPC library.</a> ONC RPC is standardized by the Internet Engineering Task Force (IETF) as RFC 1831. It is based on the External Data Representation standard (XDR), known as RFC 4506 (see References). But, on the other hand, everyone using node.js seems to be doing RPC ins JSON.</p><p>
Maybe this whole canonicalization question is just too hard, and need ad hoc solutions. Surely crypto libraries have serialization formats? Let me see what cryptonote does. No point in reinventing the wheel.</p><p>
A type that is becoming increasingly common is unordered name value mapping, where a lot of names have defaults, and people keep adding new names.</p><p>
Now if you send the names with the message every single time, it is a huge overhead. Which is what you wind up with with JSON based rpc calls.</p><p>
So you want compiled message types, which wind up as a C++ object – and when someone wants more fields, he has a derived type of the C++ object, with the new fields having default values, allowing you to cast the object to have additional names and derived types as needed.</p><p>
MsgPack is binary, and has modules for every language and environment you have ever heard of, and lots of languages you have never heard of, and library code to do anything you want, but it is all dynamically typed, which means it is not as efficient as PER.</p><p>
It is basically YAML in binary, in that MsgPack messages correspond closely to YAML documents. Because it supports every language, you can use MsgPack to talk C++ to node.js, and YAML to talk to humans.</p><p>
Dynamic typing means that a hostile evil program could send no end of messages in MsgPack that your program is not equipped to deal with. The great thing about PER is that anything that you are not expecting just gets magically rejected.</p><p>
Both of them, Per and MsgPack totally punt on the issue of protocol negotiation, whereas Avro apache has support for protocol negotiation. It combines static and dynamic typing, but dynamic requires both sides to play nice. Evil program with surprise data structures will just have the connection shut down on it.</p><p>
ASN.1 Per punts by requiring both sides to be in total agreement about the ASN.1 schema at compile time, MsgPack punts in the opposite way by being able to send any schema, including hostile schemas that are totally suprising, unexpected, and impossible for the recipient to deal with.</p><p>
Maybe the way to go would be to agree on a dictionary mapping numbers to ASN.1 schemas at connection establishment, and if agreement, send schema number and binary blob in a MsgPack message, if no agreement, send dynamic message with a schema GUI, and the end user has to deal with it as best he can. If receiving a message with a schema guid, then precompiled code to generate the corresponding C++ object from the MsgPack message, and to generate a MsgPack message from the C++ object. On reception, execute the generic object->process_on_receive(&amp;connection) job on the received object. Which typically will look up the table for the object to which this is a response. Everything in the table is a pointer to a common base type, but, on getting the object, executes a derived operation.
For an expected message, which is anticipated to be a response to a previous message, the response should contain an opaque callback which was sent with the previous message, which is an index into a table of local objects whose base type can run time check that the message is of the type that they expected. (All schemas corresponding to data that can be received, or loaded from files, derive from a base type that reports their schema, so any time you deal with a message, it is mapped into a C++ object that will only be dealt with by code that at compile time expects that object.)
Thus every transmissable object has Yaml serialization, MsgPack serialization, Asn.1 Per serialization, Yaml serialization, Yaml serialization inside MsgPack, and Asn.1 Per serialization inside MsgPack. If MsgPack or Asn.1 throws on receiving a message, terminate the connection. If it throws on sending a message, it is a bug.
But I don’t see that Avro Apache can talk to node.js, in part because it wisely refuses to be fully dynamic.</p><p>
There is a review of more serializers than you can shake a stick at <a href="https://github.com/thekvs/cpp-serializers">https://github.com/thekvs/cpp-serializers</a>
If you attempt to hand generate code for processing packets described by
ASN.1, you will probably get it wrong and your head will explode.&nbsp;
Hence ASN.1 is much cursed and condemned.&nbsp; </p><p>
Don’t do that.&nbsp; Don’t hand write code to generate or interpret ASN.1
data packets.&nbsp; You are unlikely to succeed, and your code will have
mystery bugs.</p>
<p>ASN.1 PER is ASN.1 data description compiled to produce efficiently
compressed data packets that conform to a description in ASN.1, and
efficiently decompresses them.</p>
<p>ASN.1 DER&nbsp; that data description that generates data packets with a
description of what the data packet means, so that if two programs sign
the same ASN.1 DER data, they agree not only on the data, but on the
meaning of that data, and if one program means the same thing as the other
program, the signatures will come out the same.</p>
<p>Use it.&nbsp; ASN.1, used right, is what is needed to rigorously define a
protocol so that a client written by one person will work with a server
written by another.</p>
<p>There is much loud cursing about the fact that the data on the wire is
humanly incomprehensible, and that the code that converts it into program
data structures is humanly incomprehensible.&nbsp; No one should be
looking at machine generated code, because machine generated code is
notoriously incomprehensible.&nbsp; The question then is, does the
compiler work, and is the compiler usable.</p><p>
There is an <a href="http://lionet.info/asn1c/faq.html">internet tool for compiling asn.1 specifications into C code</a>.</p><p>
If a program reads DER or BER data, the result is apt to be disastrous.&nbsp; BER and DER can express an arbitrary data structure – and thus can crash the program receiving the data, probably causing it to execute transmitted data as code.</p>
<p>You can’t depend on a DER or BER bit string being able to map back into any well-defined ASN.1 objectthat the program was designed to deal with.&nbsp;&nbsp;</p>
<p> Incoming data should be parsed as the expected and bounded size data
structure, thus we need something that can generate parsing code from a
description of the data at compile time.&nbsp; We need compile time
descriptions of the data, not run time descriptions, because the program
that uses the incoming data will unavoidably rely on compile time
description of the data.
<br/>
<br/>
PER, however cannot receive unexpected data structures, because the
expected data structure is specified at compile time, not run time.&nbsp;
Malicious or faulty data will generate an error, not a crash.<br/>
<br/>
Thus all data should be received as PER or by a format with the properties
of PER.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

195
docs/ripple.html Normal file
View File

@ -0,0 +1,195 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style><title>Ripple</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Ripple</h1>
<p>This rambling explanation fails to explain what
level of anonymity is provided, or how it is provided.
We want aggregative anonymity, cryptographically
secured, with money flowing on chains of trust.</p>
<p>Fails to explain need for integration with
reputation management, fraud problem, ordering, person
to person transactions</p>
<h2>How internet money should work</h2><p>
The idea is that an organization will issue some kind of money
equivalent – promises to deliver US dollars, promises to deliver gold,
shares, promises to deliver some service. Let us call the organization
issuing the money Big Money Issue Corp, and the money
Big Money Issue Corp OUs.&nbsp; </p><p>
You will be able to buy Big Money Issue Corp OUs from
Bob, and use them to pay Carol for something. You will
be able to do this over the internet by instant
messaging – dropping some money into the instant
message. Let us suppose you pay Carol to deliver some
cigarettes. Carol will know you paid her, and what you
paid her for, and you will be able to prove that Carol
agreed to deliver cigarettes for a certain payment and
that you paid to deliver some cigarettes, prove it to
the whole world, which ordinarily you will not want to
do, but you might want to do if the deal goes bad.
</p><p>
Now the most obvious way to make this work is that the
people operating the financial system know everything
about everyone, and all transactions are on their
computers, readable by the government, who can thereby
tax everyone. </p><p>
We don’t want a technology where everyone deals
directly with Big Money Issue Corp, because then Big
Money Corp will be under pressure to refrain from
dealing with this or that person or group, and then it
will have to know its customers, and for a big
organization to know its customers is likely to be
inefficient for the big organization and burdensome for
the customers. </p><p>
We want payments to be provable, and linked to deals,
so that if something goes wrong, the customer can do
something about it – but provable and deal linked
payments run contrary to anonymous payments. </p><p>
Cypherpunks had a vision of how anonymous funds
transfer would work on the internet, which vision ran
into some disastrous obstacles.&nbsp; The cypherpunk vision
was built around Chaumian anonymity, but this
technology does not in itself provide many capabilities
that are necessary for internet money, and makes
implementing those capabilities more difficult.&nbsp; In
the Chaumian vision, everyone dealt directly with Big
Money Corp, but Money Corp could not link Bob’s payment
to Carol receiving money. Unfortunately, this meant
no recourse for Bob if he paid and Carol stiffed him,
plus the fact that everyone dealt directly with a
single center provided a single point of control
</p><p>
<a href="%3Chttp://ripple.sf.net/">Ripple</a> is a
brilliant insight, great idea, but suffers from the
critical mass problem that afflicts any proposal to
provide competition to the existing government run
money system.&nbsp; </p><p>
In addition to the critical mass problem, governments
tend to treat competition as illegal, once the
competition gets large enough to to make a dent -
observe what is happening to e-gold. E-gold is
attempting to comply with overbearing and intrusive
regulation to the great detriment of its business and
its customers, but the government has no intention that
it be possible for e-gold to comply. Of course a
decentralized system is a lot more resistant to this
than a centralized system such as e-gold. E-gold looks
like being the Napster of internet money – one that
showed the way, though it was ultimately suppressed.&nbsp;
</p><p>
Therefore, in my opinion, the best prospect for a
decentralized money system such as ripple is in some
activity that is already somewhat illegal, for example a
file sharing system, in which the participants grant
each other upload credits.&nbsp; </p><p>
Ripple, as it stands at present, does not really address
the routing problem, (in the sense that the proposed
routing algorithm sucks), and indeed does not need to,
for there are very few participants. For a file
sharing system, would need to be more DHT like.&nbsp;
</p><p>
To the extent that a payment system is anonymous, tends
to be used by ordinary criminals and ponzis. This gives
government justification and excuse to shut it down.&nbsp;
</p>
<h2>Requirements of an internet payment system:</h2><p>
Payments should be identifiable by the participants, but
not identifiable by outsiders, and should automatically
generate and maintain the appropriate records on the
participants machines. If you pay a net presence for X,
you should be able to prove to outsiders that you paid
that particular identifiable net presence for that
particular X, but outsiders should not be able to prove
it except with your assistance. This requirement
presupposes a mechanism for identifying net presences -
Zooko based yurls, and/or authorized certificates.
Since we obviously want to transfer money between people
who do not necessarily have authorized certificates,
have to support yurls, which means we have to first have
a yurl system, which at present we do not.&nbsp; </p><p>
To resist shutdown, and keep costs low, a payment system
needs to inherently implement "ripple", making every man
a bank. Ripple, however tends to reduce the profits of
the currency operator, and is some work to implement, so
is generally not done.&nbsp; </p><p>
The problem with Chaum’s anonymous cash, and Brands'
anonymous cash, as generally envisaged, is that it
relies on a single central server, with which everyone
has a relationship – a star shaped network. Internet
networks really have to be power law networks – neither
star, nor entirely equal peers. A single central server
is a central point of failure, a point that governments
can attack.&nbsp; </p><p>
"Ripple" means that if the Bank of Whatsit implements
ripple, then you don’t need an account with the Bank of
Whatsit. You can do fine with an account with someone
who has an account with the bank of Whatsit. Hey
presto, a power law network.&nbsp; </p><p>
So if you want to buy a domain name registration from
Wonton, a registrar that has an account with the Bank of
Whatsit, and you have an account with Joe, who has an
account with the bank of Whatsit, then Joe’s machine
tells Bank of Whatsit to pay Wonton. The Bank of
Whatsit only knows that Joe payed Whatsit. Joe knows
that you paid Wonton, but does not know what you paid
Wonton for. Wonton knows you paid them through the Bank
of Whatsit, does not know or care who Joe is, knows what
you paid them for, but cannot prove what you paid them
for. You know, and can prove, that you paid Wonton, and
can prove what you paid them for.&nbsp; </p><p>
Now what I have described is all account based – no
Brand style or Chaum style anonymous tokens. But if the
Bank of Whatsit implements ripple, Joe, or anyone else,
*can* implement Chaum style or Brand style anonymous
tokens. Further, you can pay Wonton using Joe’s tokens
even if Wonton has no relationship with Joe, and has
never heard of these new fangled tokens, and the Bank of
Whatsit has never heard of them either, for through
ripple you can turn the token payment into an ordinary
account payment from the Bank of Whatsit.&nbsp; </p><p>
Thus if we had payment guys implementing ripple, they
could avoid the heat that is likely to arise from
implementing Chaum style tokens, indeed be entirely
unaware of either those tokens or that heat, combining
the anonymity that comes from Chaum style tokens with
the anonymity that comes from the faceless crowd of a
power law network.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

49
docs/rpc_to_theblockchain.html Normal file
View File

@ -0,0 +1,49 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>RPC to the blockchain</title>
</head>
<body><p><a href="./index.html"> To Home page</a></p>
<h1>RPC to the blockchain</h1><p>
Bitcoind is an rpc server, and bitcoin-qt can be started to also operate as a server. It operates JSON-RPC interface over HTTP over sockets. (But you have to talk JSON HTTP if engaging it directly. There is a <a href="http://wxcode.sourceforge.net/docs/wxjson/">wxJSON source only library</a> for wxWidgets, but it is not part of wxWidgets itself. There are a <a href="http://www.json.org/">huge number of JSON libraries</a>, and we don’t have any real need to represent JSON data in wxWidgets objects.</p><p>
One data structure we need, and bitcoin does not have is the partial Merkle-patricia trie. As these can potentially get quite large, we likely want a format more efficient than JSON. And for generally short messages, tcp is overhead.</p><p>
If we want anyone to be able to talk the chain, if we want anyone to be able to write programs that interact with the chain, we need to talk JSON in http on tcp. But if we just want our custom client to talk to our custom server, we should talk binary, since they are largely using the same internal format anyway – modulo the usual byte order problems.</p><p>
This means that one can programatically do all the things the bitcoin-qt gui does, such as generate an address for payment, and check if that payment has been made.</p><p>
bitcoin-cli is an rpc client, that provides a command line interface to the server, so that a human can do the same things as a program. </p><p>
Eloipool is an example of program that calls the server</p><p>
RPC calls are fully documented <a href="https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs">here</a>, giving an example of how to call bitcoind directly from curl.
Bitcoin-qt provides a console that allows the same command line controls as bitcoin-cli. One can issue command lines in bitcoin-qt as if using the bitcoin-cli client:<br/>
Click "Help > Debug window". You should see the "Debug window".<br/>
Click "Console" tab. You should see the console screen where you can enter bitcoin-cli commands.</p><p>
To run bitcoin-qt as a server add to bitcoin.conf<br/><code>
server=1<br/>
rpcuser=myname <br/>
rpcpassword=password</code></p><p>
The bitcoin server binds to local host, so the password is not that critical. It should not be possible to speak to the server from outside the machine. We, of course, being oriented towards everyone running a client and only a few people running a server, will offer a safe subset of calls that are globally accessible from the entire internet – which will require a process that resists DNS attacks.</p><p>
Bitcoin_QT offers <a href="https://gist.github.com/donpdonp/4997294">a lot of command line options</a>, and these command line options parallel the ones in the conf file.</p>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

357
docs/safe_operating_system.html Normal file
View File

@ -0,0 +1,357 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Safe Operating System</title>
</head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Safe Operating System</h1><p>
Capdesk was a demonstration and user interface mockup
that demonstrates that a secure operating system could be
user friendly. Polaris demonstrates that such a system
can be mostly backwards compatible, that existing windows
software can run on such a system, and for the most part
neither the user nor the program will notice any
difference. </p><p>
We now know, pretty well, how to build an operating
system that is largely immune to viruses, Trojans and
spyware.&nbsp; “Capdesk” was a demo of the design
principles for a secure desktop operating system.&nbsp; It
has led to similar, though more realistic versions
retrofitted to windows and Linux, and
<a href="http://www.cl.cam.ac.uk/research/security/capsicum/">
sandboxes</a> based on the same concept. </p>
<ul>
<li>Resources, such as files and directories, should be
owned by packages, or package*user, not merely users,
so that one package cannot interfere with another package,
so that packages cannot run with the full authority
of the user, and so that a package cannot be furtively installed
(for to be installed, has to be allocated resources, such as
a directory for its executable files to live in)</li>
<li>The principle of least authority: Programs
should not run with the full authority of the user.&nbsp;
Your solitaire game does not need authority to read your
contact list and spam them in each other’s name, put a
plugin in your browser that will watch what websites you
login to, stash the information and sell it to
advertisers, monitor your bank logins, collect the
passwords and bank account numbers, sell the collected
information to the highest bidder, use all your disk
space to store child porn, spam the entire world offering
to sell the child porn on your computer in your name,
while forwarding any payments to Nigeria, and use any
remaining bandwidth to launch a distributed denial of
service attack against popular web sites.
</li><li>The powerbox user interface pattern, so that
instead of each program needing durable authority to do
anything the user might command it to do, it instead
receives ephemeral authority to do the particular thing
that the user has commanded it to do..
</li><li>Default deny: Instead of having a long, and ever
growing list of forbidden programs and trying to detect them
in an ever more tedious virus and malware scan, it should
only be easy to install programs signed by an authority that
the operating system writer or end user has chose to trust.
Installation of other programs should require resort to the
command line or some similar obstacles. There should be no
one click installs of unsigned software, and even when
installing signed software the user should see, as on the
Android operating system, a list of authorities the program
wants, and have to approve those authorities. </li> </ul><p>
The key design pattern is the use of a “powerbox” to
unite permission and designation.&nbsp; Trusted software,
the powerbox, stands in the user interface between the user
and the less trusted software, and when the user commands
the less trusted software to do something, he unknowingly
grants it permission – and without that permission, the
less trusted software should be <em>unable</em> to do that
thing.&nbsp; </p> <p>
Following Ivan Krstić’s design we can use this software
pattern to ensure:</p>
<ul>
<li>
No program that can be executed merely by viewing
email or browsing to a web page or reading a document
can have persistent effects, or indeed effects outside
that web page’s window and server, except by something
such as offering up a standard widget that end user can
click on to get a save file dialog, or offering up a
standard widget that the user can click on to spawn a
new window, because these standard widgets
enable the powerboxes that grant permissions.</li><li>
No package can be installed except by the end user
clicking on the standard install widget.&nbsp; </li><li>
No package can be installed except it comes from a
source that the end user or OS writer has chosen to
approve, or a source approved by an authority they have
chosen to approve.&nbsp; </li><li>
No package can be installed except through the
standard series of installation dialogs.&nbsp; </li><li>
Every package so installed gets a corresponding and
effective series of uninstall dialogs.&nbsp; No package
can rootkit itself, even if the user is root, because
it cannot edit operating system files, or indeed any
files outside its own package, unless the user
chooses to open such a file through its file open
dialog.&nbsp; Deallocating all resources granted to a package
will uninstall the package, because the package has no
means to insert its code outside those resources behind
the user’s back.&nbsp; </li><li>
If a package needs authority to do X once installed,
it will only get it if the installation dialogs depict
the package to the end user as one of a category of
packages that the designer of the standard installation
interface has decided needs authority to do X.&nbsp; Thus
for example a sound player needs access to /dev/dsp. It
does not need authority to read arbitrary directories,
delete files, and so forth, because when it opens the
file select box, it opens a powerbox, trusted software
that <em>does</em> have authority to do file stuff – on
the users command, rather than the sound player’s.
command.&nbsp; Similarly an indexing program will have very
broad authority to read files, but very limited authority
to write files or access the internet. There
will be a couple of dozen package types.</li><li>
If a package needs some combination of authorities that
the designer of the installation interface failed to
anticipate, then the user must initiate some complicated
process and type in the necessary options to create a
new category of installable package in preparation for
installation, rather than clicking OK after the
installation is under way.&nbsp; </li><li>
A package can only be upgraded if the upgrade package is
of the same category as the package to be upgraded and
thus has the same authorities, and the upgrade and
package to be upgraded carry digital signature evidence
that they originate from the same entity.&nbsp; </li><li>
Any package that if installed that might look confusingly
like another installed package will be flagged by the
install process, which will ask the user for a petname
to differentiate the packages.&nbsp; </li><li>
Each package gets its own <a href="safe_operating_system_config_data.html"> exclusive
area to store configuration information</a>, and data in
this area can only be changed in ways that the package
is willing to accept, short of the package being
uninstalled altogether.</li><li>
The operating system provides protocol negotiation to
minimize <a href="bitrot_and_protocol_negotiation.html">bitrot</a>.&nbsp;
</li>
</ul>
<p>
When a package is installed, the install scrip will use
one of a limited set of possible install patterns.&nbsp; For
this design pattern to be useful, installable packages
need to come with install scripts adapted for the secure
system, scripts that tell the secure system’s
installer what sort of a package is being installed.&nbsp; A
typical install pattern for an editor would give it read
access to a very limited set of files, and read write
access only to files in a special directory for that
package and user – the package’s configuration area.&nbsp;
To access any arbitrary file the user wanted edited, the
“open file” on any program menu would launch a
powerbox – trusted software that enables the user to
select a file.&nbsp; The standard file select dialog box
would be provided by the file selection powerbox, which
quietly grants the less trusted program access
<em>only</em> to selected files – thus combining
designation with permission.&nbsp; </p>
<p>
Among the needed powerboxes are:</p>
<ul>
<li>
The file select dialog.</li><li>
The command line, which should not only tell programs what
files to access but also enable them to access those files
and only those files.</li><li>
The project file powerbox, which manipulates files that
are lists of files and lists of tasks for other programs
to do with those files, and enables those
programs to work on those files.</li><li>
The account configuration powerbox, which enables programs
such as one’s email client or one’s newsreader that access
particular hosts through an account on that host, hosts
that seldom change, to access those particular hosts using
those particular protocols.&nbsp; It should be possible for
the end user to launch this powerbox from within the
browser from the host’s web page with the configuration
details filled in, if the host cooperates and is aware of
the protocol for doing so.</li>
</ul>
<p>
To describe the powerbox user interface pattern for yet a
third time: The way Linux and Windows work at present is
that most programs have the power to access most files
and most resources.&nbsp; Most programs run with the full
power of the user, and anything the user is permitted to
do, they are permitted to do.&nbsp; They are only
<em>supposed</em> to access the things you tell them to,
but can do anything that you could do.&nbsp; With the
powerbox user interface pattern, most programs are
<em>incapable</em> of accessing most files and most
resources unless you tell them to, prevented by the
operating system from doing pretty much anything until
commanded to do it.&nbsp; </p>
<p>
To describe the concept of combining designation with
permission again: No one bothers to manage permissions
until disaster ensues, and if they have to manage
permissions, it is seldom clear what they should do – or
more likely what they should have done to avoid the
disaster that has just happened.&nbsp; Therefore we have to
attach permission to the coat tails of designation,
otherwise there is no way permissions are going to be
managed correctly.&nbsp; Fixed up versions of Linux such as
Plash, unlike the usual sandboxing approaches, remove the
need to specify detailed policy information for each
application by leveraging the information that is already
available about the application in the form of standard
package dependencies and by making smart use of existing
facilities like the “Open File” dialog to infer
security information.&nbsp; </p>
<p>
Plash, however, is limited in what it can do without
extensive user management and understanding, because it is
an add on for Linux, rather than its own Linux
distribution with its own repository of properly wrapped
packages.&nbsp; If the user has to think about security, it
is not secure.&nbsp; Most installable packages need to come
out of the repository pre wrapped, rather than each user
himself having to wrap each package, for in practice the
end user swiftly gets sick of having to wrap each
package, no matter how easy we make it, and worse, starts
automatically clicking through dialogs without paying
attention, thus creating a worse security hole than the
ones we are trying to close.&nbsp; </p>
<p>
The powerbox pattern is that we leverage designation
information to generate permission information, and the
powerbox user interface pattern is that we hook the user
interface to extract transient permission information from
user choices.&nbsp; Programs running under Plash can access
only those files outside the sandbox that the user has
selected.&nbsp; That dramatically limits the damage a
malicious program can do.&nbsp; </p>
<p>
Because normal programs have very limited write privileges
in such an operating system, a flaw in one program cannot
give the attacker control over the entire machine, and is
considerably less likely to give the attacker durable
control over even that program.&nbsp; A flaw in the browser
would give the attacker control over that browser page,
but without the ability
to write to arbitrary files on the disk, it is difficult
to leverage that control into control of all open browser
pages, and more difficult to leverage that control into
control of the browser after the next browser restart.&nbsp;
</p>
<p>
These fixed up versions of Linux and windows are operating
systems that are a fair approximation to a secure user
friendly environment, a decent first stab at it,
sufficient that we can see what the final version should
look like: Polaris, Bitfrost and Plash.&nbsp; All of these
have serious problems, largely of incompleteness, and of
horrible kludges to retrofit uncooperative software
designed for an OS where each app gets total power, but
they are workable and effective.&nbsp; </p>
<p>
Of these secure versions, “Bitfrost” was the most
thoroughly thought through, shortly before the time that I
write this, though the situation is changing too rapidly
to easily track.&nbsp; This document is not intended to
provide an up to date bibliography of the latest progress.
Bitfrost, as envisaged, has the
requirement that any software that is installed, has to be
installed by its custom installer which provides a secure
environment for that software – and <em>only</em> software
that has been wrapped in a package suitable for
installation on Bitfrost can be installed, which means that
the implementer can patch software that needs patching,
and give special privileges to software that needs special
privileges, while doing extra diligence on such software.
Most software needs no special privileges or modification,
and is thus trivial to wrap, though we need better
facilities to allow the end user to wrap stuff, and more
kinds of powerbox.&nbsp; When last I looked there were only
two real powerboxes, one for file menus and one for the
command line interface, and the rest are more demos than
finished products.&nbsp; Indeed, I did not look that hard.&nbsp;
Perhaps they were all demos to some extent, but even if
all the powerboxes were mere demos back then the design is
sound.&nbsp; We now know how to build a malware proof
operating system.&nbsp; </p>
<p>
In addition to protecting against abuse of trust, such as
the program that reads private information and supplies it
to the attacker who sells it to whoever is interested, we
also need to protect against undue resource
consumption.&nbsp; </p>
<p>
Install should automatically and necessarily be
reversible, by simply deallocating whatever resources and
and privileges have been allocated to the package.
Consumption of background processing time, background
memory, boot up time, and so forth, all need to tracked
and billed to each installed package, and the resulting
information made available to the user in easily
intelligible form, so that the user can detect those
packages that are hogs.&nbsp; No program should be able to
bring the system to a grinding halt by sucking up all
available CPU cycles, or all available memory, or all
available disk space.&nbsp; It should be easy for the user
to monitor and restrict resource consumption, both for
particular processes, and for any particular installed
package.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

100
docs/safe_operating_system_config_data.html Normal file
View File

@ -0,0 +1,100 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
a:hover {
color: #FF0000;
}
dl {
margin-left: 2.5em;
padding-left: 0;
margin-top: 0pt;
margin-bottom: 20pt;
padding-top: 0pt;
padding-bottom: 0pt;
top: 0pt;
bottom: 0pt;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Configuration Data in a Safe Operating System</title></head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Configuration Data in a Safe Operating System</h1>
<p>In Microsoft Windows and in Linux, managing configuration data
has grown to become a huge problem.  </p><p>
In Windows this is stored in the registry, which is
hierarchical database.  In Linux, this is stored in
plain text files, which is something of a problem as it
is easy for these to be incorrectly formatted.  On the
other hand, the Windows registry is also a problem, for
it is a database that fails to scale.  We need a
database that can efficiently handle a hierarchical tree
containing a very large number of very small flat tables
- the file system already provides hierarchical trees,
and Sqllite provides flat tables, so the quick and dirty
way to do that is the way Linux already does it. 
</p><p>
But both systems suffer from the big problem that any
program can write to the configuration data of any other
program, and no program can protect its configuration
information from being changed into an inconsistent
state.  It is very common to make a mistake editing
the configuration data, and suffer mysterious and
dreadful consequences.  </p><p>
So each package should get its own private data spaces,
in which it stores data both as plaintext, and as
Sqlite databases.  </p><p>
We want fine grained control over access to these
data spaces, so that an installed package can prevent
them being changed in surprising ways or to
inconsistent states.  </p> <dl><dt>
Home</dt><dd> pseudo persistent process private
mutable data, only accessible by single process
that is an instance of the correct program of the
package</dd><dt>
Tmp</dt><dd> non persistent mutable data, only
accessible by that process, deleted when the non
persistent process ends.</dd><dt>
Etc</dt><dd> read only data available to all
instances of a program from the package run by the
same user as the current instance. Editable only
by that user through a facility provided by the
package, which locks normal programs of the package
from reading material subject to change. </dd><dt>
Root</dt><dd>read only data available to all
instances of a program from the package on a given
machine. Editable only by root through a facility
provided by the package, which locks normal
programs of the package from reading material
subject to change.</dd> </dl><p>
In all cases, only package code should be able to change
the data, though this may well mean that the standard
configuration editing tool sends messages to package
code, which package code can then act on such messages
in the standard generic fashion, or ignore such
messages, or reject some change messages with an error
message.  </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

65
docs/scalable_reputation_management.html Normal file
View File

@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Scalable Reputation Management</title>
</head>
<body>
<p><A href="./index.html"> To Home page</A> </p>
<h1>Scalable Reputation Management</h1><p>
The hardest part of the cypherpunk plan is scalable reputation management.</p><p>
We plan to have a global store of named rhocoins, thereby squaring Zooko’s
triangle. Associated with each name will be a nameserver, which tells you how
to contact that individual, his websites, etc, which have public keys signed by
the rhocoin private key. You start out assuming that he and all his associated
data are on that nameserver, and it gives you a permanent or temporary redirect,
signed by a public key authorized by his rhocoin private key to give such
redirects, which key contains a limit for that key and all the redirects.</p><p>
He has a collection of positive reviews, that chain to spent coins in the blockchain, via his offer or payment request, and also to a recent global hash. But what about negative reviews?.</p><p>
For that, we need reputation managers, two or three, that hold a replicated collection of negative reviews.</p><p>
The payment request chains to a name being monitored by the reputation monitors, but the person making the payment is generally anonymous. So he could manufacture positive reviews in unlimited number by sending payments to himself. So the reputation monitoring entities need to monitor spam, much as google has a problem with link farms. If the same entity gives reviews to entities that do not spam, or is unreasonably prone to giving frivolous negative reviews. One way around this is to give reviewers reputation points on the basis of the money they have paid to entities with good reputation. Paying one ro to a hundred entities gives you more reputation than paying money one hundred ro to one hundred entities..</p><p>
We really want to subdivide reviews into good, grey, and possible spam. which, suggests a logistic curve over the sum of a bunch of logistic curves.</p><p>
ln {B+&sum; ln(P<sub>i</sub>+1)}</p><p>
This means it is not enough to connect the review to the rocoins. Needs to be connected to a cheap but permanent identity. So, the transaction chains to the payers through a Merkle-patricia tree, which links to each payment request, which links to the durable named identity of the wallet receiving it, and the durable but possibly nameless wallet paying it. This part of the chain is not on global canonical blockchain, but in the private blockchains of the receiving and paying wallet, which can be visible, if the payer or the payee make parts of it public. Any conversations about the payment before the transaction are directly rendered immutable by the global blockchain, so we know the that Ann, the party that controls the wallet posting a review made the payment, but, without Bob’s cooperation, cannot know that parts of the conversation that Ann claims were seen by Bob after the transaction actually were seen by Bob. We can, however, if either Ann or Bob makes the payment request public, know that Bob requested payment for such and such, and Ann paid. If someone is telling fibs about what happened after the transaction, we can know from the global shared blockchain that Ann is not fibbing about what Ann paid and Bob promised to deliver.</p><p>
The transaction is on the global shared canonical blockchain, and links through a Merkle dac, which is not on the global shared canonical blockchain, to immutable information about who made the payment, who received the payment, and why. Subsequent conversations about the transaction are mutable, unless, of course, they result in another payment. If there is a continuing relationship, and continuing transactions between Ann and Bob, then the entire conversation up to the most recent payment is immutable.</p><p>
The problem is sybil attack. A transaction creates reputation for buyer and seller, creating an incentive to create a network of dummy transaction, to generate positive reputation for scammers, and to attack the reputation of good actors.</p><p>
But, we assume that there are a small number of big centralized reputation brokers, with big machines and custom algorithms that they continually tweek.</p><p>
One solution is to have sixty four different reputation colors, each represented by eight byte number. Known entities, that we have external information indicating that supply real goods and services, get a mix of colors reflecting the source and content of that external information. Unknown actors randomly and automatically get a color from a different palette. A transaction causes the parties get more of the same color as the entity that they transact with.</p><p>
Known link farms get colors from the bad palette.</p><p>
So, the main network of legitimate actors will tend to get all the same color mix, because every legitimate customer buys from lots of legitimate sellers, and every legitimate seller sells to lots of legitimate buyers.</p><p>
Networks of fakes will get their own distinct color, because the reputation circulates inside that network. The big giveaway will not so much be bad colors versus good colors, but the failure of colors to homogenize. All the good actors will tend to develop rather similar colors, each link farm will have its own distinct color. Every transaction inside your own little group will tend to result in more of your group color, and less of the general mix.</p><p>
With forty colors, we have a trillion different composite colors, so we randomly assign each seller entity that collects reviews an initial pool of distinct color, and they get additional color from feedback on each transaction of the entity transacted with. If feedback from a wallet never seen before, it has no color, so they get more of their own color, and it gets a pool of the color of the entity they gave feedback to proportional to the amount paid. Every completely unknown seller entity gets one hundred units of various randomly chosen colors. External reputational indications result in additions of color reflecting that external information.which will get mixed in with throughout the network of real actors and real feedback.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

63
docs/seed_phrases.html Normal file
View File

@ -0,0 +1,63 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
table {
border-collapse: collapse;
}
td, th {
padding: 6px;
border: solid 1px black;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Name System</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Seed phrase wallets</h1>
<p>Bitcoin has had big problems with wallet security, and eventually converged on the <a href="https://en.bitcoin.it/wiki/Seed_phrase">seed phrase system</a>. A seed phrase generates a sequence of key pairs.</p>
<p>This is implemented as the BIP-039 standard.</p>
<p>On the other hand, <a href="https://keybase.io/warp/warp_1.0.9_SHA256_a2067491ab582bde779f4505055807c2479354633a2216b22cf1e92d1a6e4a87.html">Warpwallet</a> indicates that with password strengthening, forty eight bits of passphrase security suffices, which if using the BIP-039 system is five words.</p>
<p>For durable storage, write the words on art low acid paper in pencil, and spray with art fixative to prevent the pencil from smudging.</p>
<p>We want to be able to create a receive only wallet, that can sign on with a name controlled by its master wallet, and can receive money that only its master wallet can spend.</p>
<p>In order for it to receive money, it has to be able to generate an indefinitely large number of public keys, that it cannot generate private keys for. It generates a pseudo random sequence, integer hashed with a 128 bit value, and multiplies the public key of the master by that pseudo random number. To spend the money, the master multiplies the private key by that pseudo random number.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">Example code</a> for maintaining a tree of deterministically generated keys, which is not exactly what we want, but which is similar.</p>
<p>One evident defect of this system is that leaking a single private key corresponding to the public keys generated by the receive only wallet, plus the information that enables the receive only wallet to generate an unlimited number of receive keys, leaks them all. It might be safer just to give the receive only wallet a great big bundle or receive keys.
<p>A key that owns a name, can sign a statement allowing another key to use that name for some defined time, so the always logged on wallet can operate. If the always logged on wallet gets stolen, it will receive payments for some other key sequence, </p>
<p>so, given a strong secret, we generate two wallets – one of which can receive money, can chat, can assert it rightly has a certain zooko or ro identity, and one of which can spend that money and assert the same identity. Chat includes making conversations and files available, either generally, or two identities that have a key . This implements sale of books by the receive only wallet.</p>
<p>Everyone is converging to BIP0032 BIP0039 wallets</p>
<p>But electrum has some powerful and convincing objections to BIP0039 wallets</p>
<p>You want the wallet to depend only on the secret list of words, not on the wordlist, because the wordlist is likely to change. But you don’t want to let the user construct his own secret capriciously, because he will fuck up, so you need a checksum so that his own custom secret will not work.</p>
<p>So here is my solution: You hash his word list through secret strengthening, but the strengthened secret has to have some zeroes in the right places. Our code for generating the word list generates a hundred or so wordlist till it finds one that works. If the user tries his own master passphrase, probably will not work. </p>
<p>We need to have an explicit standard for generating the wallet from the passphrase, because with bitcoin a seed phrase only works with the same wallet software that created it. If storing for a long period of time, the seed phrase will stop working.</p>
<p>Therefore, need a standard test vector: A wallet <em>must</em> generate this (empty) test wallet with this phrase, which test wallet is authorized to use the name "anon 1". We need to make the construction of a wallet from a test phrase part of the standard, so that future wallet software will give you access to the same account for the same passphrase as past wallet software.</p>
<p>It has to be a standard for wallet software that for a given pass phrase that is valid for the standard wallet, any new wallet software shall give you access to the same accounts, and a test vector for this has to be part of the system from the beginning, giving a sequence of wallets authorized to use the names anonymous_1 anonymous_2, and anonymous_3</p>
<p><a href="coinb.in">coinb.in</a> is the client wallet for bitcoin. Before I roll my own, I need to understand what they are doing and why they are doing it.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

36
docs/spam_blogging_logon_email_money.html Normal file
View File

@ -0,0 +1,36 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>How to Save the World</title>
</head>
<body>
<h1>The general problem of spam, logon, blogging, and money</h1><p>
blogs – each blog, unlike usenet, is inherently moderated, solving the moron problem, but lacks usenets sophisticated newness and reply tracing. RSS feeds give newness information, but lose rich content (an entirely unacceptable loss) and lose the already inadequate threading information. </p><p>
Google provides a workaround for the newness problem, but really, you want to be able to immediately see what is new on a thread, wherever posted, so the Google fix is pretty much half assed – showing you new blog posts, rather than new action on a thread.</p><p>
The correct behavior is to show you a thread, rather than a blog – generated from your view of the thread (what is new to you in the thread) plus the blog’s view of the thread (what it thinks is not spam). Anything posted to a thread should appear on all blogs participating in a thread, unless the blog owner chooses to filter it – blogs should work like usenet, but with html instead of plain text, decentralized spam filtering and censorship of morons. </p><p>
The underlying mechanism should be usenet like on a thread basis – each blog gets the latest posts on a thread from those blogs and threads it is subscribing to – for some blogs automatically, for some with varying degrees of blog owner review. </p><p>
test</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

35
docs/spam_filtering.html Normal file
View File

@ -0,0 +1,35 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Spam filtering</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Spam Filtering</h1>
<p>Divide the text into natural units – type of text, headers, paragraphs, and standard parts. Divide the larger scale units into natural units identifying word and sentence boundaries.</p>
<p>Perform a dimensional reduction to forty plus dimensions on all possible substrings of the smallest natural units, up to a maximum of ten plus words or so. Store the dimensionally reduced vector of each substring in a hash table of a few gigabytes maximum, small enough to fit in ram, preferentially keeping common substrings, and dumping old and seldom seen substrings, thereby developing a dictionary of common words and phrases. That certain substrings have been seen before implies that they can be useful in classification, while never before seen substrings are useful in classification only as a count of never before seen substrings. This is our lowest level of order detection.</p>
<p>Label each larger unit by a vector which is the sum of the dimensionally reduced vector of the previously seen substrings, plus the novelty level (random untintellible jibberish would have a high novelty level and a small, and therefore uninformative vector)</p>
<p>Perform an entropy reduction (identification of natural groups within dimensionally reduced space) on the set of larger units.</p>
<p>Repeat recursively all the way up to the largest natural unit, to get the natural groupings of the largest units. A familiar sentence has familiar substrings. A familiar paragraph has familiar sentences. A familiar message has familiar paragraphs. Of course, we notice a problem in that messages obviously belong to multiple groups – all messages originating from this address, all messages with the same text style as messages originating from this address, all messages on this topic, all messages trying to sell something. The problem is not merely grouping, but rather extracting significant dimensions from random dimensional reduction. We are looking for a reduced set of high level dimensions that predict a whole lot of low level dimensions, and a massive brute force search for correlations between the lowest level entities (substrings) is going to turn up correlations which are merely an accidental and arbitrary result of forms of order that the algorithm is incapable of perceiving.</p>
<p>Learn which natural groupings of the largest units the end user identifies as spam, and label each such natural grouping by the most common large substring that identifies the largest unit (that gives the most information about) the largest unit as a member of its class.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>
//////

112
docs/squaring_zookos_triangle.html Normal file
View File

@ -0,0 +1,112 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Squaring Zooko’s triangle</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Squaring Zooko’s triangle</h1>
<p>
Need a system for handing one’s keys around that protects end users from the horrifying sight of actual keys or actual strong hashes of keys.</p>
<p>
But at the same time the system has to not say, "I can’t deliver your message to that person because an invisible gnotzaframmit that I won’t describe to you seems to be unavailable to me in the flabogrommit."</p>
<p>It seems like the clever bit of CT is the insight that some actions, like
a CA signing a cert, are intended to be public, and so should be forced
(via clever crypto) to take place in public. This makes me wonder what
other crypto actions should also take place in public, in a way that
doesn’t permit hiding them from the world.&nbsp; </p>
<p>Revocation&nbsp; </p>
<p>Software releases&nbsp; </p>
<p>Mapping of email address to public key&nbsp; </p>
<p>Delegation of DNSSEC keys&nbsp; </p>
<p>&nbsp; </p>
<p>Of course, globally visible events need to take place at a globally
visible time. The most widely available time is GPS time (which is 19
seconds off the commonly used time), and which is available from the
seldom connected pps line.</p>
<p>At present, unfortunately, anyone who wants gps time has to do his own
soldering and hack his own software. There is a pre soldered device
available, but it is hard to get.&nbsp; </p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p>
Imagine skype as originally designed, (central authority maps public and
private keys to user names) plus a key continuity feature, plus the seldom
used option of doing a zero knowledge shared passphrase to detect man in
the middle.&nbsp; </p>
<p>
The possibility that the zero knowledge check could be used would deter
powerful adversaries, even if seldom used in practice. The more powerful,
the greater the deterrent effect.&nbsp; </p>
<p>
It is not totally end to end, central authority can listen in, but the
check would limit the amount of listening.&nbsp; </p>
<p>
It can be made completely end to end for strong passwords. Assume login is
by zero knowledge password protocol, which means that the central
authority does not know the end user’s password, for strong
passwords.&nbsp; </p>
<p>
The secret key is generated from the strong secret supplied by central
authority, plus the password.&nbsp; </p>
<p>
When you change your password, you generate a certificate mapping your new
public key to your old public key, which certificate makes other people’s
key continuity check happy.&nbsp; </p>
<p>
If key continuity fails, people get a warning, but they don’t have to
click it away, for that just trains people to click it away. They can just
continue right on and not pay attention to it.&nbsp; </p>
<p>
Or they could use the zero knowledge shared passphrase procedure to detect
man in the middle.&nbsp; </p>
<p>
So, if non paranoid, and using easy passwords, works like skype used to
work. No interception except by central authority, and central authority
cannot intercept everyone, or even large numbers of people.&nbsp; </p>
<p>
If paranoid and using strong passwords, provides OTR like end to end
capability.&nbsp; </p>
<p><br/>
</p>
<p><br/>
</p>
<p>Key management is an unsolved problem.&nbsp; In my biased opinion the
best<br/>
solution was my Crypto Kong, which received limited takeup.<br/>
<br/>
So, in conclusion, don’t make people manage keys, though that should be an
option for the seriously paranoid.<br/>
<br/>
Instead, autogenerate the keys with zero knowledge passphrase logon.<br/>
<br/>
If he uses a password weak enough to fall to an offline dictionary attack,
this is equivalent to the old skype system, where central authority
manages his keys and he has password logon.&nbsp; If he uses a stronger
password, equivalent to a salted strong passphrase system.</p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p>&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

184
docs/the_internet_money_solution.html Normal file
View File

@ -0,0 +1,184 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;
}
dl {counter-reset: item1;
margin-left: 1.5em;
padding-left: 0;
margin-top: 0pt;
margin-bottom: 0pt;
padding-top: 0pt;
padding-bottom: 0pt;
top: 0pt;
bottom: 0pt;
}
dt {
margin-top: 6pt;
}
dt:before {
counter-increment: item1;
content: counter(item1) ". ";
}
a:hover {
color: #FF0000;
}
</style><title>The Internet Money Solution</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>The Internet Money Solution</h1><p>
To transfer money, transfer promises made by very creditworthy
well networked entities.</p><p>
Swift, the electronic interbanking system, the system banks
use to communicate with each other, describes the service it
provides as secure authenticated store and forward non
repudiable messages with proof of delivery – a bank cannot
deny sending the message, nor deny receiving it. </p><p>
The system has about ten thousand members and handles about
twenty million messages a day, too many for a bitcoin like
system. Your store would grow at about four gigabytes a
day.</p><p>
To handle this in a system based on a global hash: </p><p>
The global hash for each time period is shared by almost
everybody, as are all the nodes near the root. Each member
only needs to retain the near root data, the data that they
care about, and paths from the data that they care about to
the root. </p><p>
Ann maintains a signed hash of all messages sent from Ann to
Bob, also a signed hash of all messages received from Bob.
These hashes get incorporated into the global hash that is
shared by everyone. </p><p>
So when Ann sees a mismatch between messages Bob sent, and
messages Ann received, asks Bob to fix the mismatch. </p><p>
To the extent that Ann’s record of messages sent, agrees with
Bob’s record of messages received for messages sent some
time ago, we have non repudiation and guarantee of delivery.
</p><p>
If ten thousand members, then two hundred million hashes
every time period, but we special case the hash of no messages
sent or received between Ann and Bob in a given time period,
so that it does not take up any significant space in the tree
or computational resources. It is a virtual hash, not a real
hash. </p><p>
Everyone stores the current hash for each pair, which,
if no messages have been sent in the last few time
periods, is the same as the hash from some time ago, and if no
messages have ever been sent, is represented by the null hash.
Conceptually we have a lot of nulls, but these are efficiently
represented, as a sparse matrix, so that we don’t waste
storage or communication managing huge numbers of mostly null
entries. </p><p>
In addition to the encrypted pairwise messages, we also have
messages to the public, signed but not encrypted. This
enables one to find the characteristics of the owner of the
key, usually used to look for a key owner with certain
characteristics. The primary function of this is to ensure
that everyone sees the same key for the entity called Bob as
Bob does, since the hash of all public messages by Bob go into
the global hash, and everyone sees the same global hash.
</p><p>
All of this would be simple if the hashes were static, if we
were managing an immutable data structure, but we are of
course managing a mutable data structure with an immutable
past. Each hash continually changes. </p><p>
An ever changing hash is represented by a time tree of hashes.
</p><p>
We have a hash for the period 0 milliseconds to 2^64-1 milliseconds,
which is itself a hash of the two hashes, one for the period 0
seconds to 2^63-1 milliseconds, and the other for the period 2^63
seconds to 2^64-1 milliseconds. </p><p>
And the hash for the period the period 2^63 seconds to 2^64-1
seconds is itself a hash of the two hashes, one for the period
2^63 seconds to 3*2^62-1 seconds, and one for the period
3*2^62 seconds to 2^64-1 seconds. </p><p>
And so on and so forth. Hashes for the past are immutable,
and signed. Hashes for periods that incorporate the future
are also signed, but are listed as provisional and only
covering data up to such and such a time. They are useful
because they incoporate hashes of times that are strictly in
the past. </p><p>
To bind the entire past, one needs the signed mutable hash for
the smallest period including all of the past, plus the hashes
nearest the root that cover all of the past. </p><p>
Thus the hash for the entire past is typically only larger
than the hash for a single time period by a factor of log base
two of the current time. </p><p>
The signature on the mutable hash acts as a signature on all
past immutable hashes. </p><p>
The hash for a single time period is an ordinary hash, like
SHA2. The hash for the entire time period is a small number
of such hashes forming a tree, and ending in a signature of
the root of the tree. </p><p>
Any data that anyone supplies then has to have a path leading
from its local all time hash to this global all time hash.
</p><p>
If 256 bit single time hashes, an all time hash is about one
kilobyte, but updates are only thirty two bytes or so. So our
global data structure is quite large, but updates quite
slowly. If ten thousand members, our global data structure is
about a hundred gigabytes, assuming every entity interacted
with every other. If every member interacted with every other
member in a given time period, the update would be three
gigabyes, which would be intolerable. Interacting with a
single member requires ten thousand thirty two byte
notifications, which is tolable, but starting to get
expensive. </p><p>
To remedy the problem, members for groups, and groups of
groups and groups of groups of groups. So you don’t track the
hashes for every interaction between every member, but rather
most such interactions get aggregated into the interaction
between group and group. </p><p>
Of course, having secure non repudiable messaging with proof
of delivery is only a foundation for a financial system.
Swift builds a financial system on top of that by making sure
that all entities are very highly rated. </p><p>
Ripple, however, addresses a system where some entities are
rated to some people and not others, where not everyone has
good ratings, and opinions about ratings differ, where perhaps
some entities are well placed to ensure payment of what is
owed, and others less well placed. </p>
<p style="background-color : #ccffcc;
font-size:80%">These documents are licensed under the <a
rel="license"
href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

163
docs/the_login_problem.html Normal file
View File

@ -0,0 +1,163 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;
}
dl {counter-reset: item1;
margin-left: 1.5em;
padding-left: 0;
margin-top: 0pt;
margin-bottom: 0pt;
padding-top: 0pt;
padding-bottom: 0pt;
top: 0pt;
bottom: 0pt;
}
dt {
margin-top: 6pt;
}
dt:before {
counter-increment: item1;
content: counter(item1) ". ";
}
a:hover {
color: #FF0000;
}
</style><title>The login problem</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>The login problem</h1><p>
Increasingly applications and activities are networked,
though our operating systems are still oriented to a
single computer.</p><p>
Linux makes a start on fixing this, since one can
routinely open a window on one computer managed by a
program running on another computer, and all operating
systems allow the user to have access to files on the
network.</p><p>
This of course means that the user has
lots and lots of logins, which are usually made possible
by durable secrets. &nbsp;Durable secrets are a big
problem, and durable shared secrets a bigger problem, so
it is unsurprising we have crises such as phishing.</p><p> For machines logging into machines, this problem is,
if not solved, substantially under control with public and
private keys, unshared secrets which are used to generate
transient shared secrets.</p><p>
With humans, however, we have a big problem, for
human secrets are small enough to come under dictionary
attack and are commonly shared secrets, so can be
phished.</p><p>
Password-authenticated key agreement solves phishing – both sides
authenticate to the other, and attempting to login to an
impostor leaks no information to the impostor, but, of
course, still vulnerable to online dictionary attack.</p><p>
To prevent user enumeration, the login process should
never reveal that there is no such user, merely that if
there is such a user, that is the wrong password.</p><p>
To prevent online dictionary attack, server should use
reverse Turing test.&nbsp; To avoid inflicting a reverse
Turing test every time, a successful login should store a
transient unprotected&nbsp;secret or weakly protected
secret on the computer that successfully logs in.&nbsp;
Possession of this secret excuses a person logging in from
the reverse Turing test – but every time he makes an
unsuccessful login, there is a finite probability, perhaps
one in six, that the server will forget that secret.</p><p>
This solves the phishing attack, and the online
dictionary attack, but we still have the problem that
humans have too @#$% many logins, and thus too
@#$% many secrets.</p><p>
The obvious solution to this problem is single sign
on, but various attempts to introduce single sign on,
often backed by big money, big marketing, or widespread
consensus, have failed, even though there is obvious and
pressing need for a single sign on solution.</p><p>
There are at present three solutions for single sign on,
none of them having great success:</p>
<dl>
<dt>Cardspace</dt>
<dd>Microsoft’s solution: Change the server, the client,
and the end user’s behavior to use an ID card metaphor.
The ID card is the user interface representation of
cryptographic credentials supplied by a server.</dd>
<dt>OpenID</dt>
<dd>Consensus solution: Change the server, but not the
client. Change user’s behavior merely by using a url as a
name. Oversimplifying drastically: The server bounces the
client to the URL with an argument saying “log me in
to the original server”. The identity server sends
the client back to the original server with a validated id
as an argument.
</dd><dt>Passpet</dt>
<dd>Heroic solution: Changes client to provide single
server based login, but fools server into thinking this is
an ordinary human user based login. Requires some thought
and learning by the end user.</dd>
</dl>
<p>None of these solutions fix a major weakness in the
present identity system – the lack of push. If you
have a login relationship with a site, there is in
general no way that site can send you validated
messages, messages that you <em>know</em> came from the
site with which you have the relationship </p><p>
To fix this problem, a single sign on solution must
support a user interface akin to the instant messaging
interface</p><p>We need a client side signon/login tool, which also
enables the client to receive messages from entities with
which the client has a login relationship, analogous to
the buddy list in IM, and, like the buddy list in IM, only
from those entities.</p><p>The interface of the signon tool should resemble an IM
interface, and also resemble the interface for a browser’s
favorites list. However clicking on a "buddy", instead of
opening a chat window with the buddy, brings you to the
web page like a "favorite", but you are logged on, unlike
a "favorite". Clicking on a message, instead of opening a
chat window, brings you logged on to a web page belonging
to that "buddy", but a web page selected by the message
author (a web page that normally contains the body of the
message), instead of the web page corresponding to that
"favorite".</p><p>In the present incarnation of the tool, the three
parties to an interaction are the single sign on server
(SSS), the client, and the relying party. The relying
party is the web site the client wants to log in to, for
example a bank or a blog.</p><p>As with an instant messaging system, user has to
register and logon to a single signon server. Any server
will do. So we then face the problem of making the signon
server invulnerable to phishing: One solution to that
problem is password-authenticated key agreement, and another other is to have a short list
of public keys of permitted single signon servers, a list
that the user can add to, but which is not easy to
mindlessly do a one click add.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

145
docs/tim_may_on_bitcoin.html Normal file
View File

@ -0,0 +1,145 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Enough with the ICO-Me-So-Horny-Get-Rich-Quick-Lambo Crypto</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Enough with the ICO-Me-So-Horny-Get-Rich-Quick-Lambo Crypto</h1>
<p><em>CoinDesk asked cypherpunk legend Timothy May, author of the &#8220;<strong><a href="https://www.activism.net/cypherpunk/crypto-anarchy.html" data-wpel-link="external" target="_blank" rel="external noopener noreferrer">Crypto Anarchist Manifesto</a>,</strong>&#8221; to write his thoughts on the bitcoin white paper on its 10th anniversary. What he sent back was a sprawling 30-page evisceration of a technology industry he feels is untethered from reality.</em></p>
<p><em>The original message is presented here as a fictional Q&amp;A for clarity. The message remains otherwise unchanged. Read more in our <strong><a href="/category/bitcoin-white-paper-reviewed/" data-wpel-link="internal">White Paper Reflections</a></strong> series.</em></p>
<hr />
<p><strong>CoinDesk: Now that bitcoin has entered the history books, how do you feel the white paper fits in the pantheon of financial cryptography advances?</strong></p>
<p><strong>Tim: </strong>First, I&#8217;ll say I&#8217;ve been following, with some interest, some amusement and a lot of frustration for the past 10 years, the public situation with bitcoin and all of the related variants.</p>
<p>In the pantheon, it deserves a front-rank place, perhaps the most important development since the invention of double-entry book-keeping.</p>
<p>I can&#8217;t speak for what Satoshi intended, but I sure don&#8217;t think it involved bitcoin exchanges that have draconian rules about KYC, AML, passports, freezes on accounts and laws about reporting &#8220;suspicious activity&#8221; to the local secret police. There&#8217;s a real possibility that all the noise about &#8220;governance,&#8221; &#8220;regulation&#8221; and &#8220;blockchain&#8221; will effectively create a surveillance state, a dossier society.</p>
<p>I think Satoshi would barf. Or at least work on a replacement for bitcoin as he first described it in 2008-2009. I cannot give a ringing endorsement to where we are, or generate a puff-piece about the great things already done.</p>
<p>Sure, bitcoin and its variants – a couple of forks and many altcoin variants – more or less work the way it was originally intended. Bitcoin can be bought or mined, can be sent in various fast ways, small fees paid and recipients get bitcoin and it can be sold in tens of minutes, sometimes even faster.</p>
<p>No permission is needed for this, no centralized agents, not even any trust amongst the parties. And bitcoin can be acquired and then saved for many years.</p>
<p>But this tsunami that swept the financial world has also left a lot of confusion and carnage behind. Detritus of the knowledge-quake, failed experiments, Schumpeter&#8217;s &#8220;creative destructionism.&#8221; It&#8217;s not really ready for primetime. Would anyone expect their mother to &#8220;download the latest client from Github, compile on one of these platforms, use the Terminal to reset these parameters?&#8221;</p>
<p>What I see is losses of hundred of millions in some programming screw-ups, thefts, frauds, initial coin offerings (ICOs) based on flaky ideas, flaky programming and too few talented people to pull off ambitious plans.</p>
<p>Sorry if this ruins the narrative, but I think the narrative is fucked. Satoshi did a brilliant thing, but the story is far from over. She/he/it even acknowledged this, that the bitcoin version in 2008 was not some final answer received from the gods..</p>
<p><strong>CoinDesk: Do you think others in the cypherpunk community share your views? What do you think is creating interest in the industry, or killing it off?<br />
</strong></p>
<p><strong>Tim: </strong>Frankly, the newness in the Satoshi white paper (and then the early uses for things like Silk Road) is what drew many to the bitcoin world. If the project had been about a &#8220;regulatory-compliant,&#8221; &#8220;banking-friendly&#8221; thing, then interest would&#8217;ve been small. (In fact, there were some yawn-inducing electronic transfer projects going back a long time. &#8220;SET,&#8221; for Secure Electronic Transfer, was one such mind-numbingly-boring projects.)</p>
<p>It had no interesting innovations and was 99 percent legalese. Cypherpunks ignored it.</p>
<p>It&#8217;s true that some of us were there when things in the &#8220;financial cryptography&#8221; arena really started to get rolling. Except for some of the work by David Chaum, Stu Haber, Scott Stornetta, and a few others, most academic cryptographers were mainly focused on the mathematics of cryptology: their gaze had not turned much toward the &#8220;financial&#8221; aspects.</p>
<p>This has of course changed in the past decade. Tens of thousands of people, at least, have flocked into bitcoin, blockchain, with major conferences nearly every week. Probably most people are interested in the &#8220;Bitcoin Era,&#8221; starting roughly around 2008-2010, but with some important history leading up to it.</p>
<p>History is a natural way people understand things… it tells a story, a linear narrative.</p>
<p>About the future I won&#8217;t speculate much. I was vocal about some &#8220;obvious&#8221; consequences from 1988 to 1998, starting with &#8220;The Crypto Anarchist Manifesto&#8221; in 1988 and the Cypherpunks group and list starting in 1992.</p>
<p><strong>CoinDesk: It sounds like you don&#8217;t think that bitcoin is particularly living up to its ethos, or that the community around it hasn&#8217;t really stuck to its cypherpunk roots.</strong></p>
<p><strong>Tim: </strong>Yes, I think the greed and hype and nattering about &#8220;to the Moon!&#8221; and &#8220;HODL&#8221; is the biggest hype wagon I&#8217;ve ever seen.</p>
<p>Not so much in the &#8220;Dutch Tulip&#8221; sense of enormous price increases, but in the sense of hundred of companies, thousands of participants, and the breathless reporting. And the hero worship. This is much more hype than we saw during the dot-com era. I think far too much publicity is being given to talks at conferences, white papers and press releases. A whole lot of &#8220;selling&#8221; is going on.</p>
<p>People and companies are trying to stake-out claims. Some are even filing for dozens or hundreds of patents in fairly-obvious variants of the basic ideas, even for topics that were extensively-discussed in the 1990s. Let&#8217;s hope the patent system dismisses some of these (though probably only when the juggernauts enter the legal fray).</p>
<p>The tension between privacy (or anonymity) and &#8220;know your customer&#8221; approaches is a core issue. It&#8217;s &#8220;decentralized, anarchic and peer-to-peer&#8221; versus &#8220;centralized, permissioned and back door.&#8221; Understand that the vision of many in the privacy community — cypherpunks, Satoshi, other pioneers — was explicitly of a permission-less, peer-to-peer system for money transfers. Some had visions of a replacement for &#8220;fiat&#8221; currency.</p>
<p>David Chaum, a principal pioneer, was very forward-thinking on issues of &#8220;buyer anonymity.&#8221; Where, for example, a large store could receive payments for goods without knowing the identity of a buyer. (Which is most definitely not the case today, where stores like Walmart and Costco and everybody else compiled detailed records on what customers buy. And where police investigators can buy the records or access them via subpoenas. And in more nefarious ways in some countries.)</p>
<p>Remember, there are many reasons a buyer does not wish to disclose buying preferences. But buyers and sellers BOTH need protections against tracking: a seller of birth control information is probably even more at risk than some mere buyer of such information (in many countries). Then there&#8217;s blasphemy, sacrilege and political activism. Approaches like Digicash which concentrated on *buyer* anonymity (as with shoppers at a store or drivers on a toll-road), but were missing a key ingredient: that most people are hunted-down for their speech or their politics on the *seller* side.</p>
<p>Fortunately, buyers and sellers are essentially isomorphic, just with some changes in a few arrow directions (&#8220;first-class objects&#8221;).</p>
<p>What Satoshi did essentially was to solve the &#8220;buyer&#8221;/&#8221;seller&#8221; track-ability tension by providing both buyer AND seller untraceability. Not perfectly, it appears. Which is why so much activity continues.</p>
<p><strong>CoinDesk: So, you&#8217;re saying bitcoin and crypto innovators need to fight the powers that be, essentially, not align with them to achieve true innovation?</strong></p>
<p><strong>Tim: </strong>Yes, there is not much of interest to many of us if cryptocurrencies just become Yet Another PayPal, just another bank transfer system. What&#8217;s exciting is the bypassing of gatekeepers, of exorbitant fee collectors, of middlemen who decide whether Wikileaks — to pick a timely example — can have donations reach it. And to allow people to send money abroad.</p>
<p>Attempts to be &#8220;regulatory-friendly&#8221; will likely kill the main uses for cryptocurrencies, which are NOT just &#8220;another form of PayPal or Visa.&#8221;</p>
<p>More general uses of &#8220;blockchain&#8221; technology are another kettle of fish. Many uses may be compliance-friendly. Of course, a lot of the proposed uses — like putting supply chain records — on various public or private blockchains are not very interesting. Many point that these &#8220;distributed ledgers&#8221; are not even new inventions, just variants of databases with backups. As well, the idea that corporations want public visibility into contracts, materials purchases, shipping dates, and so on, is naive.</p>
<p>Remember, the excitement about bitcoin was mostly about bypassing controls, to enable exotic new uses like Silk Road. It was some cool and edgy stuff, not just another PayPal.</p>
<p><strong>CoinDesk: So, you&#8217;re saying that we should think outside the box, try to think about ways to apply the technology in novel ways, not just remake what we know?</strong></p>
<p><strong>Tim: </strong>People should do what interests them. This was how most of the innovative stuff like BitTorrent, mix-nets, bitcoin, etc. happened. So, I&#8217;m not sure that &#8220;try to think about ways&#8221; is the best way to put it. My hunch is that ideologically-driven people will do what is interesting. Corporate people will probably not do well in &#8220;thinking about ways.&#8221;</p>
<p>Money is speech. Checks, IOUs, delivery contracts, Hawallah banks, all are used as forms of money. Nick Szabo has pointed out that bitcoin and some other cryptocurrencies have most if not all of the features of gold except it also has more features: it weighs nothing, it&#8217;s difficult to steal or seize and it can be sent over the crudest of wires. And in minutes, not on long cargo flights as when gold bars are moved from place to another.</p>
<p>But, nothing is sacred about either banknotes, coins or even official-looking checks. These are &#8220;centralized&#8221; systems dependent on &#8220;trusted third parties&#8221; like banks or nation-states to make some legal or royal guaranty.</p>
<p>Sending bitcoin, in contrast, is equivalent to &#8220;saying&#8221; a number (math is more complicated than this, but this is the general idea). To ban saying a number is equivalent to a ban on some speech. That doesn&#8217;t mean the tech can&#8217;t be stopped. There was the &#8220;printing out PGP code,&#8221; or the Cody Wilson, Defense Distributed case, where a circuit court ruled this way,</p>
<p>Printed words are very seldom outside the scope of the First Amendment.</p>
<p><strong>CoinDesk: Isn&#8217;t this a good example of where you, arguably, want some censorship (the ability to force laws), if we&#8217;re going to rebuild the whole economy, or even partial economies, on top of this stuff?</strong></p>
<p><strong>Tim: </strong>There will inevitably be some contact with the legal systems of the U.S., or the rest of the world. Slogans like &#8220;the code is the law&#8221; are mainly aspirational, not actually true.</p>
<p>Bitcoin, qua bitcoin, is mostly independent of law. Payments are, by the nature of bitcoin, independent of charge-backs, &#8220;I want to cancel that transaction,&#8221; and other legal issues. This may change. But in the current scheme, it&#8217;s generally not know who the parties are, which jurisdictions the parties live in, even which laws apply.</p>
<p>This said, I think nearly all new technologies have had uses some would not like. Gutenberg&#8217;s printing press was certainly not liked by the Catholic Church. Examples abound. But does this mean printing presses should be licensed or regulated?</p>
<p>There have usually been some unsavory or worse uses of new technologies (what&#8217;s unsavory to, say, the U.S.S.R. may not be unsavory to Americans). Birth control information was banned in Ireland, Saudi Arabia, etc. Examples abound: weapons, fire, printing press, telephones, copier machines, computers, tape recorders.</p>
<p><strong>CoinDesk: Is there a blockchain or cryptocurrency that&#8217;s doing it right? Is bitcoin, in your opinion, getting its own vision right?</strong></p>
<p><strong>Tim: </strong>As I said, bitcoin is basically doing what it was planned to do. Money can be transferred, saved (as bitcoin), even used as a speculative vehicle. The same cannot be said for dozens of major variants and hundreds of minor variants where a clear-cut, understandable &#8220;use case&#8221; is difficult to find.</p>
<p>Talk of &#8220;reputation tokens,&#8221; &#8220;attention tokens,&#8221; &#8220;charitable giving tokens,&#8221; these all seem way premature to me. And none have taken off the way bitcoin did. Even ethereum, a majorly different approach, has yet to see interest uses (at least that I have seen, and I admit I don&#8217;t the time or will to spend hours every day following the Reddit and Twitter comments.)</p>
<p>&#8220;Blockchain,&#8221; now its own rapidly-developing industry, is proceeding on several paths: private blockchains, bank-controlled blockchains, pubic blockchains, even using the bitcoin blockchain itself. Some uses may turn out to be useful, but some appear to be speculative, toy-like. Really, marriage proposals on the blockchain?</p>
<p>The sheer number of small companies, large consortiums, alternative cryptocurrencies, initial coin offerings (ICOs), conferences, expos, forks, new protocols, is causing great confusion and yet there are new conferences nearly every week.</p>
<p>People jetting from Tokyo to Kiev to Cancun for the latest 3-5 days rolling party. The smallest only attract hundreds of fanboys, the largest apparently have drawn crowds of 8,000. You can contrast that with the straightforward roll-out of credit cards, or even the relatively clean roll-out of bitcoin. People cannot spend mental energy reading technical papers, following the weekly announcements, the contentious debates. The mental transaction costs are too high, for too little.</p>
<p>The people I hear about who are reportedly transferring &#8220;interesting&#8221; amounts of money are using basic forms of bitcoin or bitcoin cash, not exotics new things like Lightning, Avalanche, or the 30 to 100 other things.</p>
<p><strong>CoinDesk: It sounds like you&#8217;re optimistic about the value transfer use case for cryptocurrencies, at least then.</strong></p>
<p><strong>Tim: </strong>Well, it will be a tragic error if the race to develop (and profit from) the things that are confusingly called &#8220;cryptocurrencies&#8221; end up developing dossiers or surveillance societies such as the world has never seen. I&#8217;m just saying there&#8217;s a danger.</p>
<p>With &#8220;know your customer&#8221; regulations, crypto monetary transfers won&#8217;t be like what we have now with ordinary cash transactions, or even with wire transfers, checks, etc. Things will be _worse_ than what we have now if a system of &#8220;is-a-person&#8221; credentialing and &#8220;know your customer&#8221; governance is ever established. Some countries already want this to happen.</p>
<p>The &#8220;Internet driver&#8217;s license&#8221; is something we need to fight against.</p>
<p><strong>CoinDesk: That&#8217;s possible, but you could make a similar claim about the internet today isn&#8217;t exactly the same as the original idea, yet it&#8217;s still be useful in driving human progress.</strong></p>
<p><strong>Tim: </strong>I&#8217;m just saying we could end up with a regulation of money and transfers that is much the same as regulating speech. Is this a reach? If Alice can be forbidden from saying &#8220;I will gladly pay you a dollar next week for a cheeseburger today,&#8221; is this not a speech restriction? &#8220;Know your customer&#8221; could just as easily be applied to books and publishing: &#8220;Know your reader.&#8221; Gaaack!</p>
<p>I&#8217;m saying there are two paths: freedom vs. permissioned and centralized systems.</p>
<p>This fork in the road in the road was widely discussed some 25 years ago. Government and law enforcement types didn&#8217;t even really disagree: they saw the fork approaching. Today, we have tracking, the wide use of scanners (at elevators, chokepoints), tools for encryption, cash, privacy, tools for tracking, scanning, forced decryption, backdoors, escrow.</p>
<p>In a age where a person&#8217;s smartphone or computer may carry gigabytes of photos, correspondence, business information – much more than an entire house carried back when the Bill of Rights was written – the casual interception of phones and computers is worrisome. A lot of countries are even worse than the U.S. New tools to secure data are needed, and lawmakers need to be educated.</p>
<p>Corporations are showing signs of corporatizing the blockchain: there are several large consortiums, even cartels who want &#8220;regulatory compliance.&#8221;</p>
<p>It is tempting for some to think that legal protections and judicial supervision will stop excesses… at least in the US and some other countries. Yet, we know that even the US has engaged in draconian behavior (purges of Mormons, killings and death marches for Native Americans, lynchings, illegal imprisonment of those of suspected Japanese ancestry).</p>
<p>What will China and Iran do with the powerful &#8220;know your writers&#8221; (to extend &#8220;know your customer&#8221; in the inevitable way)?</p>
<p><strong>CoinDesk: Are we even talking about technology anymore though? Isn&#8217;t this just power and the balance of power. Isn&#8217;t there good that has come from the internet even if it&#8217;s become more centralized?</strong></p>
<p><strong>Tim: </strong>Of course, there&#8217;s been much good coming out of the Internet tsunami.</p>
<p>But, China already uses massive databases – with the aid of search engine companies – to compile &#8220;citizen trustworthiness&#8221; ratings that can be used to deny access to banking, hotels, travel. Social media corporate giants are eagerly moving to help build the machinery of the Dossier Society (they claim otherwise, but their actions speak for themselves).</p>
<p>Not to sound like a Leftist ranting about Big Brother, but any civil libertarian or actual libertarian has reason to be afraid. In fact, many authors decades ago predicted this dossier society, and the tools have jumped in quantum leaps since then</p>
<p>In thermodynamics, and in mechanical systems, with moving parts, there are &#8220;degrees of freedom.&#8221; A piston can move up or down, a rotor can turn, etc. I believe social systems and economies can be characterized in similar ways. Some things increase degrees of freedom, some things &#8220;lock it down.&#8221;</p>
<p><strong>CoinDesk: Have you thought about writing something definitive on the current crypto times, sort of a new spin on your old works?</strong></p>
<p><strong>Tim: </strong>No, not really. I spent a lot of time in the 1992-95 period writing for many hours a day. I don&#8217;t have it in me to do this again. That a real book did not come out of this is mildly regrettable, but I&#8217;m stoical about it.</p>
<p><strong>CoinDesk: Let&#8217;s step back and look at your history. Knowing what you know about the early cypherpunk days, do you see any analogies to what&#8217;s happening in crypto now?</strong></p>
<p><strong>Tim: </strong>About 30 years ago, I got interested in the implications of strong cryptography. Not so much about the &#8220;sending secret messages&#8221; part, but the implications for money, bypassing borders, letting people transact without government control, voluntary associations.</p>
<p>I came to call it &#8220;crypto anarchy&#8221; and in 1988 I wrote &#8220;The Crypto Anarchist Manifesto,&#8221; loosely-based in form on another famous manifesto. And based on &#8220;anarcho-capitalism,&#8221; a well-known variant of anarchism. (Nothing to do with Russian anarchists or syndicalists, just free trade and voluntary transactions.)</p>
<p>At the time, there was one main conference – Crypto – and two less-popular conferences – EuroCrypt and AsiaCrypt. The academic conferences had few if any papers on any links to economics and institutions (politics, if you will). Some game theory-related papers were very important, like the mind-blowing &#8220;Zero Knowledge Interactive Proof Systems&#8221; work of Micali, Goldwasser and Rackoff.</p>
<p>I explored the ideas for several years. In my retirement from Intel in 1986 (thank you, 100-fold increase in the stock price!), I spent many hours a day reading crypto papers, thinking about new structures that were about to become possible.</p>
<p>Things like data havens in cyberspace, new financial institutions, timed-release crypto, digital dead drops through steganography, and, of course, digital money.</p>
<p>Around that time, I met Eric Hughes and he visited my place near Santa Cruz. We hatched a plan to call together some of the brightest people we knew to talk about this stuff. We met in his newly-rented house in the Oakland Hills in the late summer of 1992.</p>
<p><strong>CoinDesk: You mentioned implications for money&#8230; Were there any inclinations then that something like bitcoin or cryptocurrency would come along?</strong></p>
<p><strong>Tim: </strong>Ironically, at that first meeting, I passed out some Monopoly money I bought at a toy store. (I say ironically because years later, when bitcoin was first being exchanged in around 2009-2011 it looked like play money to most people – cue the pizza story!)</p>
<p>I apportioned it out and we used it to simulate what a world of strong crypto, with data havens and black markets and remailers (Chaum&#8217;s &#8220;mixes&#8221;) might look like. Systems like what later became &#8220;Silk Road&#8221; were a hoot. (More than one journalist has asked me why I did not widely-distribute my &#8220;BlackNet&#8221; proof of concept. My answer is generally &#8220;Because I didn&#8217;t want to be arrested and imprisoned.&#8221; Proposing ideas and writing is protected speech, at least in the U.S. at present.)</p>
<p>We started to meet monthly, if not more often at times, and a mailing list rapidly formed. John Gilmore and Hugh Daniel hosted the mailing list. There was no moderation, no screening, no &#8220;censorship&#8221; (in the loose sense, not referring to government censorship, of which of course there was none.) The &#8220;no moderation&#8221; policy went along with &#8220;no leaders.&#8221;</p>
<p>While a handful of maybe 20 people wrote 80 percent of the essays and messages, there was no real structure. (We also thought this would provide better protection against government prosecution).</p>
<p>And of course this fits with a polycentric, distributed, permission-less, peer to peer structure. A form of anarchy, in the &#8220;an arch,&#8221; or &#8220;no top&#8221; true meaning of the word anarchy. This had been previously explored by David Friedman, in his influential mid-70s book &#8220;The Machinery of Freedom.&#8221; And by Bruce Benson, in &#8220;The Enterprise of Law.</p>
<p>He studied the role of legal systems absent some ruling top authority. And of course anarchy is the default and preferred mode of most people—to choose what they eat, who they associate with, what the read and watch. And whenever some government or tyrant tries to restrict their choices they often finds way to route around the restrictions: birth control, underground literature, illegal radio reception, copied cassette tapes, thumb drives ….</p>
<p>This probably influenced the form of bitcoin that Satoshi Nakamoto later formulated.</p>
<p><strong>CoinDesk: What was your first reaction to Satoshi&#8217;s messages, do you remember how you felt about the ideas?</strong></p>
<p><strong>Tim: </strong>I was actually doing some other things and wasn&#8217;t following the debates. My friend Nick Szabo mentioned some of the topics in around 2006-2008. And like a lot of people I think my reaction to hearing about the Satoshi white paper and then the earliest &#8220;toy&#8221; transactions was only mild interest. It just didn&#8217;t seem likely to become as big as it did.</p>
<p>He/she/they debated aspects of how a digital currency might work, what it needed to make it interesting. Then, in 2008, Satoshi Nakamoto released &#8220;their&#8221; white paper. A lot of debate ensued, but also a lot of skepticism.</p>
<p>In early 2009 an alpha release of &#8220;bitcoin&#8221; appeared. Hal Finney had the first bitcoin transaction with Satoshi. A few others. Satoshi himself (themselves?) even said that bitcoin would likely either go to zero in value or to a &#8220;lot.&#8221; I think many were either not following it or expected it would go to zero, just another bit of wreckage on the Information Superhighway.</p>
<p>The infamous pizza purchase shows that most thought of it as basically toy money.</p>
<p><strong>CoinDesk: Do you still think it&#8217;s toy money? Or has the slowly increasing value sort of put that argument to rest, in your mind?</strong></p>
<p><strong>Tim: </strong>No, it&#8217;s no longer just toy money. Hasn&#8217;t been for the past several years. But it&#8217;s also not yet a replacement for money, for folding money. For bank transfers, for Hawallah banks, sure. It&#8217;s functioning as a money transfer system, and for black markets and the like.]</p>
<p>I&#8217;ve never seen such hype, such mania. Not even during the dot.com bubble, the era of Pets.com and people talking about how much money they made by buying stocks in &#8220;JDS Uniphase.&#8221; (After the bubble burst, the joke around Silicon Valley was &#8220;What&#8217;s this new start-up called &#8220;Space Available&#8221;?&#8221; Empty buildings all around.)</p>
<p>I still think cryptocurrency is too complicated…coins, forks, sharding, off-chain networks, DAGs, proof-of-work vs. proof-of-stake, the average person cannot plausibly follow all of this. What use cases, really? There&#8217;s talk about the eventual replacement of the banking system, or credit cards, PayPal, etc. is nice, but what does it do NOW?</p>
<p>The most compelling cases I hear about are when someone transfers money to a party that has been blocked by PayPal, Visa (etc), or banks and wire transfers. The rest is hype, evangelizing, HODL, get-rich lambo garbage.</p>
<p><strong>CoinDesk: So, you see that as bad. You don&#8217;t buy the argument that that&#8217;s how things get built though, over time, somewhat sloppily…</strong></p>
<p><strong>Tim: </strong>Things sometimes get built in sloppy ways. Planes crash, dams fail, engineers learn. But there are many glaring flaws in the whole ecology. Programming errors, conceptual errors, poor security methods. Hundreds of millions of dollars have been lost, stolen, locked in time-vault errors.</p>
<p>If banks were to lose this kind of my money in &#8220;Oops. My bad!&#8221; situations there&#8217;d be bloody screams. When safes were broken into, the manufacturers studied the faults — what we now call &#8220;the attack surface&#8221; — and changes were made. It&#8217;s not just that customers — the banks — were encouraged to upgrade, it&#8217;s that their insurance rates were lower with newer safes. We desperately need something like this with cryptocurrencies and exchanges.</p>
<p>Universities can&#8217;t train even basic &#8220;cryptocurrency engineers&#8221; fast enough, let alone researchers. Cryptocurrency requires a lot of unusual areas: game theory, probability theory, finance, programming.</p>
<p>Any child understands what a coin like a quarter &#8220;does,&#8221; He sees others using quarters and dollar bills and the way it works is clear.</p>
<p>When I got my first credit card I did not spend a lot of time reading manuals, let alone downloading wallets, cold storage tools or keeping myself current on the protocols. &#8220;It just worked, and money didn&#8217;t just vanish.</p>
<p><strong>CoinDesk: It sounds like you don&#8217;t like how innovation and speculation have become intertwined in the industry…</strong></p>
<p><strong>Tim: </strong>Innovation is fine. I saw a lot of it in the chip industry. But we didn&#8217;t have conferences EVERY WEEK! And we didn&#8217;t announce new products that had only the sketchiest ideas about. And we didn&#8217;t form new companies with such abandon. And we didn&#8217;t fund by &#8220;floating an ICO&#8221; and raising $100 million from what are, bluntly put, naive speculators who hope to catch the next bitcoin.</p>
<p>Amongst my friends, some of whom work at cryptocurrency companies and exchanges, the main interest seems to be in the speculative stuff. Which is why they often keep their cryptocurrency at the exchanges: for rapid trading, shorting, hedging, but NOT for buying stuff or transferring assets outside of the normal channels.</p>
<p><strong>CoinDesk: Yet, you seem pretty knowledgeable on the whole about the subject area&#8230; Sounds like you might have a specific idea of what it &#8220;should&#8221; be.</strong></p>
<p><strong>Tim: </strong>I probably spend way too much time following the Reddit and Twitter threads (I don&#8217;t have an actual Twitter account).</p>
<p>What &#8220;should&#8221; it be? As the saying goes, the street will find its own uses for technology. For a while, Silk Road and its variants drove wide use. Recently, it&#8217;s been HODLing, aka speculating. I hear that online gambling is one of the main uses of ethereum. Let the fools blow their money.</p>
<p>Is the fluff and hype worth it? Will cryptocurrency change the world? Probably. The future is no doubt online, electronic, paperless.</p>
<p>But bottom line, there&#8217;s way too much hype, way too much publicity and not very many people who understand the ideas. It&#8217;s almost as if people realize there&#8217;s a whole world out there and thousands start building boats in their backyards.</p>
<p>Some will make, but most will either stop building their boats or will sink at sea.</p>
<p>We were once big on manifestos, These were ways not of enforcing compliance, but of suggesting ways to proceed. A bit like advising a cat… one does not command a cat, one merely suggests ideas, which sometimes they go with.</p>
<p><strong>Final Thoughts:</strong></p>
<ul>
<li>Don&#8217;t use something just because it sounds cool…only use it if actually solves some problem (To date, cryptocurrency solves problems for few people, at least in the First World).</li>
<li>Most things we think of as problems are not solvable with crypto or any other such technology (crap like &#8220;better donation systems&#8221; are not something most people are interested in).</li>
<li>If one is involved in dangerous transactions – drugs, birth control information – practice intensive &#8220;operational security&#8221;….look at how Ross Ulbricht was caught.</li>
<li>Mathematics is not the law</li>
<li>Crypto remains very far from being usable by average people (even technical people)</li>
<li>Be interested in liberty and the freedom to transact and speak to get back to the original motivations. Don&#8217;t spend time trying to make government-friendly financial alternatives.</li>
<li>Remember, there are a lot tyrants out there.</li>
</ul>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

76
docs/true_names_and_TCP.html Normal file
View File

@ -0,0 +1,76 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>
True Names and TCP
</title>
</head><body>
<h1>True Names and TCP
</h1><p>
Vernor Vinge <a
href="http://www.amazon.com/True-Names-Opening-Cyberspace-Frontier/dp/0312862075">made
the point</a> 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. </p><p>
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 <em>are</em> 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. </p><p>
TCP is all about creating connections.  It creates connections between network addresses, but network adresses correspond to the way networks are organized, not the way people are organized, so on top of networks we have domain names.  </p><p>
TCP therefore establishes a connection <em>to</em> a domain name rather than a mere network address – but there is no concept of the connection coming <em>from</em> anywhere humanly meaningfull. </p><p>
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. </p><p>
There are several big problems with urls: </p><ol><li><p>
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, becaŭse in truth there is no one real jim, and there is fraŭd, as in lots of people pretending to be Paypal or the Bank of America, in order to steal your money.</p></li><li><p>
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 becaŭse 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. </p><p>
Becaŭse security (ssl, https) is constructed below the level of a connection, becaŭse 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. </li></ol><p>
That domain names and hence urls presuppose agreement, agreement which can never exist, we get cybersquatting and phishing and suchlike. </p><p>
That connections and logons exist, but are not explicitly addressed by the protocol leads to such attacks as cross site scripting and session fixation. </p><p>
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. </p><p>
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.  </p><p>
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. </p><p>
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”? </p><p>
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: </p><p>
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 to 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. </p><p>
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.</p><p>
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 managemnet 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. </p><p>
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.
</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

32
docs/trust_and_privacy_on_the_blockchain.html Normal file
View File

@ -0,0 +1,32 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Trust and Privacy on the blockchain</title> </head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Trust and Privacy on the blockchain</h1><p>
Bob, who has a tax file number, buys crypto currency under his government registered identity, from a government registered and regulated corporation, as if buying shares.&nbsp; This generates a record, accessible to the state, that his wallet controls a bunch of public keys, which control transaction outputs representing ones, twos, fives, tens, hundreds, two hundreds, five hundreds, and so forth.&nbsp; </p><p>
Subsequently Bob wants to pay Edward.&nbsp; His wallet advertises for other wallets to perform a coinjoin.&nbsp; Ann, Bob, and Carol put various amounts into the transaction, and the outputs are controlled by new public keys – and it is hard for an outsider to know who controls the new keys of the new outputs.&nbsp; Some of those outputs are controlled by Edward some by Bob, but from the blockchain, outsiders cannot tell which of the participants controls which of the outputs, and probably cannot identify most of the participants.</p><p>
While the outputs Bob initially received were likely linked to his government registered identity, the outputs he subsequently participates in generating probably have no very strong link to any one identity.</p><p>
Subsequently an output winds up under the control of Dave, who might be Bob’s identity in another country, or someone connected to Bob in another country.&nbsp; Dave wants to sell the crypto currency for a bag full of Filipino pesos, Philippine government issued fiat money.&nbsp; Government regulation in the Philippines tends to be unreliable and unpredictable, except when Duterte throws a few of the more corrupt bureaucrats and fanatical social justice warriors out of his helicopter, whereupon it improves for a while.</p><p>
Fred is in the business of buying and selling cryptocurrency for Filipino pesos, and has a human readable name registered in the blockchain, and a public key associated to that name.&nbsp; Dave performs a transaction where one of the outputs is controlled, not by a random freshly created public key, but to that registered and well known public key, that is associated with Fred and Fred’s well known and widely advertised business.&nbsp; The amount is not a round amount, a not a one or a two or a five or a ten, but the specific and exact amount.&nbsp; This creates a record that anyone can see that Fred received the money.&nbsp; And if Fred cheats Dave, Dave can issue a review of Fred, and create a record in the blockchain that anyone can see proving that the person who controlled the money that Fred received endorsed this review about Fred’s services.&nbsp; Thus the blockchain can provide reputational enforcement of non anonymous transactions.&nbsp; But the chain of transactions that started with Bob and ended with Fred may well be untraceable.&nbsp; The blockchain will not provide information linking the transactions.&nbsp; The money starts out in government enforcement of a public transaction, passes through anonymous and private transactions, and ends in blockchain enforcement of a public transaction that may well not be registered with or recorded by the government.&nbsp; </p><p>
This plan reflects our intent to replace government mediated trust and cooperation, with blockchain mediated trust and cooperation, because government mediated trust and cooperation is conspicuously failing.&nbsp; </p><p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

33
docs/universal_code_for_integers.html Normal file
View File

@ -0,0 +1,33 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style><title>Universal Code for Integers</title>
</head>
<body>
<h1>Universal Code for Integers</h1>
<p><a href="./index.html"> To Home page</a> </p>
<h2>The problem to be solved</h2>
<p>As computers and networks grow, any fixed length fields
in protocols tend to become obsolete. Therefore, for future
upwards compatibility, we want to have variable precision
numbers. This class of problem is that of a <a href="https://infogalactic.com/info/Universal_code_%28data_compression%29">
universal code for integers</a> </p>
<p>But all this stuff is too clever by half.</p>
<p>A way simpler solution in context is that all numbers are potentially sixty four bit numbers. Communication is always preceded by protocol negotiation, in which both sides agree on a protocol that guarantees they both know the schemas that will be used to represent records and what is to be done with those records. Each record will be preceded by a schema number, which tells the recipient how to interpret the ensuing record. A potentially sixty four bit number is represented by a group of up to nine bytes in little endian order, each byte containing seven bits, with its high order bit indicating whether the next byte is part of the group, except for ninth byte, if there is a ninth byte, in which case we shift left by eight instead of seven, and use the entire eight bits of the ninth byte, thus making overflow integers unrepresentable. This schema is good for schema identifiers, protocol identifiers, block numbers, length counts, database record numbers, and times dated from after the start of the information epoch. Blobs of known size will directly stored in the record. In the unlikely event that a blob is of variable size, its size will be length count in the schema, usually followed directly by the blob. If a record contains a variable number of records, again, a length count of the number of records.</p>
<p>Having spent an unreasonable amount of time and energy on figuring out optimal ways of representing variable precision numbers, and coming up with the extremely ingenious idea of representing the numbers from 2 to any positive number with an implied probability of
n*(n+1)/(4^n)/8, where n is the number of bits following the first non zero bit, I decided to throw all that stuff away.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

83
docs/user_model_of_secrets_and_coins.html Normal file
View File

@ -0,0 +1,83 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>User model of secrets and coins</title>
</head>
<body><a href="./index.html"> To Home page</a>
<h1>User model of secrets and coins</h1><p>
The entity relationship model is a view of your data, not in normal form, but
as it is meaningful and useful to the user. </p><p>
This model is to be communicated to the user, either in documentation, or, better,
in the layout of screens, so that by simply bringing up screens, the user recognizes
the model</p><p>
After you construct your entity
relationship model you work backwards to a normal form schema that supports some
select statements and insertion deletion rules that support the entity relationship
model.</p><p>
An entity is a real thing in the world that the customer cares about, and also a select statement.
A relationship is a connection between one real world thing and another, and also a bunch of rules
governing insertion and deletions, and primary and foreign keys, such that the database things
behave in a way that models the things in the world.</p><p>
Though the schema shall be in normal form, the user interface shall model the things
the user knows, the entities and their relationships, so the ER model tells one how to
construct the schema <i>and</i> the UI <i>and</i> the insertion and deletion rules.</p><p>
The ER model is thus high level documentation of the schema and user interface. The schema
shall be in normal form, the ER model in reality form.</p><p>
The ER model also defines your data objects, which encapsulate the database. For example if
a relationship between to object sets is hierarchical, your data objects give you access as if
you were using a hierarchical, rather than relational, database. Thus if entity A belongs to
entity B, hierarchical deletion and insertion is implicit, and not only does the program
follow that rule, and the database enforce that rule, but the program accesses the database
through a data object that provides no means of breaking that rule, no means of performing
an action that would cause your database to generate an error message. Your database is in
normal form, but your data objects are in closer-to-reality form</p><p>
So your data model not only tells you how to construct your schema, but also your UI and data objects</p>
<HR>
<h2>Entities:</h2>
<dl>
<dt>Coin</dt>
<dd>user only sees value, and information as to whether spent or unspent. Spent or unspent is actually a
property of the coin’s involvement in payments and backups</dd>
<dt>Payment</dt>
<dd>a group of coins, and what happened to them. Payments are linked to contracts, bills, invoices, and the like</dd>
<dt>Invoice</dt>
<dd>Demand for payment, claim that goods have in fact been delivered &ndash; not quite the concept we want.
Dictionary says &ldquo;see bill&rdquo;</dd>
<dt>Order</dt>
<dt>Offer</dt>
<dt>Bid</dt>
</dl>
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

32
docs/value_and_exchange_system.html Normal file
View File

@ -0,0 +1,32 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em; margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Value and Exchange</title>
</head>
<body>
<p><a href="./"> To Home page</a> </p>
<h1>Value and Exchange</h1>
<p>An exchange of value consists of a contract to exchange ("trade"), two
transfers of value (value for value), coordination problems
("settlement"), and dispute resolution services ("failure").</p>
<p> Hence, reliability of exchange is dominated by reliability of transfers.
And, transfers of value are dominated by reliability of basic issues of
value, including storage.</p>
<p> What might be seen as sort of semantic short-cut is that a value system
may be considered reliable if and only if it can participate in an
exchange. </p>
<p>&nbsp;</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

66
docs/verifiable_log_backed_map.html Normal file
View File

@ -0,0 +1,66 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Verifiable log backed map</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Verifiable log backed map</h1>
<p>The point and purpose of the Verifiable Log Backed Map is to provide a mapping from identiers, such as phone numbers, email addresses, etc, to public keys, which mapping has to be the same for everyone – so that if you see your public key is such and such, you know that those you converse with also see your public key is such and such.</p>
<p>For this to be actually useful, needs to drive a blogging and messaging system with capabilities analogous to facebook, wordpress, or twitter, and each entity in the system needs to have a wallet analogous to a blockchain wallet. Not all wallets should be associated with entities that can be easily found on the network, but entities that can be easily found on the network should have wallets</p>
<p>A Verifiable Log Backed map is a Verifiable Map backed by a Verifiable Log that describes an ordered set of operations that result in predictable mutations to the map.</p>
<h2>Clients of a verifiable log can:</h2><ol>
<li>Efficiently verify that a specific entry is included in the log.</li>
<li>Efficiently detect splitview attacks.</li>
<li>Efficiently verify the appendonly property of the log.</li>
<li>Enumerate all entries held in the log.</li>
</ol>
<p>The verifiable log as described is equivalent to that described in <a href="https://tools.ietf.org/html/rfc6962">RFC6962</a>.</p>
<h2>Verifiable Maps</h2>
<p>A verifiable map is a map from a set of keys to a corresponding set of values. Conceptually we map all 2<sup>256</sup> hash values to 256 bit values plus null, except that we take advantage of the fact that the tree is sparse, that most values map to null. Periodically the map will publish a signed tree head which includes a root hash of all 2<sup>256</sup> entries.</p>
<p>We implement this as a <a href="https://github.com/ethereum/wiki/wiki/Patricia-Tree">Merkle-patricia dac</a>.</p>
<p>Clients of the map can:</p>
<ol><li>Efficiently retrieve the value (or indication of nonpresence)for a key, and verify that this is included (or not present) in the map at a point in time.</li>
<li>Efficiently detect splitview attacks.</li>
<li>Enumerate all key/value pairs held in the map.</li></ol>
<p>This verifiable map as described is equivalent to the Sparse Merkle Tree described in Revocation Transparency.</p>
<h2>Verifiable LogBacked Map</H2>
<P>is a Verifiable Map backed by a Verifiable Log that describes an
ordered set of operations that result in predictable mutations to the map.</p>
<p>The following table summarizes properties of the data structures laid out above. “Efficiently” means that a client can and should perform this validation themselves. “Full audit” means that to validate correctly, a client would need to download the entire dataset, and is something that in
practices we expect a small number of dedicated auditors to perform, rather than being done by each client.
<table rules="all" frame="box">
<tr><th>&nbsp;</th><th>Verifiable Log</th><th>Verifiable Map</th><th>Verifiable LogBacked Map</th></tr>
<tr><th>Prove inclusion of value</th><td>Yes, efficiently</td><td>Yes, efficiently</td><td>Yes, efficiently</td></tr>
<tr><th>Prove noninclusion of value </th><td>Impractical </td><td>Yes, efficiently </td><td>Yes, efficiently</td></tr>
<tr><th>Retrieve provable value for key </th><td>Impractical </td><td>Yes, efficiently </td><td>Yes, efficiently</td></tr>
<tr><th>Retrieve provable current value for key </th><td>Impractical </td><td>No </td><td>Yes, efficiently</td></tr>
<tr><th>Prove appendonly </th><td>Yes, efficiently </td><td>No </td><td>Yes, efficiently, although full audit is required to verify complete correct
operation.</td></tr>
<tr><th>Enumerate all entries </th><td>Yes, by full audit </td><td>Yes, by full audit</td><td> Yes, by full audit</td></tr>
<tr><th>Prove correct operation </th><td>Yes, efficiently </td><td>No </td><td>Yes, by full audit</td></tr>
<tr><th>Enable detection of splitview </th><td>Yes, efficiently </td><td>Yes, efficiently </td><td>Yes, efficiently</td></tr>
</table>
<p>&nbsp;</p>
</body>
</html>

25
docs/vision_statement.html Normal file
View File

@ -0,0 +1,25 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style> <link rel="shortcut icon" href="../rho.ico">
<title>Replacing TCP, UDP, SSL and TLS</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Vision Statement</h1>
<p>Not yet written</p>
<p> A vision statement is a one page version of the functional spec, saying what your software will do for users
</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

31
docs/wallet_design.html Normal file
View File

@ -0,0 +1,31 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {text-align:center;}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Wallet Design</title> </head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Wallet Design</h1><p>
The standard for wallets is <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">BIPS44, also written BIP44 and bip-r44</a>, which builds on, and presupposes you have read, earlier bip standards.</p><p>
It is intended to support multicurrecy wallets, but you still have to construct a wallet for your particular currency, which the multicurrency wallet will use.</p><p>
It seems like a lot of work to implement, but that is only because you have not yet done all the work of inventing your own idiosyncratic and non standard wallet, and not yet encountered all the surprise problems, and gone down all the wrong paths.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

301
docs/wallet_implementation.html Normal file
View File

@ -0,0 +1,301 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Wallet Implementation</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Wallet Implementation</h1><p>
The primary function of the wallet file is to provide a secret key for
a public key, though eventually we stuff all sorts of user odds and ends
into it.</p><p>
In Bitcoin, this is simply a pile of random secrets, randomly generated, but obviously it is frequently useful to have them not random, but merely seemingly random to outsiders. One important and valuable application of this is the paper wallet, where one can recreate the wallet from its master secret, because all the seemingly random secret keys are derived from a single master secret. But this does not cover all use cases.</p><p>
We care very much about the case where a big important peer in a big central
node of the internet, and the owner skips out with the paper key that owns the
peer’s reputation in his pocket, and sets up the same peer in another
jurisdiction, and everyone else talks to the peer in the new jurisdiction,
and ignores everything the government seized.</p><p>
The primary design principle of our wallet is to bypass the DNS and ICANN, so
that people can arrange transactions securely. The big security hole in
Bitcoin is not the one that Monaro fixes, but that you generally arrange
transactions on the totally insecure internet. The spies care about the
metadata more than they care about the data. We need to internalize and secure
the metadata.</p><p>
We particularly want peers to be controlled by easily hidden and transported
secrets. The key design point around which all else is arranged is that if
some man owns a big peer on the blockchain, and the cops descend upon it, he
grabs a book of his bookshelf that looks like any airport book, except on
pencil in the margins of one page is his master secret, written in pencil,
and a list of all his nicknames, also written in pencil. Then he skips off
to the airport and sets up his peer on a new host, and no one notices that it
has moved except for the cops who grabbed his now useless hardware. (Because
the secrets on that hardware were only valuable because their public keys
were signed by his keys, and when he starts up the new hardware, his keys
will sign some new keys on the peer and on the slave wallet on that hardware.)
</p><p>
We also want perfect forward secrecy, which is easy. Each new connection
initiation starts with a random transient public key, and any identifying
information is encrypted in the shared secret formed from that transient public
key, and the durable public key of the recipient.</p><p>
We also want off the record messaging. So we want to prove to the recipient
that the sender knows the shared secret formed from the recipients public key
and the sender’s transient private key, and also the shared secret formed from
the recipient’s public key, the sender’s transient private key, and the
sender’s durable private key. But the recipient, though he then knows the
message came from someone who has the sender’s durable private key, cannot
prove that to a third party, because he could have constructed that shared
secret, even if the sender did not know it. The recipient could have forged
the message and sent it to himself.</p><p>
Thus we get off the record messaging. The sender by proving knowledge of two
shared secrets, proves to the recipient knowledge of two secret keys
corresponding to the two public keys provided, but though the sender proves
it to the recipient, the recipient cannot prove it to anyone else.</p><p>
The message consists of transient public key in the clear, which encrypts
durable public key. then durable public key plus transient public key encrypts
the rest of the message, which encryption proves knowledge of the secret key
underlying the durable public key, proves it to the recipient, but he cannot
prove it to anyone else.</p><p>
The durable public key may be followed by the schema identifier 2, which
implies the nickname follows, which implies the twofitytwo bit hash of the
public key followed by nickname, which is the global identifier of the
pseudonym sending the message. But we could have a different schema, 3,
corresponding to a chain of signatures authenticating that public key, subject
to timeouts and indications of authority, which we will use in slave wallets
and identifiers that correspond to a corporate role in a large organization,
or in iff applications where new keys are frequently issued.</p><p>
If we have a chain of signatures, the hash is of the root public key and the
data being signed (names, roles, times, and authorities) but not the signatures
themselves, nor the public keys that are being connected to that data.</p><p>
When someone initiates a connection using such a complex identity, he sends
proof of shared knowledge of two shared secrets, and possibly a chain of
signatures, but does not sign anything with the transient public key, nor the
durable public key at the end of the chain of signatures, unless, as with a
review, he wants the message to be shared around, in which case he signs the
portion of the message that is to be shared around with that public key, but
not the part of the message that is private between sender and receiver.</p><p>
To identify the globally unique twofitytwo bit id, the recipient hashes the
public key and the identifier that follows. Or he may already know, because
the sender has a client relationship with the recipient, that the public key
is associated with a given nickname and globally unique identifier.</p><p>
If we send the schema identifier 0, we are not sending id information, either
because the recipient already has it, or because we don’t care, or because we
are only using this durable public key with this server and do not want a
global identity that can be shared between different recipients.</p><p>
So, each master wallet will contain a strong human readable and human writeable
master secret, and the private key of each nickname will be generated by
hashing the nickname with the master secret, so that when, in some new
location, he types in the code on fresh hardware and blank software, he will
get the nickname’s public and private keys unchanged, even if he has to buy or
rent all fresh hardware, and is not carrying so much as a thumbdrive with him.
</p><p>
People with high value secrets will likely use slave wallets, which perform
functions analogous to a POP or IMAP server, with high value secrets on their
master wallet, which chats to their slave wallet, which does not have high
value secrets. It has a signed message from the master wallet authorizing it
to receive value in the master wallets name, and another separately signed
message containing the obfuscation shared secret, which is based on the
master wallet secret and an,the first integer being the number of the
transaction with the largest transaction in that name known to the master
wallet, an integer that the slave wallet increments with every request for
value. The master wallet needs to provide a name for the slave walle, and to
recover payments, needs that name. The payments are made to a public key of
the master wallet, multiplied by a pseudo random scalar constructed from the
hash of a sequential integer with an obfuscation secret supplied by the master
wallet, so that the master wallet can recover the payments without further
communication, and so that the person making the payment knows that any
payment can only be respent by someone who has the master wallet secret key,
which may itself be the key at the end of chain of signatures identity,
which the master wallet posesses, but the slave wallet does not.</p><p>
For slave wallets to exist, the globally unique id has to be not a public
key, but rather the twofiftytwo bit hash of a rule identifying the public key.
The simplest case being hash(2|public key|name), which is the identifier used
by a master wallet. A slave wallet would use the identifier hash(3|master
public key|chain of signed ids) with the signatures and public keys in the
chain omitted from the hash, so the durable public key and master secret of
the slave wallet does not need to be very durable at all. It can, and
probably should, have a short timeout and be frequently updated by messages
from the master wallet.</p><p>
The intent is that a slave wallet can arrange payments on behalf of an identity
whose secret it does not possess, and the payer can prove that he made the
payment to that identity. So if the government grabs the slave wallet, which
is located in a big internet data center, thus eminently grabbable, it grabs
nothing, not reputation, not an identity, and not money. The slave wallet has
the short lived and regularly changed secret for the public key of an
unchanging identity identity authorized to make offers on behalf a long lived
identity, but not the secret for an identity authorized to receive money on
behalf of a long lived identity. The computer readable name of these
identities is a twofiftytwo bit hash, and the human readable name is something
like receivables@_@globally_unique_human_readable_name, or
sales@_@globally_unique_human_readable_name. The master secret for
_@globally_unique_human_readable_name is closely held, and the master secret
for globally_unique_human_readable_name written in pencil on a closely held
piece of paper and is seldom in any computer at all.</p><p>
For a name that is not globally unique, the human readable name is
non_unique_human_readable_nickname zero_or_more_whitespace
42_characters_of_slash6_code zero_or_more_whitespace. </p><p>
Supposing Carol wants to talk to Dave, and the base point is B. Carols secret is the scalar <code>c</code>, and her public key is elliptic point <code>C=c*B</code>. Similarly Dave’s secret is the scalar <code>d</code>, and his public key is elliptic point
<code>D=d*B</code>.</p><p>
His secret scalar <code>d</code> is probably derived from the hash of his master secret with his nickname, which we presume is "Dave".</p><p>
They could establish a shared secret by Carol calculating <code>c*D</code>, and
Dave calculating <code>d*C</code>. But if either party’s key is seized, their
past communications become decryptable. Plus this unnecessarily leaks metadata
o people watching the interaction.</p><p>
Better, Carol generates a random scalar <code>r</code>, unpredictable to anyone
else, calculates <code>R=r*B</code>, and sends Dave <code>R, C</code> encrypted
using <code>r*D,</code> and the rest of the message encrypted using <code>
(r+c)*D</code>.</p><p>
This gives us perfect forward secrecy and off-the-record.</p><p>
One flaw in this is that if Dave’s secret leaks, not only can he and the people communicating with him be spied upon, but he can receive falsified messages that appear to come from trusted associates.</p><p>
One fix for this is the following protocol. When Carol initiates communication
with Dave, she encrypts only with the transient public and private keys, but
when Dave replies, he encrypts with another transient key. If Carol can
receive his reply, it really is Carol. This does not work with one way
messages, mail like messages, but every message that is a reply should
automatically contain a reference to the message that it replies to, and every
message should return an ack, so one way communication is a limited case.</p><p>
Which case can be eliminated by handling one way messages as followed up by
mutual acks. For TCP, the minimum set up and tear down of a TCP connection
needs three messages to set up a connection, and three messages to shut it
down, so if we could multiplex encryption setup into communication setup, which
we should, we could bullet proof authentication. To leak the least metadata,
want to establish keys as early in the process as we can while avoiding the
possibility of DNS attacks against the connection setup process. If
communication only ensues when both sides know four shared secrets, then the
communication can only be forged or intercepted by a party that knows both
sides durable secrets.</p><p>
We assume on public key per network address and port – that when she got the port
associated with the public key, she learned what which of his possibly numerous
public keys will be listening on that port.</p><p>
Carol calculates <code>(c+r)*D</code>. Dave calculates <code>d*(C+R)</code>, to arrive at a shared secret, used only once.</p><p>
That is assuming Carol needs to identify. If this is just a random anonymous client connection, in which Dave responds the same way to every client, all she needs to send is <code>R</code> and <code>D</code>. She does not need forward secrecy, since not re-using <code>R</code>. But chances are Dave does not like this, since chances are he wants to generate a record of the distinct entities applying, so a better solution is for Carol to use as her public key when talking to Dave <code>hash(c, D)*B</code></p><p>
Sometimes we are going to onion routing, where the general form of an onion routed message is [<code>R, D,</code> encrypted] with the encryption key being <code>d*R = r*D</code>. And inside that encryption may be another message of the same form, another layer of the onion.</p><p>
But this means that Dave cannot contact Carol. But maybe Carol does not want to be contacted, in which case we need a flag to indicate that this is an uncontactable public key. Conversely, if she does want to be contactable, but her network address changes erratically, she may need to include contact info, a stable server that holds her most recent network address.</p><p>
Likely all she needs is that Dave knows that she is the same entity as logged in with Dave before. (Perhaps because all he cares about is that this is the same entity that paid Dave for services to be rendered, whom he expects to keep on paying him for services he continues to render.) </p><p>
The common practical situation, of course is that Carol@Name wants to talk to Dave@AnotherName, and Name knows the address of AnotherName, and AnotherName knows the name of Dave, and Carol wants to talk to Dave as Carol@Name. To make this secure, have to have have a a commitment to the keys of Carol@Name and Dave@AnotherName, so that Dave and Carol can see that Name and AnotherName are showing the same keys to everyone.</p><p>
The situation we would like to have is a web of public documents rendered immutable by being linked into the blockchain, identifying keys, and a method of contacting the entity holding the key, the method of contacting the identity holding the key being widely available public data.</p><p>
In this case, Carol may well have a public key only for use with Name, and Dave a public key only for use with AnotherName.
If using <code>d*C</code> as the identifier, inadvisable to use a widely known <code>C</code>, because this opens attacks via <code>d</code>, so <code>C</code> should be a per host public key that Carol keeps secret.</p><p>
The trouble with all these conversations is that they leak metadata – it is visible to third parties that <code>C</code> is talking to <code>D</code>.</p><p>
Suppose it is obvious that you are talking to Dave, because you had to look up Dave’s network address, but you do not want third parties to know that <em>Carol</em> is talking to Dave. Assume that Dave’s public key is the only public key associated with this network address.</p><p>
We would rather not make it too easy for the authorities to see the public key of the entity you are contacting, so would like to have D end to end encrypted in the message. You are probably contacting the target through a rendevous server, so you contact the server on its encrypted key, and it sets up the rendevous talking to the wallet you want to contact on its encrypted key, in which case the messages you send in the clear do not need, and should not have, the public key of the target.</p><p>
Carol sends <code>R</code> to Dave in the clear, and encrypts <code>C</code> and <code>r</code>*<code>D</code>, using the shared secret key <code>r</code>*<code>D</code> = <code>d</code>*<code>R</code></p><p>
Subsequent communications take place on the shared secret key <code>(c+r)*D = d*(C+R)</code></p><p>
Suppose there are potentially many public keys associated with this network address, as is likely to be the case if it is a slave wallet performing Pop and Imap like functions. Then it has one primary public key for initiating communications. Call its low value primary keys p and P. Then Carol sends <code>R</code> in the clear, followed by <code>D</code> encrypted to <code>r*P = p*R</code>, followed by <code>C</code> and <code>r*D</code>, encrypted to <code>r*D = d*R</code>.</p><p>
We can do this recursively, and Dave can return another, possibly transient, public key or public key chain that works like a network address. This implies a messaging system whose api is that you send an arbitrary length message with a public key as address, and possibly a public key as authority, and an event identifier, and then eventually you get an event call back, which may indicate merely that the message has gone through, or not, and may contain a reply message. The messaging system handles the path and the cached shared secrets. All shared secrets are in user space, and messages with different source authentication have different connections and different shared secrets.</p><p>
Bitcoin just generates a key at random when you need one, and records it. A paper wallet is apt to generate a stack of them in advance. They offer the option of encrypting the keys with a lesser secret, but the master secret has to be stronger, because it has to be strong enough to resist attacks on the public keys.</p><p>
On reflection, there are situations where this is difficult – we would like the customer, rather than the recipients, to generate the obfuscation keys, and pay the money to a public key that consists of the recipients deeply held secret, and a not very deeply held obfuscation shared secret.</p><p>
This capability is redundant, because we also plan to attach to the transaction a Merkle hash that is the root of tree of Merkle hashes indexed by output, in Merkle-patricia order, each of which may be a random number or may identify arbitrary information, which could include any signed statements as to what the obligations the recipient of the payment has agreed to, plus information identifying the recipient of the payment, in that the signing key of the output is s*B+recipient_public key. But it would be nice to make s derived from the hash of the recipients offer, since this proves that when he spends the output, he spends value connected to obligations.</p><p>
Such receipts are likely generated by a slave wallet, which may well do things differently to a master wallet. So let us just think about the master wallet at this point. We want the minimum capability to do only those things a master wallet can do, while still being future compatible with all the other things we want to do.</p><p>
When we generate a public key and use it, want to generate records of to how it was generated, why, and how it was used. But this is additional tables, and an identifier in the table of public keys saying which additional table to look at.</p><p>
One meaning per public key. If we use the public key of a name for many purposes, use it as a name. We don’t use it as a transaction key except for transactions selling, buying, or assigning that name. But we could have several possible generation methods for a single meaning.</p><p>
And, likely, the generation method depends on the meaning. So, in the table of public keys we have a single small integer telling us the kind of thing the public key is used for, and if you look up that table indicated by the integer, maybe all the keys in that table are generated by one method, or maybe several methods, and we have a single small integer identifying the method, and we look up the key in that table which describes how to generate the key by that method.</p><p>
Initially we have only use. Names. And the table for names can have only one method, hence does not need an index identifying the method.</p><p>
So, a table of public key private key pairs, with a small integer identifying the use and whether the private key has been zeroed out, and a table of names, with the rowid of the public key. Later we introduce more uses, more possible values for the use key, more tables for the uses, and more tables for the generation methods.</p><p>
A wallet is the data of a Zooko identity. When logged onto the interent is <em>is</em> a Zooko triangle identity or Zookos quandrangle identity, but is capable of logging onto the internet as a single short user identity term, or logging on with one peer identity per host. When that wallet is logged in, it is Zooko identity with its master secret and an unlimited pile of secrets and keys generated on demand from a single master secret.</p><p>
We will want to implement the capability to receive value into a key that is not currently available. So how are we going to handle the identity that the wallet will present?</p><p>
Well, keys that have a time limited signature that they can be used for certain purposes in the name of another key are a different usage, that will have other tables, that we can add later.</p><p>
A receive only wallet, when engaging in a transaction, identifies itself as Zooko identity for which it does not have the master key, merely a signed authorization allowing it to operate for that public key for some limited lifetime, and when receiving value, requests that value be placed in public keys that it does not currently possess, in the form of a scalar and the public key that will receive the value. The public key of the transaction output will be s*B+<code>D</code>, where s is the obfuscating value that hides the beneficiery from the public blockchain, B is the base, and <code>D</code> is the beneficiary. B is public, s*B+<code>D</code> is public, but s and <code>D</code> are known only to the parties to the transaction, unless they make them public.</p><p>
And that is another usage, and another rule for generating secrets, which we can get around to another day.</p><p>
The implementation can and will vary from one peer to the next. The canonical form is going to be a Merkle-patricia dac, but the Merkle-patricia dac has to be implemented on top of something, and our first implementation is going to implement the Merkle-patricia dac on top of a particular sqlite database with a particular name, and that name stored in a location global to all programs of a particular user on a particular machine, and thus that database global to all programs of that particular user on that particular machine.</p><p>
Then we will implement a global consensus Merkle-patricia dac, so that everyone agrees on the one true mapping between human readable names, but the global consensus dac has to exist on top of particular implementations run by particular users on particular machines, whose implementation may well vary from one machine to the next.</p>
<p>A patricia tree contains, in itself, just a pile of bitstreams. To represent actual information, there has to be a schema. It has to be a representation of something equivalent to a pile of records in a pile of database tables. And so, before we represent data, before we create the patricia tree, have to first have a particular working database, a particular implementation, which represents actual data. Particular database first, then we construct universal canonical representation of that data second.</p>
<p>In every release version, starting with the very first release, we are going to have to install a database, if one is not already present, in order that the user can communicate with other users, so we will have no automagic creation of the database. I will manually create and install the first database, and will have a dump file for doing so, assuming that the dump file can create blobs.</p>
<p>A receive only wallet contains the public key and zooko name of its master wallet, optionally a thirty two byte secret, a numbered signed record by the master wallet authorizing it to use that name and receive value on the master wallet secret and its own public key.</p>
<p>A zooko quandrangle identifier consists of a public master key, a globally accepted human readable name globally accepted as identifying that key, a local human readable petname, normally identical to the global name, and an owner selected human readable nickname.</p>
<p>A contact consists of a public key, and network address information where you will likely find a person or program that knows the corresponding private key, or is authorized by that private key to deal with communications.</p>
<p>So, first thing we have to do is create a wxWidgets program that accesses the database, and have it create Zooko’s triangle identities, with the potential for becoming Zooko’s quandrangle identities.</p>
<h2>Proving knowledge of the secret key of a public key</h2><p>
Our protocol, unlike bitcoin, has proof of transaction. The proof is private, but can be made public, to support ebay type reputations.</p>
<p>Supposing you are sending value to someone, who has a big important reputation that he would not want damaged. And you want proof he got the value, and that he agreed to goods, services, or payment of some other form of money in return for the value.</p>
<p>Well, if he has a big important reputation, chances are you are not transacting with him personally and individually through a computer located behind a locked door in his basement, to which only he has the key, plus he has a shotgun on the wall near where he keeps the key. Rather, you are transacting with him through a computer somwhere in the cloud, in a big computing center to which far too many people have access, including the computer center management, police, the Russian mafia, the Russian spy agency, and the man who mops the floors.</p>
<p>So, when "he", which is to say the computer in the cloud, sends you public keys for you to put value into on the blockchain, you want to be sure that only he can control value you put into the blockchain. And you want to be able to prove it, but you do not want anyone else except you and he (and maybe everyone who has access to the data center on the cloud) can prove it except you make the data about your transaction public.</p>
<p>You are interacting with a program. And the program probably only has low value keys. It has a key signed by a key signed by a key signed by his high value and closely held key, with start times and timeouts on all of the intermediate keys.</p><p>
So he should have a key that is not located in the datacenter, and you want proof that only the holder of that key can spend the money – maybe an intermediate key with a timeout on it that authorizes it to receive money, which signs an end key that authorizes the program to agree to deals, but not to receive money – the intermediate key authorized to receive money presumably not being in the highly insecure data center.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>

174
docs/what_is_to_be_done.html Normal file
View File

@ -0,0 +1,174 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<style> p.center { text-align:center; }
body {
max-width: 30em;
margin-left: 2em;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>What is to be done</title>
</head>
<body>
<h1>What is to be done</h1>
<p>
This is incoherent, and not yet ready for the rest of the
world to see.</p>
<p>
Zooko Identity system.</p>
<p>
One of the services an identity may provide is IM
equivalent, email equivalent, single sign on service,
monetary transfer, and contract formation. If it
provides one of these, it normally provides the other
three.</p>
<p>
Another service an identity provide is https equivalent,
only with yurls instead of urls.</p>
<p>
At the lowest level, we have multilayer protocol
negotiation process in which the layers are integrated
so that additional layers do not result in additional
round trips.</p>
<p>
Excess round tripping is avoided by having compile time
layering rather than run time layering. At compile
time, a layered description generates a fully integrated
protocol, with optimistic protocol negotiation, so that
if all goes well, all levels of the protocol are agreed
in a single round trip. Layered source code is compiled
into integrated and unlayered run time code.&nbsp; According to Google
research, we lose two percent of users for every second of delay a web
page takes in coming up.</p>
<p>
At the lowest level we have an IP equivalent protocol,
with network addresses as opaque blobs of variable size.
Typically these blobs contain IP addresses, possibly IP
addresses plus port number, plus some additional
information, with packets typically encapsulated as udp
packets, during session establishment, imitations of tpc
establishment packets. Possibly we imitate tcp packets.
Anyone can write their own IP imitation and drop it in,
leaving all other code unchanged, thus if an ISP is
playing hardball, as comcast does, one can encapsulate
information inside packets that pass ISP inspection as
some more politically correct packets. The intent here
is that if someon is having trouble with comcast, lots
of people will add additional comcast resistent IP
layers, and if you compile your server with that layer,
and someone under comcast activates that layer in his
client, he will talk lie-to-comcast with the server,
while the server transparently talks some other IP
imitation protocol with other clients. </p>
<p>
Layering, however, is compile time, thus to support a
new hide-from-the-isp protocol, clients and servers have
to be recompiled with the new library, rather than it
being put in the OS, and binaries then automatically
using it. That is a cost of compile time layering. The
cost of run time layering is additional round
trips.</p>
<p>
Money should support webmoney, also Satoshi Nakamoto’s
bitgold coins, if available.</p>
<p>
"Satoshi Nakamoto" &lt;satoshi@vistomail.com&gt; has
published a transferrable proof of work protocol,
http://www.bitcoin.org/bitcoin.pdf, (I have a local
copy) </p>
<p>
The core concept is that multiple people keep copies of a hash tree
saying who owns what coins, and in order to add new coins to the list,
you have to have a copy of the tree. </p>
<p>
Problem is this makes coins expensive, for to be
reasonaly safe against private and public attack, the
system needs more than a dozen or so copies. </p>
<p>
Bitcoin transactions are cheap enough to compete with
bankcards, but we already have a bankcard system that
works fine. An alternative system cannot compete
directly. </p>
<p>
Instead, an alternative system has to provide service in
an area where bankcard cannot. </p>
<p>
File sharing is an obvious area. At present, file
sharing works by barter for bits. This, however requires
the double coincidence of wants. People only upload
files they are downloading, and once the download is
complete, stop seeding. So only active files, files that
quite a lot of people want at the same time, are
available. </p>
<p>
File sharing requires extremely cheap transactions, so to
support file sharing on bitcoins, we will need a layer of
account money on top of the bitcoins, supporting
transactions of a hundred thousandth the size of the
smallest coin, and to support anonymity, chaumian money
on top of the account money. </p>
<p>
Let us call a bitcoin bank a bink.&nbsp; The bitcoins
stand in the same relation to account money as gold stood
in the days of the gold standard.&nbsp; The binks, not
trusting each other to be liquid when liquidity is most
needed, settle out any net discrepancies with each other
by moving bit coins around once every hundred thousand
seconds or so, so bitcoins do not change owners that
often,&nbsp;&nbsp; Most transactions cancel out at the
account level.&nbsp; The binks demand bitcoins of each
other only because they don’t want to hold account money
for too long. So a relatively small amount of
bitcoins infrequently transacted can support a
somewhat larger amount of account money frequently
transacted. </p>
<p>
But I digress, I ramble.&nbsp; In order to make all this
stuff work, we need yurls – but yurls as specified lack
some capabilities.</p>
<p>
I was thinking of putting up a bink in the cloud, and
then thought "and suppose the government steals
it."&nbsp; Well obviously, we want all its secrets to
have a time out after a while, so the government gets
stuff all, and pretty soon the bink pops up somewhere
else. </p>
<p>
We need each yurl to represent an equivalence class of
yurls, so that we can have keys that authorize keys, keys
that time out and are replaced by superior master keys,
and such like.&nbsp; To implement companies, we need m
of&nbsp; signatures – a key is valid if is signed by m of
the underlying n keys, and so forth. </p>
<p>
To support action in the cloud, we need the process of
secret establishment to provide for a new IP – you hit up
the permanent IP, and get a secret shared with a
transient IP. </p>
<p>
We need protocol generation – you specify your messages,
you get a generated client server that supports protocol
negotiation, and on top of best effort messages provides
session establishment, shared secrets, DNS resistance,
and within a session, flow control, at least once
messages not necessarily in order, at most once messages
in order, and once and only once messages in order.
</p>
<p>
And then we need yurls representing identity, instant
messaging from yurl to yurl, therefore yurls representing
instant messaging addresses, buddies, yurls representing
sums of money, and yurls representing contracts. </p>
<p>
When we can do all that, then we have for filesharing by
such entities, thus a need for binks, and binks have a
need for bitcoins, but first the yurls, for there is lots
of stuff we can do with yurls. </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons
Attribution-Share Alike 3.0 License</a></p>
</body>
</html>