forked from cheng/wallet
put in the machinery for a navbar, a navcolumn
and a banner. Broke all my existing markdown builds, because I have a hundred files that do not fit the new machinery And now I have to provide navbars for each directory, and update the mkdocs.sh in each directory And add a recursive invocation of mkdocs in subdirectories
This commit is contained in:
parent
e679bb5960
commit
8cfb02ee99
7
docs/libraries/mkdocs.sh
Normal file
7
docs/libraries/mkdocs.sh
Normal file
@ -0,0 +1,7 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
echo `dirname $0`
|
||||
cd `dirname $0`
|
||||
docroot="../"
|
||||
templates=$docroot"pandoc_templates"
|
||||
. $templates"/mkdocs.cfg"
|
146
docs/mkdocs.sh
146
docs/mkdocs.sh
@ -2,142 +2,14 @@
|
||||
set -e
|
||||
echo `dirname $0`
|
||||
cd `dirname $0`
|
||||
docroot="./"
|
||||
templates=$docroot"pandoc_templates"
|
||||
. $templates"/mkdocs.cfg"
|
||||
|
||||
if [[ "$OSTYPE" == "linux-gnu"* ]]; then
|
||||
osoptions=""
|
||||
elif [[ "$OSTYPE" == "darwin"* ]]; then
|
||||
osoptions=""
|
||||
elif [[ "$OSTYPE" == "cygwin" ]]; then
|
||||
osoptions="--fail-if-warnings --eol=lf "
|
||||
elif [[ "$OSTYPE" == "msys" ]]; then
|
||||
osoptions="--fail-if-warnings --eol=lf "
|
||||
fi
|
||||
templates=$(pwd)"/pandoc_templates"
|
||||
options=$osoptions"--toc -N --toc-depth=5 --from markdown+smart --wrap=preserve --metadata=lang:en --include-in-header=icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o"
|
||||
pwd
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt $base.html ];
|
||||
then
|
||||
katex=""
|
||||
mine="--include-after-body=$templates/after.pandoc "
|
||||
for i in 1 2 3 4 5 6
|
||||
do
|
||||
read line
|
||||
if [[ $line =~ katex$ ]];
|
||||
then
|
||||
katex=" --katex=./"
|
||||
fi
|
||||
if [[ $line =~ notmine ]];
|
||||
then
|
||||
mine=" "
|
||||
fi
|
||||
done <$f
|
||||
pandoc $katex $mine $options $base.html $base.md
|
||||
echo "$base.html from $f"
|
||||
libraries/mkdocs.sh
|
||||
|
||||
#else
|
||||
# echo " $base.html up to date"
|
||||
fi
|
||||
done
|
||||
cd libraries
|
||||
options=$osoptions"--toc -N --toc-depth=5 --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o"
|
||||
pwd
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt $base.html ];
|
||||
then
|
||||
mine="--include-after-body=$templates/after.pandoc "
|
||||
katex=""
|
||||
for i in 1 2 3 4
|
||||
do
|
||||
read line
|
||||
if [[ $line =~ katex ]];
|
||||
then
|
||||
katex=" --katex=./"
|
||||
fi
|
||||
if [[ $line =~ notmine ]];
|
||||
then
|
||||
mine=" "
|
||||
fi
|
||||
done <$f
|
||||
echo "generating $base.html from $f"
|
||||
pandoc $katex $mine $options $base.html $base.md
|
||||
#else
|
||||
# echo " $base.html up to date"
|
||||
fi
|
||||
done
|
||||
cd ..
|
||||
cd names
|
||||
options=$osoptions"--toc -N --toc-depth=5 --from markdown+smart --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o"
|
||||
pwd
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt $base.html ];
|
||||
then
|
||||
mine="--include-after-body=$templates/after.pandoc "
|
||||
katex=""
|
||||
for i in 1 2 3 4
|
||||
do
|
||||
read line
|
||||
if [[ $line =~ katex ]];
|
||||
then
|
||||
katex=" --katex=./"
|
||||
fi
|
||||
if [[ $line =~ notmine ]];
|
||||
then
|
||||
mine=" "
|
||||
fi
|
||||
done <$f
|
||||
echo "generating $base.html from $f"
|
||||
pandoc $katex $mine $options $base.html $base.md
|
||||
fi
|
||||
done
|
||||
cd ..
|
||||
cd setup
|
||||
options=$osoptions"--toc -N --toc-depth=5 --from markdown+smart --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css --include-after-body=$templates/after.pandoc -o"
|
||||
pwd
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt $base.html ];
|
||||
then
|
||||
katex=""
|
||||
for i in 1 2 3 4
|
||||
do
|
||||
read line
|
||||
if [[ $line =~ katex ]];
|
||||
then
|
||||
katex=" --katex=./"
|
||||
fi
|
||||
done <$f
|
||||
echo "generating $base.html from $f"
|
||||
pandoc $katex $options $base.html $base.md
|
||||
#else
|
||||
# echo " $base.html up to date"
|
||||
fi
|
||||
done
|
||||
cd ..
|
||||
cd rootDocs
|
||||
pwd
|
||||
katex=""
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt ../../$base.html ];
|
||||
then
|
||||
echo "generating $base.html from $f"
|
||||
pandoc $katex $options ../../$base.html $base.md
|
||||
#--include-in-header=style.css
|
||||
#else
|
||||
# echo " $base.html up to date"
|
||||
fi
|
||||
done
|
||||
names/mkdocs.sh
|
||||
|
||||
setup/mkdocs.sh
|
||||
|
||||
rootDocs/mkdocs.sh
|
||||
|
7
docs/names/mkdocs.sh
Normal file
7
docs/names/mkdocs.sh
Normal file
@ -0,0 +1,7 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
echo `dirname $0`
|
||||
cd `dirname $0`
|
||||
docroot="../"
|
||||
templates=$docroot"pandoc_templates"
|
||||
. $templates"/mkdocs.cfg"
|
@ -13,95 +13,7 @@ Zooko’s triangle is the solution to this problem. It is explained in several p
|
||||
|
||||
- [An Introduction to Petname Systems](petnames.html)
|
||||
|
||||
<svg
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
width="width: 100%" height="100%"
|
||||
viewBox="-2500 -2400 4870 4300"
|
||||
style="background-color:#ddd">
|
||||
<g fill="none" font-family="Georgia" font-size="200"
|
||||
font-weight="400"
|
||||
>
|
||||
<path stroke="#d8d800" stroke-width="36.41"
|
||||
d="
|
||||
M-1732,1000 m-34,-68.2 l3464.076,0
|
||||
" />
|
||||
<path stroke="#888" stroke-width="60"
|
||||
d="M-1732,1000 m76,30, l1732,-3000"
|
||||
/>
|
||||
<path stroke="#990" stroke-width="36.41"
|
||||
d="M-1732,1000,
|
||||
m78,0, l1732,-3000
|
||||
" />
|
||||
<path stroke="#ffffaa" stroke-width="36.41"
|
||||
d="
|
||||
M-55,-2040,L-1834,1040
|
||||
" />
|
||||
<path stroke="#cc0" stroke-width="36.41"
|
||||
d="
|
||||
M0,-2000 m55,-40 l1732,3000
|
||||
" />
|
||||
<path stroke="#d8d800" stroke-width="36.41"
|
||||
d="
|
||||
M0,-2000 m-34,77 l1732,3000
|
||||
" />
|
||||
<path stroke="#bb0" stroke-width="36.41"
|
||||
d="
|
||||
M-1810,1068, l3610,0
|
||||
" />
|
||||
<path stroke="#dd0" stroke-width="100"
|
||||
d="
|
||||
M-1732,1000 L0, -2000 L1732,1000 Z
|
||||
" />
|
||||
<g id="left_corners" transform="translate(0, -2000)">
|
||||
<path fill="#d4d450" stroke-width="0"
|
||||
d="
|
||||
M0,0
|
||||
l57.735, 0, l21,-37, l-158,-00, l21,37 z
|
||||
" />
|
||||
<path fill="#ddd" stroke-width="0" id="erase_corner"
|
||||
d="M-80-37 l160,0, l0-100, l-160,0, z "
|
||||
/>
|
||||
</g>
|
||||
<g id="left_corners_shadow" transform="translate(0, -2000)">
|
||||
<path fill="#990" stroke-width="0"
|
||||
d=" M14.3,197.5 l-35.33,-61.19 l21.32,-36.742 z
|
||||
" />
|
||||
</g>
|
||||
<use transform="matrix(-.5 -0.866 .886 -.5 40 00)" href="#left_corners" />
|
||||
<g transform="matrix(.5 -0.866 -.886 -.5 1732 1000)" stroke-width="0">
|
||||
<path fill="#990"
|
||||
d="M0,0 l57.735, 0, l21,-37, l-158,-00, l21,37 z
|
||||
" />
|
||||
<path fill="#ddd"
|
||||
d="M0,-57 l78 0, l0,-50, l-150,-00, l0,50 z
|
||||
" />
|
||||
<path fill="#888"
|
||||
d="M0,-37 l78 0, l-11.795,-20.43, l-132,-00, l-11.795,20.43 z
|
||||
" />
|
||||
</g>
|
||||
<path fill="#d8d800"
|
||||
d="M-1732,1000 m 87,-50 l90 0, l0,-36.41 z"
|
||||
/>
|
||||
<text x="0" y="-1150" text-anchor="middle" style="fill:#000" transform="rotate(60 0,0)" >
|
||||
Nicknames
|
||||
</text>
|
||||
<text x="0" y="-1150" text-anchor="middle" style="fill:#000" transform="rotate(-60 0,0)" >
|
||||
Public Keys
|
||||
</text>
|
||||
<text x="0" y="1285" text-anchor="middle" style="fill:#000" >
|
||||
Local Names
|
||||
</text>
|
||||
<text x="0" y="-2100" text-anchor="middle" style="fill:#000" >
|
||||
Global
|
||||
</text>
|
||||
<text x="0" y="2240" text-anchor="middle" style="fill:#000" transform="rotate(-60 0,0)">
|
||||
Memorable
|
||||
</text>
|
||||
<text x="0" y="2240" text-anchor="middle" style="fill:#000" transform="rotate(60 0,0)">
|
||||
Securely Unique
|
||||
</text>
|
||||
</g>
|
||||
</svg>
|
||||
![](zookos_triangle.svg){width="80%" height="auto"}
|
||||
|
||||
A Zooko name system can only be useful inside a user interface that detects name collisions in human readable names by looking at the globally unique public key and substitutes, or insists on someone substituting, a securely unique local human readable name (petname).
|
||||
|
||||
|
@ -1 +0,0 @@
|
||||
<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>
|
@ -1 +0,0 @@
|
||||
<p><a href="./index.html"> To Home page</a></p>
|
38
docs/pandoc_templates/mkdocs.cfg
Normal file
38
docs/pandoc_templates/mkdocs.cfg
Normal file
@ -0,0 +1,38 @@
|
||||
if [[ "$OSTYPE" == "linux-gnu"* ]]; then
|
||||
osoptions=""
|
||||
elif [[ "$OSTYPE" == "darwin"* ]]; then
|
||||
osoptions=""
|
||||
elif [[ "$OSTYPE" == "cygwin" ]]; then
|
||||
osoptions="--fail-if-warnings --eol=lf "
|
||||
elif [[ "$OSTYPE" == "msys" ]]; then
|
||||
osoptions="--fail-if-warnings --eol=lf "
|
||||
fi
|
||||
options=$osoptions"--toc --number-sections --toc-depth=5 --from markdown+smart+raw_html+native_divs+native_spans+fenced_divs+bracketed_spans --to html5 --wrap=preserve --metadata=lang:en --include-in-header=icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o"
|
||||
for f in *.md
|
||||
do
|
||||
len=${#f}
|
||||
base=${f:0:($len-3)}
|
||||
if [ $f -nt $destdir$base.html ];
|
||||
then
|
||||
katex=""
|
||||
line=""
|
||||
mine="--include-after-body=$templates/after.pandoc "
|
||||
for i in 1 2 3 4 5 6
|
||||
do
|
||||
read line
|
||||
if [[ $line =~ katex$ ]];
|
||||
then
|
||||
katex=" --katex=./"
|
||||
fi
|
||||
if [[ $line =~ notmine ]];
|
||||
then
|
||||
mine=" "
|
||||
fi
|
||||
done <$f
|
||||
pandoc $katex $mine $options $destdir$base.html $base.md
|
||||
echo "$base.html from $f"
|
||||
|
||||
#else
|
||||
# echo " $base.html up to date"
|
||||
fi
|
||||
done
|
@ -51,3 +51,82 @@ pre.terminal_image {
|
||||
font-size: 75%;
|
||||
white-space: no-wrap;
|
||||
}
|
||||
|
||||
* { box-sizing: border-box;}
|
||||
|
||||
.logo-header {
|
||||
background-color:#dfdfff;
|
||||
padding: 0px;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
.logo-header::after {
|
||||
content: "Building internet protocols that rest on the consensus of the blockchain, rather than the authority of giant organizations";
|
||||
}
|
||||
|
||||
#logo-graphic{
|
||||
height:10ex;
|
||||
float: left;
|
||||
z-index: 1;
|
||||
}
|
||||
|
||||
#Rhocoin::before{
|
||||
content: "Rhocoin";
|
||||
font-size: 2em;
|
||||
font-weight: normal;
|
||||
margin-top: 1px;
|
||||
position: relative; left: -0.3em; top: -4px;
|
||||
float: left;
|
||||
}
|
||||
|
||||
#TOC {background-color: #cfffcf;}
|
||||
|
||||
/* Styling for the button bar */
|
||||
.button-bar {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
justify-content: space-between;
|
||||
background-color: #FFF;
|
||||
padding: 5px;
|
||||
padding-left: 8px;
|
||||
padding-right: 8px;
|
||||
/*box-shadow: 2px 2px 5px 1px #000; Add shadow for raised effect */
|
||||
box-shadow: inset 0px 0px 12px 8px #888;
|
||||
}
|
||||
|
||||
/* Styling for the inactive buttons inside the button bar */
|
||||
.button-bar button {
|
||||
background-color: #4CAF50;
|
||||
color: white;
|
||||
padding: 5px 5px;
|
||||
border: none;
|
||||
margin-top: 4px;
|
||||
margin-bottom: 6px;
|
||||
box-shadow: 0 0 0 1px #000;
|
||||
transform: translateY(2px);
|
||||
}
|
||||
|
||||
/* Styling for the links inside the button bar */
|
||||
.button-bar a {
|
||||
display: inline-block;
|
||||
text-decoration: none;
|
||||
background-color: #4CAF50;
|
||||
color: white;
|
||||
padding: 5px 5px;
|
||||
border: none;
|
||||
margin-top: 5px;
|
||||
margin-bottom: 6px;
|
||||
box-shadow: 2px 2px 5px 1px #000; /* Add shadow for raised effect */
|
||||
}
|
||||
|
||||
/* Style for the "pressed" effect */
|
||||
.button-bar a:active {
|
||||
box-shadow: 0 0 0 1px #000;
|
||||
transform: translateY(2px);
|
||||
}
|
||||
.myabstract{margin-left: 8%; margin-right: 12%;}
|
||||
span.bigbold{
|
||||
font-weight: bold;
|
||||
font-size: 120%;
|
||||
}
|
||||
|
||||
|
@ -1,109 +1,120 @@
|
||||
<!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>
|
||||
---
|
||||
lang: en
|
||||
title: Book of Revelations Prophecy of the Beast
|
||||
---
|
||||
# Rhocoin and the Beast
|
||||
|
||||
<body>
|
||||
<p><a href="./index.html"> To Home page</a> </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.
|
||||
|
||||
<h1>Rhocoin and the Beast</h1><p>
|
||||
We also need one whose consensus protocol is more resistant to government leverage. Ethereum is alarmingly vulnerable to pressure from our enemies.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
We also need one whose consensus protocol is more resistant to government leverage. Ethereum is alarmingly vulnerable to pressure from our enemies.</p><p>
|
||||
Thus we need a pseudonymous, not an anonymous, crypto currency.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
Thus we need a pseudonymous, not an anonymous, crypto currency.</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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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 Prophecy of the Beast
|
||||
|
||||
The Beast with seven heads establishes a false, state enforced religion, which converges all other religons to it and:</p>
|
||||
Book of Revelation 13:16 The Beast with seven heads establishes a false, state enforced religion, which converges all other religions to it and:
|
||||
|
||||
<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>
|
||||
> 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:\
|
||||
> 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.
|
||||
|
||||
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>
|
||||
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 also 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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
for fiat money.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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 come 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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
true worship of Gnon requires.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
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>
|
||||
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.
|
||||
|
||||
I don't think the prophecy of the beast will come to pass, but only because
|
||||
Christians have a commission from God to make sure it does not happen this time around.
|
||||
|
||||
The economic and financial system of the prophecy requires a one world order,
|
||||
and there are and will be conflicts over who is going to be the one.
|
||||
Tensions over the dangerously powerful global financial system are a large part
|
||||
of the current proxy war between the Global American Empire and Russia,
|
||||
and the looming wars with China and Iran. If the prophecy comes to pass,
|
||||
the nukes are going to fly. Which will probably not be the end times either,
|
||||
but will have a more than passing resemblance.
|
||||
|
||||
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
|
||||
|
||||
The rhocoin design aims to ensure that when power gets concentrated, as with scaling it
|
||||
inevitably will, it gets concentrated into peers controlled by whaltes 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
|
||||
beating in their faces. Proof of share means that the system operates
|
||||
effectively like corporate board, and since "votes" are proportional to crypto currency
|
||||
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>
|
||||
people who prefer banking in secrecy and do not trust each other all that much.
|
||||
|
336
docs/program/scalability.md
Normal file
336
docs/program/scalability.md
Normal file
@ -0,0 +1,336 @@
|
||||
---
|
||||
title: >-
|
||||
Scalable and private blockchain
|
||||
sidebar: true
|
||||
notmine: false
|
||||
...
|
||||
|
||||
::: myabstract
|
||||
[abstract:]{.bigbold}
|
||||
Bitcoin does not scale to the required size. The Bitcoin reliable broadcast
|
||||
channel is a massively replicated public ledger of every transaction
|
||||
that ever there was, each of which has to be evaluated for correctness
|
||||
by every full peer. With recursive snarks, we can now instead have a
|
||||
massively replicated public sql index of private ledgers.
|
||||
Such a blockchain with as many transactions as bitcoin, will,
|
||||
after running for as long as Bitcoin, only occupy a few dozen megabytes
|
||||
of disk storage, rather than near a terabyte, and each peer and client wallet only has to
|
||||
evaluate the root recursive snark to prove the validity of every transaction
|
||||
that ever there was, including all those lost in the mists of time.
|
||||
:::
|
||||
|
||||
# Scaling, privacy, and recursive snarks
|
||||
|
||||
Bitcoin does not not scale because it is a massively replicated public ledger.
|
||||
Thus any real solution means making the ledger *not* massively replicated.
|
||||
Which means either centralization,
|
||||
a central bank digital currency, which is the path Ethereum is walking, or privacy.
|
||||
|
||||
You cure both blockchain bloat and blockchain analysis by *not*
|
||||
putting the data on the reliable broadcast channel in the first
|
||||
place, rather than doing what Monero does, putting it on the
|
||||
blockchain in cleverly encrypted form, bloating the blockchain
|
||||
with chaff intended to obfuscate against blockchain analysis.
|
||||
|
||||
# Pre-requisites
|
||||
|
||||
This explanation is going to require you to know what a graph,
|
||||
vertex, edge, root, and leaf is, what a directed acyclic graph (dag)
|
||||
is, what a hash is, what a blockchain is,
|
||||
and how hashes make blockchains possible.
|
||||
And what an sql index is and what it does, and what a primary sql index is and what it does.
|
||||
You need to know what a transaction output is in the context of blockchains,
|
||||
and what an unspent transaction output (utxo) is.
|
||||
Other terms will be briefly and cryptically explained as necessary.
|
||||
|
||||
# Some brief and cryptic explanations of the technology
|
||||
|
||||
I have for some time remarked that recursive snarks make a
|
||||
fully private, fully scalable, currency, possible.
|
||||
But it seems this was not obvious to everyone,
|
||||
and I see recursive snarks being applied in complicated convoluted stupid ways that fail to utilize their enormous potential.
|
||||
This is in part malicious, the enemy pouring mud into the tech waters. So I need to explain.
|
||||
|
||||
## recursive snarks, zk-snarks, and zk-starks
|
||||
|
||||
A zk-snark or a zk-stark proves that someone knows something,
|
||||
knows a pile of data that has certain properties, without revealing
|
||||
that pile of data. Such that he has a preimage of a hash that has certain properties – such as the property of being a valid transaction.
|
||||
You can prove an arbitrarily large amount of data
|
||||
with an approximately constant sized recursive snark.
|
||||
So you can verify in a quite short time that someone proved
|
||||
something enormous (proved something for every transaction
|
||||
in the blockchain) with a quite small amount of data.
|
||||
|
||||
A recursive snark is a zk-snark that proves that the person who
|
||||
created it has verified a zk-stark that proves that someone has
|
||||
verified a zk-snark that proves that someone has verified …
|
||||
|
||||
So every time you perform a transaction, you don't have to
|
||||
prove all the previous transactions and generate a zk-snark
|
||||
verifying that you proved it. You have to prove that you verified
|
||||
the recursive snark that proved the validity of the unspent
|
||||
transaction outputs that you are spending.
|
||||
|
||||
## structs
|
||||
|
||||
A struct is simply some binary data laid out in well known and agreed format.
|
||||
Almost the same thing as an sql row, except that
|
||||
an sql row does not have a well known and agreed binary format,
|
||||
so does not have a well defined hash, and a struct is not
|
||||
necessarily part of an sql table, though obvious you can put a
|
||||
bunch of structs of the same type in an sql table, and represent an
|
||||
sql table as a bunch of structs, plus at least one primary index.
|
||||
An sql table is equivalent to a pile of structs,
|
||||
plus at least one primary index of those structs.
|
||||
|
||||
## merkle graphs and merkle trees
|
||||
|
||||
A merkle graph is a directed acyclic graph whose vertices are
|
||||
structs containing hashes
|
||||
|
||||
A merkle vertex is a struct containing hashes.
|
||||
The hashes, merkle edges, are the edges of the graph.
|
||||
So using recursive snarks over a merkle graph,
|
||||
each vertex has a proof that proved that its data was valid,
|
||||
given that the vertices that its edges point to were valid,
|
||||
and that the peer that created the recursive snark of that
|
||||
vertex verified the recursive snarks of the vertices that the
|
||||
outgoing edges (hashes) of this vertex points to.
|
||||
|
||||
So, you have a merkle chain of blocks, each block containing a
|
||||
merkle patricia tree of merkle dags. You have a recursive snark
|
||||
that proves the chain, and everything in it, is valid (no one
|
||||
created tokens out of thin air, each transaction merely moved
|
||||
the ownership of tokens) And then you prove that the new block is valid, given that rest of the chain was valid, and produce a
|
||||
recursive snark that the new block, which chains to the previou
|
||||
block, is valid.
|
||||
|
||||
## reliable broadcast channel
|
||||
|
||||
If you publish information on a reliable broadcast channel,
|
||||
everyone who looks at the channel is guaranteed to see it and to
|
||||
see the same thing, and if someone did not get the information
|
||||
that you were supposed to send over the channel, it is his fault,
|
||||
not yours. You performed the protocol correctly.
|
||||
|
||||
A blockchain is a merkle chain *and* a reliable broadcast channel.
|
||||
In Bitcoin, the reliable broadcast channel contains the entire
|
||||
merkle chain, which obviously does not scale, and suffers from a
|
||||
massive lack of privacy, so we have introduce the obscure
|
||||
cryptographic terminology "reliable broadcast channel" to draw a
|
||||
distinction that does not exist in Bitcoin. In Bitcoin the merkle
|
||||
vertices are very large, each block is a single huge merkle vertex,
|
||||
and each block lives forever on an ever growing public broadcast
|
||||
channel. It is impractical to produce a recursive snark over such
|
||||
huge vertices, and attempting to do so results in centralization,
|
||||
with the recursive snarks being created in a few huge data centers,
|
||||
which is what is happening with Ethereum's use of recursive snarks.
|
||||
So we need to structure the data as large dag of small merkle
|
||||
vertices, with all the paths through the dag for which we need to
|
||||
generate proofs being logarithmic in the size of the contents of
|
||||
the reliable broadcast channel.
|
||||
|
||||
## Merkle patricia tree
|
||||
|
||||
A merkle patricia tree is a representation of an sql index as a
|
||||
merkle tree. Each edge of a vertex is associated with a short
|
||||
bitstring, and as you go down the tree from the root (tree graphs
|
||||
have their root at the top and their leaves at the bottom, just to
|
||||
confuse the normies) you append that bitstring, and when you
|
||||
reach the edge (hash) that points to a leaf, you have a bitstring
|
||||
that corresponds to path you took through the merkle tree, and to
|
||||
the leading bits of the bitstring that make that key unique in the
|
||||
index. Thus the sql operation of looking up a key in an index
|
||||
corresponds to a walk through the merkle patricia tree
|
||||
guided by the key.
|
||||
|
||||
# Blockchain
|
||||
|
||||
Each block in the chain is an set of sql tables, represented as merkle dags.
|
||||
|
||||
So a merkle patricia tree and the structs that its leaf edges point
|
||||
to is an sql table that you can generate recursive snarks for,
|
||||
which can prove things about transactions in that table. We are
|
||||
unlikely to be programming the blockchain in sql, but to render
|
||||
what one is doing intelligible, it is useful to think and design in sql.
|
||||
|
||||
So with recursive snarks you can prove that that your transaction
|
||||
is valid because certain unspent transaction outputs were in the
|
||||
sql index of unspent transaction outputs, and were recently spent
|
||||
in the index of commitments to transactions, without revealing
|
||||
which outputs those were, or what was in your transaction.
|
||||
|
||||
It is a widely shared public index. But what it is an index of is
|
||||
private information about the transactions and outputs of those
|
||||
transactions, information known only to the parties of those
|
||||
transactions. It is not a public ledger. It is a widely shared
|
||||
public sql index of private ledgers. And because it is a merkle
|
||||
tree, it is possible to produce a single reasonably short recursive
|
||||
snark for the current root of that tree that proves that every
|
||||
transaction in all those private ledgers was a valid transaction
|
||||
and every unspent transaction output is as yet unspent.
|
||||
|
||||
## performing a transaction
|
||||
|
||||
Oops, what I just described is a whole sequence of complete
|
||||
immutable sql indexes, each new block a new complete index.
|
||||
But that would waste a whole lot of bandwidth. What you want is
|
||||
that each new block is only an index of new unspent transaction
|
||||
outputs, and of newly spent transaction outputs, which spending
|
||||
events will give rise to new unspent transaction outputs in later
|
||||
blocks, and that this enormous pile of small immutable indexes
|
||||
gets summarized as single mutable index, which gets complicated. I will get to that later – how we purge the hashes of
|
||||
used outputs from the public broadcast channel, winding up with
|
||||
a public broadcast channel that represents a mutable index of an
|
||||
immutable history, with a quite a lot of additional house keeping
|
||||
data that tells how to derive the mutable index from this pile of
|
||||
immutable indices, and tells us what parts of the immutable
|
||||
history only the parties to the transaction need to keep around
|
||||
any more, what can be dumped from the public broadcast channel.
|
||||
Anything you no longer need to derive the mutable index, you can dump.
|
||||
|
||||
The parties to a transaction agree on a transaction – typically
|
||||
two humans and two wallets, each wallet the client of a peer on
|
||||
the blockchain.
|
||||
|
||||
Those of them that control the inputs to the transaction
|
||||
(typically one human with one wallet which is a client of one peer)
|
||||
commits unspent transactions outputs to that transaction,
|
||||
making them spent transaction outputs. But does not reveal that
|
||||
transaction, or that they are spent to the same transaction –
|
||||
though his peer can probably guess quite accurately that they are.
|
||||
|
||||
In the next block that is a descendant of that block the parties to
|
||||
the transaction prove that the new transaction outputs are valid,
|
||||
and being new are unspent transaction outputs, without revealing
|
||||
the transaction or the inputs to that transaction.
|
||||
|
||||
You have to register the unspent transaction outputs on the public
|
||||
index, the reliable broadcast channel, within some reasonable
|
||||
time, say perhaps below block height $\lfloor(h/32⌋+2\rfloor)*32$,
|
||||
where h is the block height on which the first commit of an
|
||||
output to the transaction was registered. If not all the inputs to
|
||||
the transaction were registered, then obviously no one can
|
||||
produce a proof of validity for any of the outputs. After that
|
||||
block height you cannot register any further outputs, but if you
|
||||
prove that after that block height no output of the transaction was
|
||||
registered, you can create a new unspent transaction output for
|
||||
each transaction input to the failed transaction which effectively
|
||||
rolls back the failed transaction. This time limit enables us to
|
||||
recover from failed transactions, and, perhaps, more importantly,
|
||||
enables us to clean up the mutable sql index that the immense
|
||||
chain of immutable sql indexes represents, and that the public
|
||||
broadcast channel contains. We eventually drop outputs that have
|
||||
been committed to a particular transaction, and can then
|
||||
eventually drop the commits of that output without risking
|
||||
orphaning valid outputs that have not yet been registered in the
|
||||
public broadcast channel.
|
||||
|
||||
## summarizing away useless old data
|
||||
|
||||
So that the public broadcast channel can eventually dump old
|
||||
blocks, and thus old spend events, every time we produce a new
|
||||
base level block containing new events (an sql index of new
|
||||
transaction outputs, and an sql index table with the same primary
|
||||
of spend commitments of past unspent transaction outputs to
|
||||
transactions) we also produce a consolidation block, a summary
|
||||
block that condenses two past blocks into one summary block,
|
||||
thus enabling the two past blocks that it summarizes to be dropped.
|
||||
|
||||
Immediately before forming a block of height $2n+1$, which is
|
||||
a block height whose binary representation ends in a one, we use
|
||||
the information in base level blocks $2n-3, 2n-2, 2n-1$,
|
||||
and $2n$ to produces a level one summary block that allows base
|
||||
level blocks $2n-3$ and $2n-2$, the two oldest remaining base
|
||||
level blocks to be dropped. When we form the block of height
|
||||
$2n+1$, it will have an edge to the block of height 2n, forming a
|
||||
chain, and an edge to the summary block summarizing blocks
|
||||
$2n-3$ and $2n-2$, forming a tree.
|
||||
|
||||
At every block height of $4n+2$. which is a block height whose
|
||||
binary representation ends in a one followed by a zero, we use the
|
||||
information in the level one summary blocks for heights
|
||||
$4n-5$, $4n-3$, $4n-1$, and $4n+1$, to produce a level two
|
||||
summary block that allows the level one summary blocks for
|
||||
$4n-5$ and $4n-3$, the two oldest remaining lever one
|
||||
summary blocks, to be dropped. The base level blocks are level zero.
|
||||
|
||||
At every block height of $8n+4$. which is a block height whose
|
||||
binary representation ends in a one followed by two zeroes, we
|
||||
use the information in the level two summary blocks for heights
|
||||
$8n-10$, $8n-6$, $8n-2$, and $8n+2$, to produce a level
|
||||
three summary block that allows the level two summary blocks
|
||||
for $8n-10$ and $8n-6$, the two oldest remaining level two
|
||||
summary blocks, to be dropped.
|
||||
|
||||
And similarly, for every block height of $2^{m+1}*n + 2^m$,
|
||||
every block height whose binary representation ends in a one
|
||||
followed by $m$ zeroes, we use the information in four level $m$
|
||||
summary blocks, the blocks $2^{m+1}*n + 2^{m-1}- 4*2^{m}$, $2^{m+1}*n + 2^{m-1}- 3*2^{m}$, $2^{m+1}*n + 2^{m-1}- 2*2^{m}$, and $2^{m+1}*n + 2^{m-1}- 1*2^{m}$ to produce an $m+1$ summary block that allows the two oldest remaining level $m$ summary blocks, the blocks $2^{m+1}*n + 2^{m-1}- 4*2^{m}$ and $2^{m+1}*n + 2^{m-1}- 3*2^{m}$ to be dropped.
|
||||
|
||||
We summarise the data in the earliest two blocks by discarding
|
||||
every transaction output that was, at the time those blocks were
|
||||
created, an unspent transaction output, but is now marked as used
|
||||
in any of the four blocks by committing it to a particular
|
||||
transaction. We discard commits which refer to outputs that have
|
||||
now been discarded by previous summary blocks and have timed
|
||||
out, which is to say, commits in a level m summary block being
|
||||
summarised into a level m+1 summary block that reference
|
||||
outputs in the immediately previous level m+1 summary block.
|
||||
However if, a commit references an output that is now in a
|
||||
summary block of level greater than m+1, that commit has to be
|
||||
kept around to prevent double spending of the previous output,
|
||||
which has not yet been summarised away.
|
||||
|
||||
We produce the summary block of past blocks just before we
|
||||
produce the base level block, and the base level block has an
|
||||
edge pointing to the previous base level block, a chain edge,
|
||||
and an edge pointing to the just created summary block a tree
|
||||
edge, a chain edge and a tree edge. And when we summarize two
|
||||
blocks into a higher level summary block, their chain and tree
|
||||
edges are discarded, because pointing to data that the reliable
|
||||
broadcast channel will no longer carry, and the newly created
|
||||
summary block gets a chain edge pointing to the previous summary
|
||||
block at the same level, and tree edge pointing to the previous higher level summary block.
|
||||
|
||||
We have to keep the tree around, because in order to register a
|
||||
commit for an output in the blockchain, we have to prove no
|
||||
previous commit for that output in any of the previous blocks in
|
||||
the tree, back to the block or summary block in which the output
|
||||
is registered. Only the client wallets of the parties to the
|
||||
transaction can produce a proof that a commit is valid if no
|
||||
previous commit, but only a peer can prove no previous commit.
|
||||
|
||||
So the peer, who may not necessarily be controlled by the same
|
||||
person as controls the wallet, will need to know the inputs to the
|
||||
transaction, and could sell that information to interested parties,
|
||||
who may not necessarily like the owner of the client wallet very
|
||||
much. But the peer will not know the value of the transaction
|
||||
inputs or outputs, nor the what the transaction is about.
|
||||
|
||||
Once all the necessary commits have been registered on the
|
||||
reliable broadcast channel, only the client wallets of the parties to
|
||||
the transaction can produce a proof for each of the outputs from
|
||||
that transaction that the transaction is valid. They do not need to
|
||||
publish on the reliable broadcast channel what transaction that
|
||||
was, and what the inputs to that transaction were.
|
||||
|
||||
So we end up with the blockchain only carrying order $\log(h)$
|
||||
blocks where $h$ is the block height, and all these blocks are likely
|
||||
to be of roughly comparable sizes to a single base level block.
|
||||
So, a blockchain with as many transactions as bitcoin, that has
|
||||
been running as long as bitcoin, will only occupy a few dozen
|
||||
megabytes of disk storage, rather than near a terabyte. Bitcoin
|
||||
height is currently near a hundred thousand, at which height we will
|
||||
be keeping about fifty blocks around, instead of a hundred thousand
|
||||
blocks around.
|
||||
|
||||
## Bigger than Visa
|
||||
|
||||
And when it gets so big that ordinary people cannot handle the
|
||||
bandwidth and storage, recursive snarks allow sharding the
|
||||
blockchain. You cannot shard the bitcoin blockchain, because a
|
||||
shard might lie, so every peer would have to evaluate every
|
||||
transaction of every shard. But with recursive snarks, a shard can
|
||||
prove it is not lying.
|
@ -1,25 +1,71 @@
|
||||
<!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>
|
||||
---
|
||||
title:
|
||||
Vision Statement
|
||||
sidebar: false
|
||||
notmine: false
|
||||
...
|
||||
|
||||
<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>
|
||||
Not only money secured by the blockchain, but pseudonymous identities with money and
|
||||
reputation secured by the blockchain.
|
||||
|
||||
Satoshi was after the money in the seignorage tax. There is also a lot of money in
|
||||
eBay and Amazon owning other people's reputations, a lot of money in the domain name
|
||||
system, and a lot of money in limited liability company name registration. eBay is
|
||||
entirely a search engine for the reputation data of people doing transactions and
|
||||
Amazon is largely such a search engine, and the primary asset value of most businesses is the goodwill accrued by their registered company name.
|
||||
|
||||
Our vision is a web 3.0 whose root of identity is not domain certificate authorities
|
||||
and registrars, but the master secrets of wallets. The seizure or blocking of domain
|
||||
names by authorities has become a big problem, as is Amazon and eBay casually
|
||||
mistreating and exploiting the people who rely on their reputation systems.
|
||||
|
||||
Satoshi's objective with Bitcoin was to allow people to transact over the internet
|
||||
without an intermediary that could reverse, freeze, or confiscate transactions.
|
||||
This has been accomplished, though we are hitting scaling problems hard,
|
||||
resulting in slow and expensive transactions.
|
||||
|
||||
We now, however, need a mechanism of communication and pseudonymous identity
|
||||
that can neither be censored, nor shilled and spammed into oblivion,
|
||||
where private pseudonymous communications can carry money, and can be revealed
|
||||
and proven by the parties to the transaction if they so choose subsequently,
|
||||
enabling pseudonymous identities to accrue reputation as with Amazon and eBay.
|
||||
And we want long accrued reputation to be also provable on the blockchain,
|
||||
and not confiscatable or poisonable by third parties
|
||||
like Amazon or eBay or the government.
|
||||
|
||||
At present the big weakness and privacy hole in crypto currency transactions is
|
||||
that the metadata about the transaction must go other some other channel,
|
||||
usually a channel that is insecure and far from private,
|
||||
and the agreement to exchange money for goods and services cannot be easily
|
||||
and provably linked to the payment. The linkage is made ad-hoc by some
|
||||
mechanism outside the blockchain. We need an uncensorable net,
|
||||
and we also need private communications that support secure transaction metadata
|
||||
that is testified to by a hash in the blockchain.
|
||||
|
||||
Our project is to provide the tools and protocols for cryptographically secure
|
||||
transactions and communications, such that identities are not rooted in a
|
||||
certificate authority, and such that the parties have a timestamp on the blockchain
|
||||
to the transaction metadata, a timestamp as to why the transaction and what it was
|
||||
about. To replace eBay and Amazon, we build a reputation system on top of that,
|
||||
and to replace limited liability name registration, bookkeeping, including book
|
||||
keeping for funds shared to a common purpose.
|
||||
|
||||
Suppose an identity solicits money from other identities for some common purpose.
|
||||
He then has to prove that he is spending it on this purpose. Which at present
|
||||
is done by the formation of a corporate identity subject to government oversight,
|
||||
which tends to oversee that you are hiring people of the right accreditation, race,
|
||||
sex, and sexual preference, rather than oversee that you are using the money for the
|
||||
intended purpose. We need to provide, not just reputations of buyers and sellers,
|
||||
but the means for trust in the collective use of funds. The corporate form is
|
||||
collapsing under a pile of government interventions intended to secure results
|
||||
that do not reflect the interests or desires of the corporation,
|
||||
which undermine the cohesion and unity of the corporation. The CEO lives in fear
|
||||
and terror of HR, legal, and accounting, because their powerbases are in the state,
|
||||
not in the corporation.
|
||||
|
||||
To make a start to resolve these problems, we implement the Zooko name
|
||||
system for encrypted private and signed public communications,
|
||||
and then a blockchain whose transactions contain within its timestamp
|
||||
of the hash of the communications about the transaction.
|
||||
We need a crypto currency that is inside of and on top of a secure system of
|
||||
communication and identity.
|
||||
|
8
docs/rootDocs/mkdocs.sh
Normal file
8
docs/rootDocs/mkdocs.sh
Normal file
@ -0,0 +1,8 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
echo `dirname $0`
|
||||
cd `dirname $0`
|
||||
docroot="../"
|
||||
templates=$docroot"pandoc_templates"
|
||||
destdir="../../"
|
||||
. $templates"/mkdocs.cfg"
|
7
docs/setup/mkdocs.sh
Normal file
7
docs/setup/mkdocs.sh
Normal file
@ -0,0 +1,7 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
echo `dirname $0`
|
||||
cd `dirname $0`
|
||||
docroot="../"
|
||||
templates=$docroot"pandoc_templates"
|
||||
. $templates"/mkdocs.cfg"
|
@ -74,7 +74,8 @@ To install guest additions on Debian:
|
||||
|
||||
```bash
|
||||
sudo -i
|
||||
apt-get -qy update && apt-get -qy install build-essential module-assistant git dnsutils curl sudo dialog rsync
|
||||
apt-get -qy update && apt-get -qy install build-essential module-assistant
|
||||
apt-get -qy install git dnsutils curl sudo dialog rsync zstd
|
||||
apt-get -qy full-upgrade
|
||||
m-a -qi prepare
|
||||
apt autoremove -qy
|
||||
@ -121,6 +122,10 @@ autologin-user-timeout=0
|
||||
nano /etc/default/grub
|
||||
```
|
||||
|
||||
The full configuration built by `grub2-mkconfig` is built from the file `/etc/default/grub`, the file `/etc/fstab`, and the files in `/etc/grub.d/`.
|
||||
|
||||
Among the generated files, the key file is `menu.cfg`, which will contain a boot entry for any additional disk containing a linux kernel that you have attached to the system. You might then be able to boot into that other linux, and recreate its configuration files within it.
|
||||
|
||||
### autostart preferred programs
|
||||
|
||||
To set things to autostart on gui login under Mate and KDE Plasma create
|
||||
|
@ -23,7 +23,9 @@ but SQLite3 style lacks a way to handle the enormous number of SQLite3
|
||||
documents, which can only be handled by a multi level bar, or by a page
|
||||
full of links
|
||||
|
||||
Libsodium, on the other hand, has a [left hand bar with drop downs](https://doc.libsodium.org/secret-key_cryptography){target="_blank"}. Which
|
||||
All major software has on all its pages a constant logo and text, which is not a waste of space for someone stumbling on it over the internet, a button bar for high level navigation, which is different on each child page, though only wxWidgets does the right thing with multiple layers of button bars, which get deeper as you drill down, and then below this horizontal element is the normal substance of a web page, which structure tends to be rather random and adhoc.
|
||||
|
||||
Libsodium, on the other hand, has the logo on top, but instead of a link bar, a [left hand bar with drop downs](https://doc.libsodium.org/secret-key_cryptography){target="_blank"}. Which
|
||||
is probably easier to implement, but that there is no documentation locally
|
||||
installed suggests that it too is in some way server generated. Apache2 and
|
||||
nginx similarly, and handle the enormous number of documents by
|
||||
@ -32,7 +34,7 @@ navigation at your fingertips.]
|
||||
|
||||
This layout is in some way automatically generated on the server, which
|
||||
sucks. Probably relies on server side include, which is the easiest way to
|
||||
do it.The documentation needs to be in every install and every repository.
|
||||
do it. The documentation needs to be in every install and every repository.
|
||||
Thus wxWidgets documentation on the server has nice organizational
|
||||
style, but on each person's individual installed copy, disorganized crap.
|
||||
|
||||
@ -136,7 +138,7 @@ katex, and in such cases, one should generate the html
|
||||
|
||||
```bash
|
||||
fn=filename
|
||||
pandoc --toc --eol=lf --wrap=preserve --from markdown+ascii_identifiers+smart --to html --metadata=lang:en --verbose --include-in-header=./pandoc_templates/header.pandoc --include-before-body=./pandoc_templates/before.pandoc --include-after-body=./pandoc_templates/after.Pandoc -o $fn.html $fn.md
|
||||
pandoc --toc --eol=lf --wrap=preserve --from markdown+ascii_identifiers+smart+raw_html+fenced_divs+bracketed_spans --to html --metadata=lang:en --verbose --include-in-header=./pandoc_templates/header.pandoc --include-before-body=./pandoc_templates/before.pandoc --include-after-body=./pandoc_templates/after.Pandoc -o $fn.html $fn.md
|
||||
```
|
||||
|
||||
Since markdown has no concept of a title, Pandoc expects to find the
|
||||
@ -354,10 +356,14 @@ assuming the actual image size is 479 pixels wide and 386 pixels high, 479 pixel
|
||||
The best way to do diagrams is svg and the Visual Studio Code
|
||||
scalable vector graphics extensions.
|
||||
|
||||
I decided to place the data directly inline in markdown because
|
||||
interfacing scalable vector graphics files (`svg` files) to html can get
|
||||
complicated, and interfacing the resulting complicated html to
|
||||
markdown can get more complicated.
|
||||
If you place the data directly in markdown, rather than in an svg file,
|
||||
the markdown is a lot more tolerant of errors than the browser when it
|
||||
includes an svg file, so it is very easy to create svg that displays fine,
|
||||
until you separate it into an svg file to be included as an ordinary
|
||||
image file, whereupon it fails to display in the browser.
|
||||
|
||||
Error checking in the markdown and in visual studio code svg editors
|
||||
fails to pick up all errors that will prevent an svg file from displaying.
|
||||
|
||||
Inkscape files are unreadable, and once they are cleaned up,
|
||||
Inkscape cannot read them. To (irreversibly) clean up an Inkscape
|
||||
|
Loading…
Reference in New Issue
Block a user