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

put in the machinery for a navbar, a navcolumn

Browse Source 
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:
reaction.la 2023-08-26 07:45:47 +10:00
parent e679bb5960
commit 8cfb02ee99
No known key found for this signature in database
GPG Key ID: 99914792148C8388
15 changed files with 655 additions and 323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/libraries/mkdocs.sh Normal file
View 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
View File

@ -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
View File

@ -0,0 +1,7 @@
#!/bin/bash
set -e
echo `dirname $0`
cd `dirname $0`
docroot="../"
templates=$docroot"pandoc_templates"
. $templates"/mkdocs.cfg"

90
docs/names/zookos_triangle.md
View File

@ -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
docs/pandoc_templates/after.pandoc
View File

@ -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
docs/pandoc_templates/before.pandoc
View File

@ -1 +0,0 @@
<p><a href="./index.html"> To Home page</a></p>

38
docs/pandoc_templates/mkdocs.cfg Normal file
View 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

79
docs/pandoc_templates/style.css
View File

@ -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%;
}

137
docs/program/Revelation.md
View File

@ -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
View 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.

94
docs/program/vision.md
View File

@ -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
View 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
View File

@ -0,0 +1,7 @@
#!/bin/bash
set -e
echo `dirname $0`
cd `dirname $0`
docroot="../"
templates=$docroot"pandoc_templates"
. $templates"/mkdocs.cfg"

7
docs/setup/set_up_build_environments.md
View File

@ -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

20
docs/writing_and_editing_documentation.md
View File

@ -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