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

Merge remote-tracking branch 'origin/docs'

Browse Source
This commit is contained in:
Cheng 2023-09-23 16:28:50 +10:00
commit 60eece9269
No known key found for this signature in database
GPG Key ID: 571C3A9C3B9E6FCA
82 changed files with 3402 additions and 903 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitconfig
View File

@ -6,8 +6,8 @@
whitespace = fix
ignoreWhitespace = no
[alias]
lg = log --max-count=6 --oneline --pretty='format:%C(auto)%h %d %Creset%p %C("#60A0FF")%cr %Cgreen %cn %G? %GT trust%Creset%n%s%n'
graph = log --max-count=18 --graph --pretty=format:'%C(auto)%h %s %Cgreen(%cr) %C(bold blue)%cn %G?%Creset' --abbrev-commit
lg = log --max-count=6 --pretty=format:'%C(auto)%h %d %Creset %p %C("#60A0FF")%cr %Cgreen %cn %G? %GT trust%Creset%n %<(78,trunc)%s%n'
graph = log --max-count=38 --graph --pretty=format:'%C(auto)%h %<(78,trunc)%s %Cgreen(%cr) %C(bold blue)%cn %G?%Creset' --abbrev-commit
alias = ! git config --get-regexp ^alias\\. | sed -e s/^alias\\.// -e s/\\ /\\ =\\ / | grep -v ^'alias ' | sort
[commit]
gpgSign = true

195
docs/May_scale_of_monetary_hardness.html
View File

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

25
docs/blockdag_consensus.md
View File

@ -3,13 +3,16 @@
title: Blockdag Consensus
...
Not ready for publication. "stake" is currently used in a different sense on blockchains, and this describes
a system in which wallets are peers and peers are wallets, which is a pretty bad idea.
# The problem
For the reasons discussed, proof of work is incapable of handling a very large number of transactions per second. To replace fiat money, we need a consensus algorithm capable of a thousand times greater consensus bandwidth. There are plenty of consensus algorithms that can handle much higher consensus bandwidth, but they do not scale to large numbers of peers. They are usually implemented with a fixed number of peers, usually three peers, perhaps five, all of which have high reliability connections to each other in a single data centre.
In a decentralized open entry peer to peer network, you are apt to get a very large number of peers, which keep unpredictably appearing and disappearing and frequently have unreliable and slow connections.
Existing proof of stake crypto currencies handle this by "staking" which is in practice under the rug centralization. They are not really a decentralized peer to peer network with open entry.
Existing proof of share crypto currencies handle this by "staking" which is in practice under the rug centralization. They are not really a decentralized peer to peer network with open entry.
## The solution outlined
@ -70,9 +73,7 @@ there is for a prong of a fork.
### Sampling the peers
So we have to sample the peers, or rather have each peer draw consensus
from the same representative sample. And then we implement something
similar to Paxos and Raft within that small sample. And sometimes peers
will disagree about which sample, resulting in a fork, which has to be resolved.
from the same representative sample.
For each peer that could be on the network, including those that have been
sleeping in a cold wallet for years, each peer keeps a running cumulative
@ -83,6 +84,16 @@ On each block of the chain, a peer’s rank is the bit position of the highest
bit of the running total that rolled over when its stake was added for that
block.
*edit note*
Here I propose making the weight in any block $2^rank$, but perhaps a better rule is that exclusive or of the previous and new value of the running total is the weight, which obviates the need for multiple peers to sign on to resolve draws.
And also I propose a running limit on the rank. A better solution is that in the event of deep fork, where several blocks differ between the two branches of the fork, you prefer the branch that has the greatest median weight on all the blocks that differ multiplied by the total weight, rather than the total weight. If there are an even number of blocks, he takes the average of the two median weights. There is a limit on the number of blocks permitted since the alleged time on the last identical block. However a block with great block weight is allowed to be produces faster than a block with little block weight, so a higher weight branch can also have more total blocks.
Which gives the same outcome, that on average and over time, the total weight will reflect the total weight of peers online and actively participating, and the total weight of a branch of a deep fork will reflect the total weight of the peers on that fork, so that in the event of a long network bisection, the group that has the most peers is likely to win when the bisection is fixed.
*end edit note*
So if Bob has a third of the stake of Carol, and $N$ is a rank that
corresponds to bit position higher than the stake of either of them, then
Bob gets to be rank $R$ or higher one third as often as Carol. But even if
@ -541,7 +552,7 @@ And bitcoin consensus is slow, because the way a fork is resolved is that
blocks that received one branch fork first continue to work on that branch,
while blocks that received the other branch first continue to work on that
branch, until one branch gets ahead of the other branch, whereupon the
leading branch spreads rapidly through the peers. With proof of stake, that
leading branch spreads rapidly through the peers. With proof of share, that
is not going work, one can lengthen a branch as fast as you please. Instead,
each branch has to be accompanied by evidence of the weight of stake of
peers on that branch. Which means the winning branch can start spreading
@ -676,7 +687,7 @@ We intend that peers will hold no valuable or lasting secrets, that all the
value and the power will be in client wallets, and the client wallets with
most of the value, who should have most of the power, will seldom be online.
I propose proof of stake. The stake of a peer is not the stake it owns, but
I propose proof of share. The stake of a peer is not the stake it owns, but
the stake that it has injected into the blockchain on behalf of its clients
and that its clients have not spent yet, or stake that some client wallet
somewhere has chosen to be represented by that peer. Likely only the
@ -726,4 +737,4 @@ and, when executed, cause a change in mutable total state, typically that
a new unspent coin record is added, and an old unspent coin record is
deleted.
A thousand times as expensive turns out to be quite economical.
A thousand times as expensive turns out to be quite economical.

2
docs/contracts_on_blockchain.md
View File

@ -145,7 +145,7 @@ flexibility is likely to bite people.
# Atomic Swaps on separate blockchains
A proof of stake currency is like a corporation, like shares in a
A proof of share currency is like a corporation, like shares in a
corporation.  So we are going to have many corporations, and individuals
will want to exchange shares in one corporation, with shares in
another.  We would like to do this without direct linking of

109
docs/crypto_currency_and_the_beast.html
View File

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

64
docs/crypto_currency_launch.html
View File

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

66
docs/crypto_currency_new_index.html
View File

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

69
docs/crypto_currency_on_wide_area_distributed.html
View File

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

2
docs/cypherpunk_program.html
View File

@ -172,4 +172,4 @@ a very small amount to accept messages from people not one one’s white
list. The fee would be refunded if one does not classify
the message as spam.</p>
</body></html>
</body></html>

2
docs/delegated_proof_of_stake.html
View File

@ -116,4 +116,4 @@ The hostile outside observer might well observe that an output from one transact
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>
</html>

2
docs/development_plan.html
View File

@ -93,4 +93,4 @@ And then we introduce an anonymized mix process in making that transfer, so that
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>
</html>

2
docs/generic_client_server_program.html
View File

@ -336,4 +336,4 @@ client threads and no prospect of getting new ones. 
<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>
</body></html>

2
docs/generic_test.html
View File

@ -339,4 +339,4 @@ client threads and no prospect of getting new ones.&nbsp;
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>
</body></html>

2
docs/how_browser_security_should_be_done.html
View File

@ -217,4 +217,4 @@ can result in changes to user records on the server.&nbsp;
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>
</body></html>

2
docs/how_to_do_VPNs.html
View File

@ -195,4 +195,4 @@ needed.&nbsp; </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>
</body></html>

BIN
docs/images/gpt_partitioned_linux_disk.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/images/msdos_linux_partition.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
docs/images/nobody_know_you_are_a_dog.webp
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.5 KiB

After

Width:  |  Height:  |  Size: 38 KiB

210
docs/immutable_append_only_data_structure.md Normal file
View File

@ -0,0 +1,210 @@
---
title:
Immutable Append Only Data Structure
# katex
...
The primary chain is a chain of hashes of merkle links, with for each link we have a zeek proving that the entire merkle tree, including data that only one person has, also including long lost or discarded data that no one has any more, is valid. And each block in that chain includes a bunch of hashes of transactions, each of which is the most recent link in a child chain. So the primary chain has a bunch of other chains hanging off it. Each proof proves that the latest block is valid, and that the peer that produced this proof verified the previous proof.
We want wallet chains hanging off the primary chain, and child chains. A wallet chain needs no consensus, for the latest transaction is valid if the machine that knows the wallet secret signs it. Child chains operating by consensus will also hang off it, when we implement corporations and traded shares on the blockchain. Each child chain can have its own rules defining the validity of the latest transaction in that chain. For a child chain operating by consensus, as for example the market in a corporation's shares, the rule will be that a peer can incorporate the transaction that represents a block ancestral to his current block into the parent chain when it has enough weight piled on top it by subsequent blocks, and that every peer in the child chain, when it sees a fork in the child chain by blocks with different incorporation in the forks of the parent chain, has to prefer the branch of the child fork that is incorporated by the branch of the parent fork with the greatest weight.
Each wallet will be a merkle chain,that links to the consensus chain and is linked by the consensus chain, and it consists of a linear chain of transactions each, with a sequence number, each of which commits a non dust amount to a transaction output owned by the wallet - which only owns one such output, because all outputs by other people have to be committed into the destination wallet in a reasonable time.
A wallet chain has a single authority, but we could also have chains hanging off it that represent the consensus of smaller groups, for example the shareholders of a company with their shares in a merkle child chain, and their own reliable broadcast channel.
The reliable broadcast channel has to keep the complete set of hashes of the most recent transaction outputs of a wallet that commits more than a dust amount of money to the continuing wallet state and keep the path to those states around forever, but with the merkle chain structure envisaged, the path to those states will only grow logarithmically.
I discarded the data on infix and postfix positioning of parents, and the tree depicted does not allow us to reach an arbitrary item from a leaf node, but the final additional merkle vertex produced along with each leaf node does reach every item. At the cost of including a third hash for backtracking in some of the merkle vertexes.
I think I should redraw this by drawing different kinds of vertexes differently, the binary with a two fanged arrow head, the trinary with a three fanged arrow head, and the blocks as blocks.
The blocks one color, the intermediate vertexes another, and final vertex defining a block the final color and larger.
<div style="width: 100%; height: auto; overflow: auto;">
<svg
xmlns="http://www.w3.org/2000/svg"
width="width: 100%" height="100%"
viewBox="0 0 100 60"
style="background-color:white">
<g stroke-width="2">
<path fill=#f00 stroke=#a00
d="
M10,22 c5,-5 15,-10 20,-10 c-5,0 -15,-5 -20,-10 q10,10 0,20 z
M50,22 c5,-5 15,-10 20,-10 c-5,0 -15,-5 -20,-10
q6,8 0,10 q6,2 0,10 z
M20,55 v-20 h36 c0,5 5,8 10,10 c-5,2 -10,5 -10,10 z
" />
</g>
</svg>
</div>
You really need a physical implementation that is a physically an append
only file of irregular sized merkle vertexes, plus a rule for finding the
physical location of the item hashed, plus a collection of quick lookup
files that contain only the upper vertexes. On the other hand, sqlite is
already written, so one might well want to think of implementing this as an
ever incrementing rowid, which we can get around to making into a physically
append only file another day. Stashing hashes of variable heights into a
single table with an ever incrementing rowid is the same problem as the
physical file, except that sqlite allows variable length records. (and does
that housekeeping for us.)
The data defined by hash is immutable but discardable.
One appends data by endlessly adding a new merkle vertex, which contains the hash of the previous vertex.
<svg
xmlns="http://www.w3.org/2000/svg"
width="30em" height="19.6em"
viewBox="0 170 214 140"
style="background-color:ivory"
stroke-width="1"
stroke-linecap="round" >
<g font-family="'Times New Roman'" font-size="10"
font-weight="400" fill-rule="evenodd" fill="black" >
<g id="blockchain_id" >
<ellipse cx="10" cy="240" fill="#0D0" rx="8" ry="5"/>
<text fill="black">
<tspan x="6" y="243.2">id</tspan>
</text>
</g>
<path stroke="#0D0" fill="none" d="
M9,236 c24,-36 55,-28 84,-28 s70,6 70,-9
M11,236 c30,-36 64,2 70,-14
M13,236 c20,-16 22,-6 22,0 c 0,3 0,6.3 2,6.3 q 2,0 3,-3.5
M14,237 c29,-14 4,12 2,15c -2,3 -1,6.5 1,6.5 q 2,0 3,-3.5
M15,238 c24,-10 -11,20.5 -11,28.5c -0,2 1,4 2,4 q 2,0 3,-4
"/>
<g id="balanced merkle tree" fill="none">
<path stroke="#F00" d="
M201,238 q 1,-4 4,-4 c6,0 -8,36.5 -2,36.5 q 2,0 3,-4
M164,200 c1,-4 10,-6 16,-6 c22,0 10,48 17,48 q 2,0 3,-3.5
M164,200 c2,-3 4,-4 10,-4 c22,0 -7,62 3,62 q 2,0 3,-3.5
M164,200 c2,-2 2,-2.3 6,-2.3 c16,0 -12,73 -4,73 q 2,0 3,-4
"/>
<g id="height_4_tree" >
<path stroke="#F00" d="
M82,221 c1,-4 6,-6 16,-6 c18,0 10, 27 16,27 q 2,0 3,-3
M82,221 c2,-3 2,-4 10,-4 c18,0 12, 41.5 18,41.5 q 2,0 3,-3.5
M82,221 c2,-2 2,-2.3 6,-2.3 c18,0 -14, 51.9 -5,51.9 q 2,0 3,-4
"/>
<path stroke="#000" d="
M81,222 c -4,-20 80,0 83,-22
c 3,6 -6,8 -6,22
"/>
<g id="height_3_tree">
<path stroke="#000" d="
M41,238 c 2,-14 39,-4 40,-16
c 3,4 -6,8 -6,16
"/>
<path stroke="#F00" d="
M42,237 c1,-1 1,-4 6,-4 c7,0 -4,25.5 3,25.5 q 2,0 3,-3.5
M42,237 c1,-1 2,-2.5 4,-2.5 c7,0 -14,36 -6,36 q 2,0 3,-4
"/>
<g id="height_2_tree">
<path stroke="#F00"
d="
M22,254 q 0,-4.5 3,-4.5 c5,0 -8,21 -3,21 q 2,0 3,-4
"/>
<path stroke="#000" d="
M21,254
c 2,-14 19,-4 20,-16
c 3,4 -4,8 -4,16
x "/>
<g id="height_1_tree">
<path stroke="#000"
d="
M10,266 c0,-10 10,1 11.5,-13
M16,266 c0,-6 4,0 5.5,-13
"/>
<g id="leaf_vertex" >
<g style="stroke:#000;">
<path id="path1024"
d="
M 10,265 L9,272
M 10,265 L11,272
">
</g>
<rect id="merkle_vertex" width="4" height="4" x="8" y="264" fill="#00F"/>
</g><!-- end id="leaf vertex" -->
<use transform="translate(6)" href="#leaf_vertex"/>
<use transform="translate(11 -12)" href="#merkle_vertex"/>
</g><!-- end id="height_1_tree" -->
<use transform="translate(16)" href="#height_1_tree"/>
<use transform="translate(31 -28)" href="#merkle_vertex"/>
</g><!-- end id="height_2_tree" -->
<g >
<use transform="translate(34)" href="#height_2_tree"/>
<use transform="translate(71 -44)" href="#merkle_vertex"/>
</g>
</g><!-- end id="height_3_tree" -->
<use transform="translate(77)" href="#height_3_tree"/>
<use transform="translate(154 -66)" href="#merkle_vertex"/>
<use transform="translate(160)" href="#height_2_tree"/>
<use transform="translate(197)" href="#leaf_vertex"/>
</g><!-- end id="height_4_tree" -->
</g> <!-- end id="balanced merkle tree" -->
<text y="168">
<tspan dy="12" x="6" >Immutable append only data structure
</tspan>
<tspan dy="12" x="6" >as a collection of balanced Merkle</tspan>
<tspan dy="12" x="6" >dags in postfix order</tspan>
</text>
<g id="merkle_chain">
<use transform="translate(0,60)" href="#blockchain_id"/>
<path
style="fill:none;stroke:#00D000;"
d="m 16,297 c 6,-14 9,16 14,0"/>
<g id="16_leaf_links">
<g id="8_leaf_links">
<g id="4_leaf_links">
<g id="2_leaf_links">
<g id="leaf_link">
<path
style="fill:none;stroke:#000;"
d="m 29,299 c 4,-6 4,-6 5.6,3 C 35,305 38,304 38.5,300"/>
<use transform="translate(20,33)" href="#leaf_vertex"/>
</g><!-- end id="leaf link" -->
<use transform="translate(10,0)"
href="#leaf_link"
/>
</g> <!-- end id="2 leaf links" -->
<use transform="translate(20,0)"
href="#2_leaf_links"
/>
</g> <!-- end id="4 leaf links" -->
<use transform="translate(40,0)"
href="#4_leaf_links"
/>
</g> <!-- end id="8 leaf links" -->
<use transform="translate(80,0)"
href="#8_leaf_links"
/>
</g> <!-- end id="16 leaf links" -->
<use transform="translate(160,0)"
href="#16_leaf_links"
/>
</g> <!-- end id="merkle chain" -->
<rect width="210" height=".4" x="8" y="276" fill="#000"/>
<text y="280">
<tspan dy="8" x="6" >Immutable append only data structure as</tspan>
<tspan dy="8" x="6" >a Merkle chain</tspan>
</text>
</g>
</svg>
Each merkle vertex is associated with a block number, a height, an infix position equal to the block number, plus the block number with the hight bits zeroed and a one bit appended, the infix position, plus the postfix position, which is twice the block number minus the number of one bits in the infix position.
Some of them are two hash groups, and some of them are three hash groups, the number of additional hashes, the number of three hash groups, is equal to the block number, so the position in a physical flat file is equal to the postfix position times the size of a two hash group, plus the block number times the size of the additional hash plus a fixed size region for the common essential fixed sized data of a variable length block. The physical file is a collection of physical files where the name of each file represents its offset in the conceptual very large ever growing index file of fixed sized records, and its offset into the conceptual ever growing file of variable length records, so that simple concantenation of the files generates a valid file.
From time to time we aggregate them into a smaller number of larger files, with a binary or roughly fibonacci size distribution. We do not want aggregation to happen too often with files that are too big, as this screws up standard backup systems, which treat them as fresh files, but on the other hand, do not want an outrageously large number of very tiny files, as standard backup for very large numbers of very tiny files is also apt to be costly, and mapping an offset into a very large number of very tiny files also costly, so a background process aggregating the files, and then checking them, then after check fixing the mapping to map into the new bigger files, then deleting the now unreferenced small files. The rule that each file has to be at least half of the remaining data gives us the binary distribution, while a gentler rule, say at least a quarter, gives us a larger number of files, but less churn.
Every time a fresh tiny file is created, a background process is started to check the files, starting with the tiniest to see if it is time for aggregation. Terminates when the largest aggregation is done.
So that files sort in the correct order, we name them in base 36, with a suffix indicating whether they are the fixed length index records, or the variable sized records that the fixed length records point into.
Although we should make the files friendly for conventional backup for the sake of cold storage, we cannot rely on conventional backup mechanisms, because we have to always have to have very latest state securely backed up before committing it into the blockchain. Which is best done by having a set of remote Sqlite files.

2
docs/index.md
View File

@ -1,7 +1,7 @@
---
title: How to Save the World
...
I have almost completed an enormous design document for an uncensorable social network intended to contain a non evil scalable proof of stake currency, and I have a wallet that can generate secrets, but the wallet is missing no end of critical features – it is pre-pre alpha. When it is early pre alpha, I am going to publish it on Gitea, and call for assistance.
I have almost completed an enormous design document for an uncensorable social network intended to contain a non evil scalable proof of share currency, and I have a wallet that can generate secrets, but the wallet is missing no end of critical features – it is pre-pre alpha. When it is early pre alpha, I am going to publish it on Gitea, and call for assistance.
Here is a link to one version of the [white paper](social_networking.html), focusing primarily on social media. (But though information wants to be free, programmers need to get paid.)

25
docs/libraries.md
View File

@ -2,6 +2,11 @@
title: Libraries
...
This discussion is way out of date because a rust recursive snark library
is now available, and making it public would impose a huge burden on me
of keeping it current and accurate, when events would render it continually
out of date.
# Wireguard, Tailwind, and identity
Wireguard is a secure vpn.
@ -445,7 +450,25 @@ environment without MSVC present.
choco install mingw pandoc git vscode gpg4win -y
```
That Cmake does not really work all that well with the MSVC environment. If we eventually take the CMake path, it will be after wc and build on MingGW, not before.
Cmake does not really work all that well with the MSVC environment.\
If we eventually take the CMake path, it will be after wc and build on
MingGW, not before.
## vscode
Vscode has taken the correct path, for one always winds up with a full
language and full program running the build from source, and they went
with javascript. Javascript is an unworkable language that falls apart on
any large complex program, but one can use typescript which compiles to javascript.
A full language is needed to govern the compile from source of a large
complex program - and none of the ad hoc languages have proven very useful.
So, I now belatedly conclude the correct path is to build everthing under vscode.
On the other hand, the central attribute of both the makefile language and
the cmake language is dependency scanning, and we shall have to see how
good vscode's toolset is at this big central job.
## The standard Linux installer

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"

6
docs/lightning_layer.md
View File

@ -407,13 +407,13 @@ to those snooping on other people’s business.
### Other use cases for a reliable broadcast channel
The use case of joint signatures implies an immutable data structure of the
tuple oid, hash, public key, and two scalars.
tuple rowid, hash, public key, and two scalars.
But another use case is to publicly root private immutable data.
If you continually upload the latest version, you wind up uploading most of
tree, or all of it, which does not add significantly to the cost of each
interaction recorded. The simplest sql friendly data structure is (oid of
interaction recorded. The simplest sql friendly data structure is (rowid of
this item, public key, hash, your index of hash, oids of two child hashes)
with the reliable broadcast channel checking that the child hashes do in fact
generate the hash, and that the tuple (public key, index of hash) is unique.
@ -425,7 +425,7 @@ inconsistent pasts for immutable append only data structure associated with
this key?
To work around this problem, allow unbalanced Merkle trees, consisting of
(oid of this item, public key, hash, your tree node index, index of the
(rowid of this item, public key, hash, your tree node index, index of the
highest index leaf governed by this hash, oids of two child hashes) If an
unbalanced node referencing an old tree root is uploaded at intervals of less
than three months, it can be used to prove the contents and uniqueness of

187
docs/manifesto/May_scale_of_monetary_hardness.md Normal file
View File

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

129
docs/manifesto/Revelation.md Normal file
View File

@ -0,0 +1,129 @@
---
lang: en
title: Book of Revelations Prophecy of the Beast
---
# Rhocoin and the Beast
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.
We also need one whose consensus protocol is more resistant to government leverage. Ethereum is alarmingly vulnerable to pressure from our enemies.
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.
Thus we need a pseudonymous, not an anonymous, crypto currency.
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.
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 problem that we face is awfully close to, and very similar to, the profoundly
oppressive technology of the Prophecy of the Beast. Networked money is a dual use
technology, that can be used by individuals to free themselves from centralized
control, and can be used and is being used by powerful centers to enforce centralized control.
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 favour of data concocted by Peer Review, which are priestly truths established by the priestly method of Holy Synods, of the demonic priesthood of the Beast. The scientific method is scientists saying they did things, and as a result saw things, while peer review is the official consensus about what what other people should have seen, regardless of what they actually saw. Consensus is the priestly method to truth, observation the scientific method. The priesthood of demons demand sacrifices, lest the wrath of their demons fall upon us, and the bigger the sacrifices, the more profit and power they get. Censorship of scientific data, has, like other forms of censorship, rendered people cynical. We need a mechanism for pseudonymous reputation that is resistant to hostile manipulation.
## The Prophecy of the Beast
Book of Revelation 13:16 The Beast with seven heads establishes a false, state enforced religion, which converges all other religions to it and:
> 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 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.
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.
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.
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.
[soft]: May_scale_of_monetary_hardness.html
{target="_blank"}
Crypto currency has the great advantage that you can use it to perform
transactions over distance and time, secured by the blockchain, and
rhocoin will enable allow instant in person on-the-spot
over-the-counter transactions, designed intended to be a complete replacement
for fiat money. (Though over the counter instant transactions require money that
remains [soft] for several minutes, but this is a big improvement over credit cards,
which remain [soft] for a few months, cheques that remain soft for days,
and wire transfers that remain [soft] for hours.)
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 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.
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.
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.
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 more than a 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 rhocoin design aims to ensure that when power gets concentrated, as with scaling it
inevitably will, it gets concentrated into peers controlled by whales 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. 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.

10
docs/crypto_currency.md → docs/manifesto/crypto_currency.md
View File

@ -2,19 +2,21 @@
title: Crypto currency
...
This discussion is obsoleted and outdated by the latest advances in recursive snarks.
The objective is to implement the blockchain in a way that scales to one hundred thousand transactions per second, so that it can replace the dollar, while being less centralized than bitcoin currently is, though not as decentralized as purists would like, and preserving privacy better than bitcoin now does, though not as well as Monaro does. It is a bitcoin with minor fixes to privacy and centralization, major fixes to client host trust, and major fixes to scaling.
The problem of bitcoin clients getting scammed by bitcoin peers will be fixed through Merkle-patricia, which is a a well known and already widely deployed fix – though people keep getting scammed due to lack of a planned bitcoin client-host architecture. Bitcoin was never designed to be client host, but it just tends to happen, usually in a way that quite unnecessarily violates privacy, client control, and client safety.
Monaro’s brilliant and ingenious cryptography makes scaling harder, and all mining based blockchains tend to the same centralization problem as afflicts bitcoin. Getting decisions quickly about a big pile of data necessarily involves a fair bit of centralization, but the Paxos proof of stake protocol means the center can move at the speed of light in fiber, and from time to time, will do so, sometimes to locations unknown and not easy to find. We cannot avoid having a center, but we can make the center ephemeral, and we can make it so that not everyone, or even all peers, know the network address of the processes holding the secrets that signed the most recent block.
Monaro’s brilliant and ingenious cryptography makes scaling harder, and all mining based blockchains tend to the same centralization problem as afflicts bitcoin. Getting decisions quickly about a big pile of data necessarily involves a fair bit of centralization, but the Paxos proof of share protocol means the center can move at the speed of light in fiber, and from time to time, will do so, sometimes to locations unknown and not easy to find. We cannot avoid having a center, but we can make the center ephemeral, and we can make it so that not everyone, or even all peers, know the network address of the processes holding the secrets that signed the most recent block.
Scaling accomplished by a client host hierarchy, where each host has many clients, and each host is a blockchain peer.
A hundred or so big peers, who do not trust each other, each manage a copy of the blockchain.
The latest block is signed by peers representing a majority of the stake, which is likely to be considerably less than a hundred or so peers.
The latest block is signed by peers representing a majority of the shares, which is likely to be considerably less than a hundred or so peers.
Peer stake is delegated from clients – probably a small minority of big clients – not all clients will delegate. Delegation makes privacy more complicated and leakier. Delegations will be infrequent – you can delegate the stake held by an offline cold wallet, whose secret lives in pencil on paper in a cardboard file in a safe, but a peer to which the stake was delegated has to have its secret on line.
Peer share is delegated from clients – probably a small minority of big clients – not all clients will delegate. Delegation makes privacy more complicated and leakier. Delegations will be infrequent – you can delegate the stake held by an offline cold wallet, whose secret lives in pencil on paper in a cardboard file in a safe, but a peer to which the stake was delegated has to have its secret on line.
Each peer’s copy of the blockchain is managed, within a rack on the premises of a peer, by a hundred or so shards. The shards trust each other, but that trust does not extend outside the rack, which is probably in a room with a lock on the door and a security camera watching the rack.
@ -46,7 +48,7 @@ those assets. Delegated power representing people, not so much.
In bitcoin, power is in the hands of a very small number of very large miners. This is a problem, both in concentration of power, which seems difficult to avoid if making decisions rapidly about very large amounts of data, and in that miner interests differ from stakeholder interests. Miners consume very large amounts of power, so have fixed locations vulnerable to state power. They have generally relocated to places outside the US hegemony, into the Chinese or Russian hegemonies, or the periphery of those hegemonies, but this is not a whole lot of security.
Proof of stake has the advantage that stake is ultimately knowledge of secret keys, and while the state could find the peers representing a majority of stake, they are more mobile than miners, and the state cannot easily find the clients that have delegated stake to one peer, and could easily delegate it to a different peer, the underlying secret likely being offline on pencil and paper in someone’s safe, and hard to figure out whose safe.
proof of share has the advantage that stake is ultimately knowledge of secret keys, and while the state could find the peers representing a majority of stake, they are more mobile than miners, and the state cannot easily find the clients that have delegated stake to one peer, and could easily delegate it to a different peer, the underlying secret likely being offline on pencil and paper in someone’s safe, and hard to figure out whose safe.
Obviously, at full scale we are always going to have immensely more clients than full peers, likely by a factor of hundreds of thousands, but we need to have enough peers, which means we need to reward peers for being peers, for providing the service of storing blockchain data, propagating transactions, verifying the blockchain, and making the data readily available, rather than for the current pointless bit crunching and waste of electricity employed by current mining.

33
docs/manifesto/crypto_currency_as_a_wide_area_distributed.md Normal file
View File

@ -0,0 +1,33 @@
---
lang: en
title: Crypto Currency as a wide area distributed database
---
::: myabstract
[abstract:]{.bigbold}
In [Scalable and private blockchain](scalability.html){target="_blank"} I note that the proposed blockchain structure maps directly to sql, and is often easiest to design if one thinks about it as if an sql database. Eventually we want everything in the world that relates to property ownership, contracts, agreements, financial relationships, and ongoing disputes, that Ann chooses to make accessible to Bob, accessible through sql code running on Bob's computer, and included in the pre-image of the blockchain root hash, so that Ann can prove to Bob that she is showing the same thing to Bob as to everyone else, and is not re-inventing the past, it is the same thing, or validly derived from, what she always showed.
:::
Much of this material is shamelessly plaigarized without [attribution.](http://docplayer.net/14501083-Blockchain-throughput-and-big-data-trent-mcconaghy.html)
Bitcoin has dangerously few miners, subject to dangerously few political authorities, and miner interests are insufficiently aligned to currency user interests.
[sovereign corporation]:social_networking.html#many-sovereign-corporations-on-the-blockchain
{target="_blank"}
The solution is to create a crypto currency that relies on weight of share, rather than weight of processing power.  Such a currency is equivalent to a [sovereign corporation], or rather the easily traded shares of a [sovereign corporation].  And independently of whether we need yet another crypto currency, we need sovereign corporations.
The blockchain is a database, as are modern Big Data NoSQL and NewSQL databases. They re all distributed. Distributing a database by making a full copy on every node scales extremely poorly. Distributed DBs need a consensus algorithm
We need a sharded [crypto currency](./crypto_currency.html{target="_blank"}), that can scale to arbitrary sizes.
Nakamoto consensus is a database that sacrifices consistency for availability.  Suppose Sam the Scammer double spends the same money to Alice and Bob:
Immediately afterwards the database might tell you that Sam has not spent the money, or that he has spent it on Alice, or that he has spent it on Bob, or that he spent it on Alice, and then attempted to spend it on Bob, but the attempted spend on Bob was disallowed, or that he spent it on Bob, and the attempted spend on Alice was disallowed.
After an unpredictably long time, it will eventually reach a consensus in favour of Bob, or in favour of Alice, but the consensus is unpredictable, the time required to reach consensus could be quite long, and you can never be entirely sure that you are looking at the final consensus.
[Recursive snarks]:scalability.html
{target="_blank"}
[Recursive snarks] allow sharding within a group where the nodes do not trust each other

42
docs/manifesto/crypto_currency_launch.md Normal file
View File

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

0
docs/crypto_currency_transaction_volume.html → docs/manifesto/crypto_currency_transaction_volume.html
View File

0
docs/cyperhpunk_manifesto.md → docs/manifesto/cypherpunk_manifesto.md
View File

0
docs/eric.jpg → docs/manifesto/eric.jpg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 184 KiB

After

Width:  |  Height:  |  Size: 184 KiB

41
docs/manifesto/mkdocs.sh Normal file
View File

@ -0,0 +1,41 @@
#!/bin/bash
set -e
cd `dirname $0`
docroot="../"
banner_height=banner_height:15ex
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
if [[ -z $targetDocroot ]]; then
targetDocroot=$docroot
fi
options=$osoptions"--toc --number-sections --toc-depth=5 --from markdown+smart+raw_html+fenced_divs+bracketed_spans --to html5 --wrap=preserve --metadata=lang:en --css=$targetDocroot"pandoc_templates/style.css" -Bnavbar -o"
for f in *
do
[[ -d $item && -x $item/mkdocs.sh ]] && $item/mkdocs.sh
if [[ $f =~ (.*)".md"$ ]];then
base=${BASH_REMATCH[1]}
if [[ $f -nt $destdir$base.html ]]; then
katex=""
line=""
for i in 1 2 3 4 5 6
do
read line
if [[ $line =~ katex ]];then
katex=" --katex="$docroot
fi
done <$f
pandoc --variable $banner_height --variable targetDocroot:$targetDocroot --template $docroot"pandoc_templates/pandoc.template" $katex $options $destdir$base.html $base.md
echo "$destdir$base.html from $f"
#else
# echo " $base.html up to date"
fi
fi
done

64
docs/manifesto/motivation.md Normal file
View File

@ -0,0 +1,64 @@
---
lang: en
title: Why we need a better crypto currency
---
::: myabstract
[abstract:]{.bigbold}
Why we need to build internet protocols that rest on
the consensus of the blockchain, rather than the authority
of giant organizations
:::
To secure a crypto currency against hostile forces, we
need to secure people's ability to hold conversations,
including conversations about payment, contracts, and
money, against hostile forces, so we need to replace
the domain name system and tcp-ip, and build an overlay
network inside and on top of that capable of hiding ip
addresses from the parties to the conversation.
(Though a conversation that hides IP addresses will
necessarily be slow and inefficient,
so not used routinely.)
Bitcoin and everything blockchain is a centralized ledger. Worse than that – it’s the One True Ledger. It isn’t like gold. Gold one can have directly on one’s person or indirectly in a vault somewhere.
It is possible to have a crypto currency similar to bitcoin where though there is one global ledger recording what public keys own what, there is no way to tell which human actors know the private keys corresponding to those public keys. Instead of public ledger of all transactions, [a database of private ledgers containing only hashes whose preimages are the private transactions](./scalability.html).
A crypto currency needs to be centerless – it needs to able to survive the seizure of key servers by a hostile powerful party. Trouble with bitcoin is that it is not centerless – proof of work winds up being centralized in a small number of extremely powerful and extremely expensive computers.
Thus we need a system with proof of share, and not only proof of share, but proof of client share – the power over the system needs to reside with peers that have a lot of wealthy clients – and it needs to be hard to find who the clients are, and where they are keeping their secrets, so that even if someone seizes important peers on charges of tax evasion and money laundering, does not thereby gain control.
If the system handles an enormous number of transactions, peers are going to be big and expensive, thus vulnerable to people armed with vague and open ended charges of tax evasion and money laundering. Hence the power of peer over the currency needs to be proportional to the wealth controlled by the secrets held by that peer’s clients. And that peer’s clients need to be free to move from one peer to the next, and apt to move to peers that make it difficult for Mueller to find their clients.
Need a crypto currency where Bob can prove to the whole world that he paid Ann such and such amount, in accord with such and such a bill, but no one else can prove he paid Ann, nor that there ever was such a bill, except he or Ann shows them. Bitcoin is far too traceable. We need controlled traceability, where the participants can prove a transaction to third parties and the world, but the world cannot. And Bob needs to be able to prove what the payment was about, that it was part of a conversation, a meeting of minds.
The reason we have end user demand for crypto currency is the same as the reason we have end user demand for gold.
When quasi governmental entities started freezing the accounts of "Nazis", "racists", "Russian trolls", and suchlike, a lot of "Nazis" and "Russian trolls" moved to crypto currency, shortly thereafter followed by a great many very wealthy men who were worried that when they needed their wealth in a hurry, they would suddenly become Nazis and Russian trolls also, and their wealth would suddenly become inaccessible or worthless.
For a long time the big demand for crypto currency has been wealthy Chinese evading currency controls, but with the recent crackdown on hate speech, we are seeing massive American and European demand, which directly resulted in the recent spike in crypto currency values.
Another substantial source of demand for crypto currency, which has been around since the beginning, is buying steroids and suchlike over the internet, but the really huge move in crypto currency demand came during the recent crackdown on political activists.
Obviously political activists do not in themselves have enough wealth to cause such a huge move in market value, but when you go after political activists, you are going to make a whole lot of wealthy people reflect that they are none too popular either. If you are a rich man, makes sense to put a significant chunk of your wealth in crypto currency in case you suddenly become a refugee. For example, if, as is looking increasingly likely, there is a pogrom against whites in the USA, a whole lot of rich people will flee to Singapore, China, Russia, Hong Kong, the Philippines, and Dubai with nothing but the clothes they stand up in, and the master secret controlling their crypto currency in their heads.
So that Bob can contract with Ann without the transaction becoming visible to the world, the crypto currency needs to be built inside and on top of an encrypted overlay network, a method for people to have forbidden conversations about forbidden things. Contracts imply conversations, and secret contracts imply secret conversations. Untraceable payments imply untraceable conversations.
Full bore totalitarianism sufficient to shut down crypto currency is not far from full bore totalitarianism sufficient to shut down the internet.
Full bore totalitarianism sufficient to shut down the internet is going to strangle your economy. If your enemies are markedly wealthier than you are, it is likely to be a problem. North Korea is poor in substantial part because it dares not allow something like the internet to exist. Any contact with the west is used by the state department as a vector for subversion and color revolution.
North Korea wants to open up, and has repeatedly attempted to open up, but wants it to be safe for it to open up. If it does open up, expect a lot of North Koreans to buy crypto currency.
To create an internet where I cannot send arbitrary packets to an arbitrary machine, you are going to have to license every hub that is allowed to accept packets. Expect some serious disputes as to who gets to do the licensing.
Turning the whole world into one big North Korea is not going to be feasible, and attempting to do so is likely to result in a large part of the world glowing in the dark.
However, turning the US into Venezuela is entirely feasible, might well happen. We have a potential Democratic Party president who proposes to do exactly that.
Which is exactly why wealthy Americans are buying crypto currency, so that they can run to those parts of the world that do not turn into North Korea or Venezuela.
The best example of repression which does not bother people too much is China, and the great firewall of China. And until recently, the major demand for crypto currency came from Chinese evading currency controls.
So, to accomplish the goal of shutting down crypto currency requires world wide internet repression at levels considerably more repressive than China, which is likely to be disruptive and damaging within a single nation and a single economy, and apt to lead to conflicts if attempted globally.

7
docs/manifesto/navbar Normal file
View File

@ -0,0 +1,7 @@
<div class="button-bar">
<a href="vision.html">vision</a>
<a href="scalability.html">scalability</a>
<a href="social_networking.html">social networking</a>
<a href="Revelation.html">revelation</a>
</div>

389
docs/manifesto/scalability.md Normal file
View File

@ -0,0 +1,389 @@
---
# katex
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 obviously 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 previous
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)
commit 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. The client creates a proof that this an output from a transaction with valid inputs, and his peer creates a proof that the peer verified the client's proof and that output being committed was not already committed to another different transaction, and registers the commitment on the blockchain. The output is now valid for that transaction, and not for any other, without the reliable broadcast channel containing any information about the transaction of which it is an output, nor the transaction of which it will become an input.
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, and the
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, has two edges, 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 hashes of 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 preimage of the hash, will not know the value of the transaction
inputs, nor what the transaction is about. It will
only know the hashes of the inputs, and does not even need to
know the hashes of the outputs, though if the client wallet
uses the same peer to register the change output, the peer will
probably be able to reliably guess that that output hash
comes from that transaction, and therefore from those inputs.
If Bob is paying Ann, neither Bob's peer nor Ann's peer knows
that Bob is paying Ann. If Bob is paying Ann, and gets a proof
his transaction is valid from his peer, and he registers his
change coin through his peer, and Ann registers her payment
coin through her peer, his peer has no idea what the hash of
that payment output was, and Ann's peer therefore has no way
of knowing where it came from.
Instead of obfuscating the data on public broadcast channel
with clever cryptography that wastes a a great deal of space,
as Monero does, we just do not make it public in the first place,
resulting in an immense reduction in the storage space required
for the blockchain, a very large reduction in the bandwidth,
and a very large reduction of the load on peers. They do not
have download and validate every single transaction, which
validation is quite costly, and more costly with Monero than Bitcoin.
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 carrying only $\bigcirc\ln(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.
### sidechaining
One method of sharding is sidechaining
Each transaction output contains a hash of the verification rule,
one of the requirements whereby one will prove that the output
was validly committed as an input to a transaction when the time
comes to commit it to a transaction. One always has to prove that
the transaction will not create money out of thin air, but one also
has to prove the transaction was done by valid authority, and the
output defines what is its valid authority. The normal and usual
verification rule is to prove that the party committing the output
knows a certain secret. But the verification rule could be anything,
thus enabling contracts on the blockchain,
and could instead be that a valid current state of the sidechain, which is a valid descendant of the state previously used in the previous similar transaction that created this output,
committed this output as an input to the new transaction -- in which case the output
represents the money on a sidechain, and the transaction moves money between the sidechain and mainchain.
This hash allows anyone to innovate some sidechain idea, or
some contract idea, without needing everyone else on the
blockchain to buy in first. The rest of the blockchain does not
have to know how to verify valid authority, does not need to
know the preimage of the hash of the method of verification, just
verify that the party committing did the correct verification,
whatever it was. Rather than showing the reliable broadcast
channel a snark for the verification of authority,
which other people might not be able to check, the party committing a
transaction shows it a recursive snark that shows that he verified
the verification of authority using the verification method
specified by the output. And what that method was, outsiders do
not need to know, reducing the burden of getting everyone
playing by the same complex rules. If a contract or a sidechain
looks indistinguishable from any other transaction, it not only
creates privacy and reduces the amount of data that other people
on the blockchain have to handle and know how to handle, it also
radically simplifies blockchain governance, bringing us closer to
the ideal of transactions over distance being governed by
mathematics, rather than men.

64
docs/social_networking.md → docs/manifesto/social_networking.md
View File

@ -2,28 +2,66 @@
# katex
title: >-
Social networking
sidebar: true
notmine: false
...
::: myabstract
[abstract:]{.bigbold}
Speech is suppressed by censorship, and on "free speech" platforms by state sponsored shill spam. Crypto currency transaction metadata goes over insecure networks, so we need a secure, uncensorable, and spam resistent Web 3.0 both for freedom of speech and economic freedom.
:::
# the crisis of censorship
If we have a mechanism capable of securely handling arbitrary free form
metadata about transactions, it can handle arbitrary free form information
about anything, and people are likely to use it for information the
government does not like. It is not only transaction data that the
government wants to control.
We have a crisis of censorship.
Every uncensored medium of public discussion is getting the treatment.
In a world where truth and reality is massively suppressed, forbidden truth
should migrate to a platform resistant to Global American Empire domination.
The Global American Empire is at war with truth and reality. A
communications platform should support truth and reality, thus must be at
war with the Global American Empire. A crypto currency needs what
Urbit was supposed to be, its own communications and publishing
protocol, in order that you can have transaction metadata protected, and
thus needs its own truth and reality system. And thus it needs to be willing
to be at war with the Global American Empire. Its developers need to
figure on a significant probability of being arrested, murdered or forced to
flee, as Satoshi figured, though their inability to think beyond next weeks
power point bullet points, and inability to comprehend the nature of
cryptographic protocols will likely protect us. On the other hand,
the recent arrests of people who created privacy software for Ethereum
suggests some risk. I would never have tried what Tornado tried,
for Ethereum is full of enemies who have longer time horizons
and better capability to understand what we are up to than most of them,
and Tornado was on the enemy's home turf. You can get away with that
stuff in the Bitcoin ecology so far, but no need to tread on the
enemy's toes unnecessarily. It draws unwelcome attention and forces
them to think.
We need a pseudonymous social network on which it is possible to safely
discuss forbidden topics.
## shills, spamming, and scamming
We also have a crisis of shills, spamming, and scamming.
[lengthy battleground report]:
images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp
../images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp
"anon report_from people who tried to keep unmoderated discussion viable"
{target="_blank"}
Here is a [lengthy battleground report] from some people who were on the front lines in that battle, and stuck it out a good deal longer than I did.
Here is a [lengthy battleground report] from some people who were on the
front lines in that battle, and stuck it out a good deal longer than I did.
So we need
moderation. But to prevent censorship, we need entirely decentralized
moderation.
So we need moderation.
But to prevent censorship, we need entirely decentralized moderation.
People escape censorship to unmoderated anonymous platforms, but are
driven off those platforms by shills, spammers, and scammers.
@ -264,6 +302,7 @@ of a million shills, scammers, and spammers.
So, you can navigate to whole world’s public conversation through
approved links and reply-to links – but not every spammer, scammer, and
shill in the world can fill your feed with garbage.
## Algorithm and data structure for Zooko name network address
For this to work, the underlying structure needs to be something based on
@ -351,7 +390,7 @@ power, and their failures rather too great consequences. But, following the
way that git is designed and in practice used, we do not have to give them
unlimited power, nor allow them to be a central point of failure.
### runningt in schism, with many approximately equal branches
### running in schism, with many approximately equal branches
Centralized databases are a single point of failure. They are also extremely
convenient, because they enable many humans to leverage the judgment of
@ -365,7 +404,7 @@ Under attack, the system may well schism, with no one source that lists all
or most Zooko identities that people are interested in contacting, but it
should, like Git, be designed to schism, and work well enough while
schismed. That is what makes Git centralization truly decentralized.
Sometimes, often, there is no one authoritative branch, and things still work.
Sometimes, often, there is no one authoritative branch, and things still work well enough.
The messages of the people you are following are likely to be in a
relatively small number of repositories, even if the total number of
@ -409,8 +448,7 @@ The metadata in the feed sharing reveals what network addresses are
following a feed, but the keys are derived from user identity keys by a one
way hash, so are not easily linked to who is posting in the feed.
### Replacing Kademlia
### Replacing Kademlia
[social distance metric]:recognizing_categories_and_instances.html#Kademlia
{target="_blank"}
@ -977,7 +1015,7 @@ focus on creating value and making profit.
[sox]:sox_accounting.html
"Sarbanes-Oxley accounting"
A proof of stake currency works like a startup company used to work
A proof of share currency works like a startup company used to work
before [SOX] -- the founders get shares, then they sell or issue shares to
angel investors, and then with the angel investors money they pay early
developers with both shares and fiat.
@ -1110,7 +1148,7 @@ liquidity event will be considerably more persuasive if the system actually
is useful as a censorship resistant social media platform at the time of the
liquidity event.
A proof of stake blockdag is a [sovereign] corporation, but in order to
A proof of share blockdag is a [sovereign] corporation, but in order to
actually function as a corporation it needs a human chief executive,
corporate funds that the the chief executive can dispense, a human board
of directors to keep an eye on what the chief executive is doing with those
@ -1119,7 +1157,7 @@ executive, and the shareholders keep an eye on the board.
So, after the first liquidity event (cross blockchain trades on the blockdag)
we implement the standard corporate infrastructure, accounting, board of
directors, CEO, over proof of stake instead of under a quasi governmental
directors, CEO, over proof of share instead of under a quasi governmental
stock exchange, [triple entry accounting] with immutable journal entries
instead of [sox] accounting, for the final liquidity event, the
final liquidity event being the first [sovereign] corporation on this
@ -1233,7 +1271,7 @@ of truckers who each owned their own truck. The coup was in large
## source of corporateness
State incorporated corporations derive their corporateness from the
authority of the sovereign, but a proof of stake currency derives its
authority of the sovereign, but a proof of share currency derives its
corporateness from the cryptographically discovered consensus that gives
each stakeholder incentive to go along with the cryptographically
discovered consensus because everyone else is going with the consensus,

0
docs/tim_may_on_bitcoin.md → docs/manifesto/tim_may_on_bitcoin.md
View File

71
docs/manifesto/vision.md Normal file
View File

@ -0,0 +1,71 @@
---
title:
Vision Statement
sidebar: false
notmine: false
...
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.

0
docs/what_is_to_be_done.html → docs/manifesto/what_is_to_be_done.html
View File

10
docs/white_paper.md → docs/manifesto/white_paper.md
View File

@ -241,11 +241,11 @@ the blockchain) far less traceable, because lightning transactions happen
off chain and inherently mingle coins, thus making crypto coins fully
fungible, thus increasing their desirability as a direct substitute for cash.
# proof of stake, Byzantine fault, and statehood
# proof of share, Byzantine fault, and statehood
A proof of stake currency is a corporation. Its currency is shares in that
A proof of share currency is a corporation. Its currency is shares in that
corporation. Corporations derive their corporateness from the authority
of the sovereign, but a proof of stake currency derives its corporateness from
of the sovereign, but a proof of share currency derives its corporateness from
each stakeholder (shareholder) playing by the rules because all the other
stakeholders play by those rules.
@ -312,7 +312,7 @@ mathematical facts about the nature of collective action.
[that sovereign corporation]:social_networking.html#many-sovereign-corporations-on-the-blockchain
A successful proof of stake currency would be a non state corporation,
A successful proof of share currency would be a non state corporation,
[a sovereign corporation]. What is a sovereign corporation but a state? The
power of the US is in substantial part that it is a world currency, albeit a
major reason why it is a world currency is airsea war superiority, and as its
@ -328,7 +328,7 @@ the CIA.) USG establishes the world’s narratives which control what
everyone cool across the world believes – that gay marriage is justice, for
example, or that “trans” people are a real thing and not just crazy and/or
sexually deviant, or that global warming is real, human-caused, and
disastrous, or that black lives matter. A proof of stake currency is not very
disastrous, or that black lives matter. A proof of share currency is not very
functional, unless, like the Jitsi blockchain, it provides a namespace and
service, because you need to interact with peers that have authority over
the consensus – the shareholders, or their computers, need to interact with

14
docs/white_paper_YarvinAppendix.md → docs/manifesto/white_paper_YarvinAppendix.md
View File

@ -2,6 +2,18 @@
title: >-
Bitzion: how Bitcoin becomes a state
...
This a publication by Moldbug. Full of good ideas, but it is a digression from
my focus, and like all Moldbug, unduly verbose. Core idea. Hodlers, not miners,
should have the power, and hodlers need a human board that represents them.
But representing this as forming a state is going get us killed. Safer to represent it
as forming a sovereign corporation.
#Moldbug
It probably won’t happen. It probably should.
Statelike nonstates fascinate all political engineers. Can a nonstate
@ -348,7 +360,7 @@ are shamelessly looted like Houston lifting the Nazi space program, many
have also innovated in governance. Scholarship asks us to start by
noticing their work; and we will start by following it.
While proof of work is one thing, proof of stake is a huge family of
While proof of work is one thing, proof of share is a huge family of
things. This family is united by one general principle. The general
principle of proof-of-stake is that the ledger belongs to its
owners—who must therefore be charged with governing it.

75
docs/merkle_patricia_dag.md
View File

@ -23,7 +23,7 @@ In a Merkle dag, vertices are data structures, and edges are hashes,
as if one followed a link by looking up the preimage of a hash.
Obviously this is seldom an efficient way of actually implementing a
edges, and one is in practice going to use a pointer or handle for
data structures in memory, and an oid for structures in a database,
data structures in memory, and an rowid for structures in a database,
but this is an internal representation. The canonical form has no
pointers, no oids and no handles, these are internal representations
of the structure defined and implied by the hashes, and in
@ -117,10 +117,9 @@ The resulting patricia tree with infix keys is:
<svg
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="29em" height="24em"
viewBox="0 -10 320 265"
style="background-color:#FF9" stroke-width="1.5"
style="background-color:#FFF" stroke-width="1.5"
stroke-linecap="round" >
<g font-family="'Times New Roman'" font-size="10" font-weight="400"
fill-rule="evenodd" fill="black" >
@ -131,14 +130,17 @@ The resulting patricia tree with infix keys is:
M 273,227 c20,-30 -60,-100 -57,-140
M 197,227 c12,-35 -52,-35 -44,-70
c 2,35 -38,35 -32,70" />
<g font-weight="800" fill=#FFF>
<g fill=#FFF>
<g id="link_bits" font-size="18">
<text>
<text font-weight="bold" fill=#FFF>
<tspan y="74" x="134">10</tspan>
<tspan y="134" x="228">0</tspan></text>
<text fill=#000>
<tspan y="74" x="134">10</tspan>
<tspan y="134" x="228">0</tspan></text>
</g>
</g>
<use font-weight="400" xlink:href="#link_bits"/>
<use font-weight="400" href="#link_bits"/>
<g id="rect">
<rect width="66" height="27" x="123" y="4" rx=5
fill="#0FF" />
@ -149,33 +151,33 @@ The resulting patricia tree with infix keys is:
<text y="2">
<tspan dy="12" x="172" >""</tspan>
<tspan dy="12" x="153" >4, false</tspan></text>
<use transform="translate(60 70)" xlink:href="#rect"/>
<use transform="translate(60 70)" href="#rect"/>
<text y="72">
<tspan dy="12" x="238" >1</tspan>
<tspan dy="12" x="215" >6, false</tspan></text>
<use transform="translate(-3 140)"
xlink:href="#rect"/>
href="#rect"/>
<text y="142">
<tspan dy="12" x="170" >10</tspan>
<tspan dy="12" x="152" >5, false</tspan></text>
<g transform="translate(-43 50)">
<use transform="translate(-68 160)"
xlink:href="#rect"/>
href="#rect"/>
<text y="162">
<tspan dy="12" x="98" >010</tspan>
<tspan dy="12" x="91" >2, true</tspan></text>
<use transform="translate(8 160)"
xlink:href="#rect"/>
href="#rect"/>
<text y="162">
<tspan dy="12" x="174" >100</tspan>
<tspan dy="12" x="167" >4, true</tspan></text>
<use transform="translate(84 160)"
xlink:href="#rect"/>
href="#rect"/>
<text y="162">
<tspan dy="12" x="250" >101</tspan>
<tspan dy="12" x="243" >5, true</tspan></text>
<use transform="translate(160 160)"
xlink:href="#rect"/>
href="#rect"/>
<text y="162">
<tspan dy="12" x="326" >110</tspan>
<tspan dy="12" x="319" >6, true</tspan></text>
@ -256,7 +258,6 @@ information from the peer that has the node with more children.
<svg
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="30em" height="19.6em"
viewBox="0 170 214 140"
style="background-color:ivory"
@ -329,21 +330,21 @@ x "/>
</g>
<rect id="merkle_vertex" width="4" height="4" x="8" y="264" fill="#00F"/>
</g><!-- end id="leaf vertex" -->
<use transform="translate(6)" xlink:href="#leaf_vertex"/>
<use transform="translate(11 -12)" xlink:href="#merkle_vertex"/>
<use transform="translate(6)" href="#leaf_vertex"/>
<use transform="translate(11 -12)" href="#merkle_vertex"/>
</g><!-- end id="height_1_tree" -->
<use transform="translate(16)" xlink:href="#height_1_tree"/>
<use transform="translate(31 -28)" xlink:href="#merkle_vertex"/>
<use transform="translate(16)" href="#height_1_tree"/>
<use transform="translate(31 -28)" href="#merkle_vertex"/>
</g><!-- end id="height_2_tree" -->
<g >
<use transform="translate(34)" xlink:href="#height_2_tree"/>
<use transform="translate(71 -44)" xlink:href="#merkle_vertex"/>
<use transform="translate(34)" href="#height_2_tree"/>
<use transform="translate(71 -44)" href="#merkle_vertex"/>
</g>
</g><!-- end id="height_3_tree" -->
<use transform="translate(77)" xlink:href="#height_3_tree"/>
<use transform="translate(154 -66)" xlink:href="#merkle_vertex"/>
<use transform="translate(160)" xlink:href="#height_2_tree"/>
<use transform="translate(197)" xlink:href="#leaf_vertex"/>
<use transform="translate(77)" href="#height_3_tree"/>
<use transform="translate(154 -66)" href="#merkle_vertex"/>
<use transform="translate(160)" href="#height_2_tree"/>
<use transform="translate(197)" href="#leaf_vertex"/>
</g><!-- end id="height_4_tree" -->
</g> <!-- end id="balanced merkle tree" -->
<text y="168">
@ -352,7 +353,7 @@ x "/>
<tspan dy="12" x="6" >in postfix order</tspan>
</text>
<g id="merkle_chain">
<use transform="translate(0,60)" xlink:href="#blockchain_id"/>
<use transform="translate(0,60)" href="#blockchain_id"/>
<path
style="fill:none;stroke:#00D000;"
d="m 16,297 c 6,-14 9,16 14,0"/>
@ -364,26 +365,26 @@ x "/>
<path
style="fill:none;stroke:#000;"
d="m 29,299 c 4,-6 4,-6 5.6,3 C 35,305 38,304 38.5,300"/>
<use transform="translate(20,33)" xlink:href="#leaf_vertex"/>
<use transform="translate(20,33)" href="#leaf_vertex"/>
</g><!-- end id="leaf link" -->
<use transform="translate(10,0)"
xlink:href="#leaf_link"
href="#leaf_link"
/>
</g> <!-- end id="2 leaf links" -->
<use transform="translate(20,0)"
xlink:href="#2_leaf_links"
href="#2_leaf_links"
/>
</g> <!-- end id="4 leaf links" -->
<use transform="translate(40,0)"
xlink:href="#4_leaf_links"
href="#4_leaf_links"
/>
</g> <!-- end id="8 leaf links" -->
<use transform="translate(80,0)"
xlink:href="#8_leaf_links"
href="#8_leaf_links"
/>
</g> <!-- end id="16 leaf links" -->
<use transform="translate(160,0)"
xlink:href="#16_leaf_links"
href="#16_leaf_links"
/>
</g> <!-- end id="merkle chain" -->
<rect width="210" height=".4" x="8" y="276" fill="#000"/>
@ -399,7 +400,7 @@ valid, you have an enormous number of small proofs that each
particular part of the blockchain is valid. This has three
advantages over the chain structure.
1. A huge problem with proof of stake is "nothing at stake".
1. A huge problem with proof of share is "nothing at stake".
There is nothing stopping the peers from pulling a whole
new history out of their pocket.\
With this data structure, there is something stopping them. They
@ -426,9 +427,7 @@ advantages over the chain structure.
peer is generally accepted.
This is not a Merkle-patricia tree. This is a generalization of a Merkle
patricia dag to support immutability.
The intended usage is an immutable append only dag.
patricia dag to support immutability..
In a binary patricia tree each vertex has two links to other vertices,
one of which corresponds to appending a $0$ bit to the bitstring that
@ -504,8 +503,8 @@ immutable, that the past consensus has not been changed
underneath us, so, regardless of how the data is actually physically
stored on disk, these belong in differnt sql tables.
So, the oid of a vertex that has a full field width sized bitstring is
simply that bitstring, while the oid of its parent vertices is obtained
So, the rowid of a vertex that has a full field width sized bitstring is
simply that bitstring, while the rowid of its parent vertices is obtained
by appending $1$ bits to pad the bitstring out to full field width, and
subtracting a count of the number of $1$ bits in the original bitstring,
`std::popcount`, which gives us sequential and ever increasing oids
@ -554,7 +553,7 @@ graph, each block being a tree representing the state of the system at
that block commitment, but that tree points back into previous block
commitments for those parts of the state of the system that have not
changed. So the hash of the node in such a tree will identify, probably
through an OID, a record of the block it was a originally constructed
through an rowid, a record of the block it was a originally constructed
for, and its index in that tree.
A Merkle-patricia directed acyclic graph, Merkle-patricia dac, is a
@ -629,7 +628,7 @@ If we represented the bitstring that corresponds to the block
number, the block height, has having a large number of leading
zero bits, so that it corresponds to a sixty three bit integer (we need
the additional low order bit for operations translating the bitstring
to its representation as a key field or oid field) a fixed field of sixty
to its representation as a key field or rowid field) a fixed field of sixty
four bits will do us fine for a trillion years or so.
But I have an aesthetic objection to representing things that are not

137
docs/mkdocs.sh
View File

@ -1,134 +1,11 @@
#!/bin/bash
set -e
cd `dirname $0`
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"
#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 --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 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 --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 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
echo `dirname $0`
for item in *; do
[[ -d $item && -f $item/mkdocs.sh ]] && $item/mkdocs.sh
done
echo all subdirectories done
docroot="./"
templates=$docroot"pandoc_templates"
. $templates"/mkdocs.cfg"

0
docs/PracticalLargeScaleDistributedKeyGeneration.pdf → docs/names/PracticalLargeScaleDistributedKeyGeneration.pdf
View File

0
docs/SecureDistributedKeyGeneration.pdf → docs/names/SecureDistributedKeyGeneration.pdf
View File

BIN
docs/names/analyzing_social_graph.pdf Normal file
View File

Binary file not shown.

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"

0
docs/multischnorr-20151012.pdf → docs/names/multischnorr-20151012.pdf
View File

18
docs/names/multisignature.md
View File

@ -218,15 +218,15 @@ do not get all of it, they can calculate the signature.
# Threshold Signatures
FROST is an algorithm that produces a regular schnorr signature, and allows
a quite large number of unequal shares.
A threshold signature has the interesting feature that it is a randomness
beacon. If there is one honest participant party to the signing it generates a
random value unpredictable to all participants, This has obvious utility in
selecting the witness set and leader in blockdag algorithms equivalent to
Practical Byzantine Fault Tolerant Consensus, and in distributing discrete
shares in a way that is fair and on average over time approximates
continuous stake as closely as possible
random value unpredictable to all participants
The participants sign off on assertion that their stake is such and such, and
One application: The participants sign off on assertion that their share is such and such, and
the signature itself controls the random distribution of fractional voting
shares in the next signature as whole shares, so that voting shares, as
nearly as possible, approximate ownership shares.
@ -243,6 +243,10 @@ clean, simple, and easy to understand.
[FROST algorithm for Schnorr distributed key generation and signing]:https://suredbits.com/schnorr-applications-frost/
"Schnorr Applications: FROST"
[FROST with unequal shares]:https://github.com/Trust-Machines/frost
Source code for [FROST with unequal shares] is available on github, implemented for the bitcoin elliptic curve.
Each of the participants acts as the trusted dealer for his own share, hands
out shares in it to everyone else, and the final key is the sum of everyone's
share.
@ -359,7 +363,7 @@ maintained by a single host, albeit a notarization will not be evidence usable
on the blockchain until its notary block is Merkle chained by the blockchain.
If the blockchain automatically trusts notary signatures, they will rapidly
cease to be trustworthy. The chain, not the signature, makes it officially
official. The notary signature and oid is merely a promise to make it
official. The notary signature and rowid is merely a promise to make it
official. The blockchain will treat notaries as untrusted, so that everyone
else can treat them as trusted at low risk.

4
docs/names/names.md
View File

@ -147,9 +147,9 @@ cryptographic identifiers, which is a pain. We would like to be able to send
and receive money without relying on identifiers that look like line noise.
So we need a system similar to namecoin, but namecoin relies on proof of
work, rather than proof of stake, and the state’s computers can easily mount
work, rather than proof of share, and the state’s computers can easily mount
a fifty one percent attack on proof of work. We need a namecoin like system
but based on proof of stake, rather than proof of work, so that for the state
but based on proof of share, rather than proof of work, so that for the state
to take it over, it would need to pay off fifty one percent of the
stakeholders – and thus pay off the people who are hiding behind the name
system to perform untraceable crypto currency transactions and to speak the

956
docs/names/petnames.md Normal file
View File

@ -0,0 +1,956 @@
---
title: An Introduction to Petname Systems
# notmine
---
::: {style="text-align: center;"}
by
Marc Stiegler, Feb 2005, copyright under the MIT X License\
updated June 2010\
:::
# Abstract
Zooko's Triangle \[Zooko\] argues
that names cannot be global, secure, and memorable, all at the same
time. Domain names are an example: they are global, and memorable, but
as the rapid rise of phishing demonstrates, they are not secure.
Though no single name can have
all three properties, the *petname*
*system*
does indeed embody all three properties. Informal
experiments with petname-like systems suggest that petnames can be both
intuitive and effective. Experimental implementations already exist for
simple
extensions to existing browsers that could alleviate (possibly
dramatically) the problems with phishing. As phishers gain
sophistication, it seems compelling to experiment with petname systems
as part of the solution.
# Basic Petname Layout
Below, we have Zooko's Triangle
overlaid with a petname system:
![](./zooko-triangle.gif)
For the purposes of this document, we actually use an
alternate rendering of the key points of Zooko's Triangle.  The
points
of the triangle are:
- Memorable: this means
that  a human being has a chance of
remembering the name. Memorable names pass the "moving bus test": if
you see the name on the side of a bus as it drives past you, you should
be able to remember the name long enough to use it when you get home.
- Global: this means the name
is publicly available, and indeed the entity to whom the name is
attached is eager to give it to you. A key goal of marketing and
advertising is to capture memorable names in such a fashion that the
memorable name is globally locked to a particular entity.
- Securely Unique: This is
means that the name cannot be *forged*
or *mimicked*.
A name can be forged
if one can
manufacture an exact duplicate of the name such that neither man nor
machine can tell the difference. A name can be mimicked
if
one can make a name similar enough to fool the human being. In general,
phishing depends on mimicry, not forgery. This difference becomes
crucial later in the discussion.
Each name set consists of three
elements: a *key*
that is global and securely unique (but not necessarily memorable); a *nickname*
that is global and memorable (but not at all unique) , and a *petname*
that is securely unique and memorable (but private, not global):
- **Keys** lie at the heart of the security properties
of the petname system. Nicknames and petnames exist to make it easy for
human beings to manipulate keys. The security of the
system can be no stronger than the unforgeability of the keys.
Self-authenticating public/private key pairs make excellent keys since
they have strong
unforgeability properties. But there are other ways of achieving
unforgeability. A trusted path can also work well as the key: the full
pathname to a file on a specific computer is
also unforgeable (or at least, as unforgeable as the designation of the
specific computer, which can be quite strong in some cases). It does
not make any difference in a petname system whether a key can be
mimicked: keys are handled only by the computer, the human being
handles the keys only indirectly via petnames. For a particular person,
for a particular application, there is a
one-to-one mapping between a key and a petname.
- **Nicknames**
can be used to assist in discovery of
keys, and for help in selecting a petname. Nicknames are chosen by the
owners of  keys in hopes of creating a distinctive, if not
unique,
mapping from the memorable nickname to the key. Such nicknames often
are promulgated throughout the world in
the hopes of making the nickname stick in the mind as a reference to
the
key. Since there are strong incentives to "take ownership" of a
nickname, even though true ownership is not possible, nicknames are the
most often misunderstood part of a petname system.
In the simple case, a nickname has a one-to-many mapping to
keys The name John Smith is obviously a
nickname: there are many John Smiths.Other nicknames
produce the illusion of being globally unique: the name Marc Stiegler
appears to be globally unique at the time of this writing. But there is
no security property in this accident of global uniqueness. The
uniqueness of the name Marc Stiegler would change quite quickly if,
through the
mysterious forces of human whimsy, the name suddenly became desirable.
Sometimes the desirability of a nickname is not whimsical, but venal.
It is already desirable for some applications to call
themselves
Quicken, for example, and draw windows that request a Quicken password.
- **Petnames**
are our private bidirectional
references to keys.
There are many Mark Millers, but there is one specific Mark Miller that
the
name means to me, the Mark Miller who
works with object-capabilities for secure cooperation. "Mark Miller" is
Mark Miller's nickname; it also
happens to be my petname for the same individual. My private pet name
for my wife is not recognizably similar to the public nickname used by
my wife. In the computer setting, for a specific person with a specific
application, petnames are unique, each petname refers to exactly one
key, and each key is represented by exactly one petname. In all places
in
the application where the app wants to designate the key, the petname
is displayed -- which is to say, *a
true petname is a bidirectional one-to-one mapping to a key*.
All references to the key by the user interface are represented by
petname.
A key cannot have two petnames; if a single key had two petnames, under
what circumstances would the user interface use petname1 as the
representation of the key, and under what circumstances would it bring
up petname2?
## More Detail, and Interactions
A good example of a nickname management system is Google. Type
in a name, and Google will return a list that includes all the entities
Google knows, to which the name refers. Google
makes a mapping between these nicknames and their keys (if we think
of the url of a page as a trusted-path-style key, which will be
discussed later). Often
enough to be interesting, the first item in the list will be the one
you wanted. But it fails often enough, and endless pages of other
choices appear often enough, to never leave us in doubt that these
identifiers
are not unique mappings to single keys. As is already true in the
current world, in a world filled with petname
systems, a key goal of marketing would be to get your nickname listed
at the top of the Google rankings for that nickname.
A single key may map to multiple nicknames. The entity that comes up
first in a Google search for "Marc Stiegler" is an entity who proposes
the
nickname "marcs" for himself in many forums. However, to assess the
security
properties of a petname system, this is irrelevant.
Nicknames are conveniences that may serve as good starting points
for petnames. If I send
you my key and my nickname, often my nickname (which I normally will
have chosen to
be reasonably rare in the world) will work great as your petname. But
do not confuse the nickname-as-proposal with the
petname-as-decided. Never in a true petname system is
the nickname presented or employed as if it were a petname.
*Alleged names*
are similar enough to nicknames to be worth
distinguishing. An alleged name is the name for an entity proposed by a
third party, typically in an introduction. This can also be useful as a
starting place for picking a petname. Alleged names, like nicknames,
are usually memorable, often global, and never securely unique. Alleged
names are often based on nicknames, though this is unreliable enough,
if one really cares about the nickname then one really needs to ask the
entity holding the key, not the introducer.
In action, keys and alleged names
tend to be transferred together. We
refer henceforth to such key/alleged-name pairs as *referrals.*
It is crucial not to confuse
private petnames with global nicknames
that temporarily happen to have a unique mapping to a key.
Experience to date suggests that the word "petname" is attractive,
leading people to desire to use it. People can thence easily fall into
the trap of referring to momentarily
unique nicknames as "petnames". This error then leads them inevitably
to draw fatally confused conclusions about the possibility of petnames
with global meaning. The security properties of a petname come from its
privacy. Public nicknames are trivially vulnerable to
both forgery and mimicry; they have no security properties.
Petnames are guessable. Most people will accept Paypal's nickname as
the petname. This can only impact the security of the
system if the user interface
distinguishes the petnames from the nicknames so poorly that the user gets confused.
The term "petname" suggests that this name is embodied as text. This
is
not necessary; petnames can be graphical as well. Indeed, some of the
petname systems listed later use petnames that include both *pet
texts* and *pet graphics.*
Petnames must be repeatably editable by the human being so that the set
of petnames can evolve as the user's set of associations
grow.
You might use the petname "Mark Miller" for the one and only Mark
Miller that you know. But then if you meet another Mark Miller you will
have to distinguish, possibly by editing the first one: the single
entry "Mark Miller" may now split into "Mark Miller Capability Guru"
and "Mark Miller Dentist".
Petnames convey power: since the petname is the user representation
of the key, it is through the petname that the human
being
uses the key, communicates with the key owner, and conveys authority to
the key owner based on the user's *purposeful
trust*
relationship with that owner (*purposeful
trust* is the type of
trust
needed to engage in action: I trust (i.e., I am willing to be
vulnerable to) Entity X to hold N number of
dollars on my behalf, and to engage in transfers of that money based on
orders I give).
Another way of thinking about the relationship between a key and a
petname is this. The key is used to authenticate the entity that owns
the key. The petname is used as a handle upon which to hang the
trust/reliance/vulnerability data used by the human being to make
authorization decisions for that entity. If the entity represented by
the petname My Phone Company asks for my credit card, if the
justification sounds reasonable, I will release it. If the entity
represented by the petname Deadbeat Brother (whom I nonetheless trust
to teach my daughter soccer in the afternoon without supervision -- the
trust relationship with such a brother is neither positive nor
negative, it is complex) asks for my credit card, I will not release it
no matter what the justification.*\
*
*The security
of a petname system depends on the
keys to
prevent forgery, and on the petnames to prevent mimicry.*
# Petnames In Action
Informal
experimentation suggests that a petname system is
much easier to use than to explain (see examples below). We will create
a single example for this introduction, and give some hint as to the
wide diversity of variations in the Examples. Suppose I send you Mark
Miller's OpenPGP pubkey in email. I say, "here is mark miller's
pubkey."
I sent you both a key  and an alleged
name
(mark miller). Implicit in the transmission of the alleged name is the
proposal that you might want to consider "mark miller" as the petname.
What you actually choose as a petname depends entirely on your context.
If you know this particular mark miller in other contexts in other
applications as "markm", you may choose "markm" as the name referring
to this key in your list of pubkeys. If you think this might be
the same mark miller, but are not willing to be vulnerable to me as the
sole source of such
powerful mapping, you might use the petname "Marc Stiegler's Mark
Miller" or "Mark Stiegler's markm". If you perform appropriate
incantations on the pubkey, you can get the entity's nickname. If this
pubkey already exists
in your list, your software shouldn't give you the choice of adding it:
the software should tell you that you already have this one, and tell
you the current petname (and perhaps bring up the petname editor so you
can change the petname if the newly-received reference suggests a
better name). If you receive a message signed with the private key for
the markm petname's pubkey, the software should display the
petname markm. If you send a
message to mark miller, you should pick the
encryption key based on the petname.
The above example has the
security properties of a petname system, but OpenPGP systems often do
not demonstrate the  usability properties a petname system
needs.
Instant messaging systems with buddy lists demonstrate the usability
properties, but for reasons beyond the understanding of this author,
discard all the security properties. See the examples section for more
details on buddy lists as petname systems.\
# Key Issues with Petname Systems
Two elements of full-fledged
petname systems seem to be principle
sources of controversy. One is, how do I get the keys transferred
around the system? The other is, "how easily can Darth Vader mimic a
petname?".
## Transferring Keys and Purposeful Trust
Transferring keys around the universe is easy; for example, plaster the
keys on all the web sites in the world that'll let you do so. The hard
part is transferring a key with an association to purposeful trust. It
is useless to both PayPal and the phisher who wants your Paypal account
if you just know Paypal's key; you have to be willing to make yourself
vulnerable to the entity who
owns the key to hold your credit card, trusting him to engage in only
transfers that you specify.
The question, "how do I
transfer a purposeful
trust association?", is hard to
answer because there is no simple single answer. Instead, there are a
vast array of
answers, each of which works in narrow circumstances. The question
is made
even more difficult to answer because the mechanisms by which humans
determine an appropriate purposeful trust to be associated with an
entity
is subtle, complex, powerful, and completely subconscious: the
question of how you transfer the association can easily slide into a
hopeless discussion of how to create purposeful trust in the first
place. Here we outline some general ideas for transferring
key/purposeful-trust
mappings, then in the
Examples
point out some practical approaches in specific narrow contexts.
Answers often start with direct
physical contact. You get a combination of
a nickname and a key in a file from your best friend, who says, "this
Google thing is a great search engine", or "this Consumer Reports site
will not lead you astray". You stick these referrals in your browser,
assign petnames,
and make yourself vulnerable to them for the purposes stated because
your friend said so.
Then when the side of the bus says PayPal, you might go and see what
Google thinks Paypal means. Since a relationship with PayPal is a
serious vulnerability decision, serious enough so that we're not going
to jump
at the first site just because Google said so, we'll ask a few of our
friends to email referrals to the entities they use for online money.
If the referrals they send all share the same key as the Google
key (which is easy to tell, because trying to add each new key/petname
mapping will
produce the alert that the key matches something you've already got),
the
quality of your willingness to be vulnerable to the key you have
petnamed PayPal improves.
This is pretty similar to how
we all started using PayPal even without the petname system: we jumped
in when enough of our friends and organizations that we trust for
recommendations about financial matters concurred. The only difference
in the petname version of the story is that our friends explicitly gave
us referrals rather than easily mimicked domain names, and we
explicitly set a petname (perhaps by just clicking an Accept key when
the alleged name was proposed as the petname).
While a full-fledged, purebred
petname system could in principle
supplant the entire DNS system, we have DNS now, and we can use it to
do some bootstrapping.  My ability to type google.com and
paypal.com is probably adequate to get started.
Regardless of how you
bootstrap, you
can get referrals by email, thumbdrive, web page, chat, and even by
telephone.
## Converting From Nickname to Petname
The other part of the system
that is impossible to quantify is the
mimicability of pet names. Let us assume a poorly built petname system
in the clutches of a clueless user. We have a money transfer site
on the Web that we have petnamed PayPal. We get an email telling us to
update our PayPal account, we click the link, and go to a domain that
has given itself the nickname PayPa1 (for those of you with typically
broken fonts, that last character, "1", is a one). Our poorly
built  hypothetical petname system
is so poorly
built, the nickname is put into the field where the petnames go, with a
hint of  shading or some other easy-to-miss mod to mark the
fact that
this is the web site's nickname for
itself, not our petname for it. The  distinction is missed,
and
our
user is phished.
The solutions to this problem
are
application and context specific,
though there are some good ideas floating around that seem to have wide
applicability. In the Waterken Petname Toolbar proposal (see below),
the alleged name is always "untrusted".  It's hard to fail to
recognize
that
this isn't PayPal, though a sufficiently unobservant user might
completely disregard the petname and nickname information and get
phished anyway. There is limited informal evidence that users really do
notice things like this (see below), and so the most cynical of
skeptics are probably mostly wrong though they are probably slightly
right: if you send a million phishing emails to each of a million
users, some day some one will be tired and unobservant and will get
phished. If sending a trillion emails like this is cheap enough,
phishing will remain profitable, so part of the solution needs to be
making a trillion emails ever so slightly expensive. Regardless,
multiple experiments with multiple
user interfaces would be a good idea to help develop user interfaces
that maximize the probability that a tired unobservant user will notice
a warning.
There are a couple of user
interface issues. The petnames must be unambiguously distinct from
nicknames. This seems easy to do, through colors, fonts, additional
text, and separate fields for the nickname as examples of pieces of
strategy.
More difficult is the following
problem: Petname creation must be
both painless (or people will reject the whole idea) and reliably
mimicry-free (it would be a disaster to have both PayPal and PayPa1 as
petnames!).  Is this one of those hopeless tradeoffs that the
computer security community enjoys throwing in its own face? To the
author, this
problem looks solvable; indeed, it seems hard to believe that this
cannot be solved with some reasonable satisfaction, given the number of
user interface ideas for this problem floating around. But
implementations and experiments, will be required to identify minimally
intrusive, adequately effective solutions. 
Here are two example ideas
for petname creation user interface
that seem generally applicable. First is to compose the default choice
for the petname out of a combination of contextual information and
nickname information. Suppose we click on a link to "PayPal" in the
Consumer Reports site (that is, the site that we have assigned the
nickname, "Consumer Reports"). This takes us to a new site that
proposes the nickname "PayPal". The system clearly marks that we do not
have a petname for this site and proposes "Consumer Reports's PayPal".
The user can press a button to accept this name, edit it, or, with
algorithmic chicanery left as an exercise for the reader, press a
second button that says, "let me use the raw nickname PayPal as the
petname." This system still depends on the user remembering the
petnames he has already assigned and noticing at the time of creation
of the new petname, whether he already has a similar name in his list.
This by itself is probably enough to protect the PayPal pet name --
most of us who gave PayPal a petname would have no trouble remembering
we had done so, and if we saw something that looked like "PayPal", we'd
notice we were at risk of confusing ourselves if we accepted a similar
name -- but again, we are dealing with humans, so the process is
imperfect. To support the human being, we'd want to use a font that was
as ambiguous as possible during petname creation, mixing up 1 and l and
I in a hopeless mess,
so that we could be confident that our petnames looked unique no
matter what ridiculous font got used later.
The second idea is to have a weak algorithm for comparing a candidate
petname in the act of being accepted to the existing petnames. We
explicitly call this a *weak*
algorithm because it can be
pretty poor. It  is quite
acceptable for the algorithm to pop a list of "similar petnames" that
is overly extensive, i.e., it is fine to show names that the human
easily recognizes as distinct. The serious error is to fail to show
names that
the human might confuse. Comparing Paypal to Paypa1, a sample algorithm
might notice that the names are of similar length and have three
letters in common ("p", "a", and "y"), and say, "that's similar enough
to worry me, I'm gonna check with the boss." The algorithm for noticing
similarity between private petnames is under much less pressure to be
perfect than is the algorithm for a Certificate Authority when deciding
whether
to award the name "pawpal" when the name "paypal" already exists. A CA
might like to prevent mimicry, but to do so must tread a
difficult line with abolishing huge swaths of namespace to ensure
similarities don't arise.
However it is done, mixing alphabets from different languages into a
single petname list is ridiculous. These are private petnames. Only one
person in the whole world needs to read them. Use the user's default
character
set, and be done.
# Examples, Near Examples, and Comparisons
## Physical World Petnames
Humans have been using parts of
petname systems since before the
invention of the written word. Human faces
were used as keys. These keys resisted forgery far better than most
things that pass for security today on computers (except in episodes
of Mission Impossible, and the occasional Shakespearian comedy like
12th Night). The referral, "Joe, this is my son Billy,
he's great with a club," transferred both a key/alleged-name pair and a
first-order
purposeful trust recommendation. The recipient of this referral
typically accepts the alleged name as a petname, though in some cases
the recipient may instead choose other petnames, such as, "Bob's big
dumb dufus of a son", which is a strictly private petname.
These physical world petname
systems were sufficiently different
from computer-based petname systems that it is dangerous to draw too
many conclusions from them. But the similarities are sufficiently
intriguing that the author feels compelled to mention them. More
comprehensive comparison and contrasting of physical petnaming to
computer-based petnaming is left as an entertainment for the reader.
## Trademark Law
Trademark law is not a petname
system. When civilization started
creating entities that did not have unforgeable faces (like Apple
Computer), we settled on a legal system that attempted, with fair
success, to enforce (that is, secure) purpose-unique memorable
global IDs for small numbers of entities. It is hard to map trademarks
onto petname systems for comparison, but an attempt seems in order. The
trademark-purpose pair is the key, made unforgeable by government
coercion. It
is important to note that the trademark itself is not the key: Apple
Computer and Apple Music both used the trademark Apple for decades,
without conflict, until Apple Computer entered the music business.
The trademark by itself is the
nickname: Apple Computer thinks of itself as "Apple". Petnames are
absent. Mimicry is prevented by the same
government action as forgery, and indeed the trademark system makes no
distinction between forgery and mimicry (which helps explain why the
distinction is so blurred in most computer security discussions).
Trademark law depends on the
legal system to disambiguate "similar
purpose". This is expensive, and consequently trademark law can only
apply to "small" numbers of "big" entities. The name Mark Miller is
covered by trademark law, but only in explicitly recognizing that all
people who have that name may use it, i.e., trademark law recognizes
non-uniqueness in this case. On the Web, the number of entities with
whom we
would like to associate trust/vulnerability relationships is extremely
large; indeed,
one of the failures of the Web today is that we cannot construct as
many such associations as we would like. Those relationships span
multiple legal jurisdictions, further complicating the trademark
system. Trademarking simply does not scale well enough for the age of the Web, despite its success in earlier eras.
## Instant Messaging Buddy Lists
Buddy lists for instant messengers follow the logic of petname systems
quite closely, though all the security properties are discarded in current
implementations. Each entity gets a globally unique id, rooted in the
domain name of the messaging service, which fills the role of "key". A
weak effort is made to make the id both human memorable on the one
hand, and unforgeable, on the other. The id is used as a nickname;
being sometimes memorable, it works well enough often enough. The same
id is used as
a key even though it is easy
to forge (either through man in the middle attacks or password
attacks).
The important point is that, once the user puts a petname into the
buddy list, all references to the id are represented using the petname:
you
can connect to the entity using the petname, and when the entity
connects to you, the petname displays.
Buddy lists are so intuitive,
people easily learn how to use them
with neither instruction nor documentation. An instant messenger that
used true keys, true nicknames, and enforced good security properties
would be virtually indistinguishable in user-interface presentation
from
existing systems; indeed, if one used an object-capability style of
key, the biggest difference would be the absence of passwords, an
actual usability improvement. Informal experimentation on a global
scale in the
instant messaging arena suggests the petname architecture embodied in
buddy lists can work well.
## CapDesk and Polaris
CapDesk \[CapDesk\] and Polaris \[Polaris\] are desktop systems that
explicitly flesh out a petname system to enforce security
properties. CapDesk is a point and click desktop that combines
usability, security, and functionality, to a degree often found
surprising by those unfamiliar with it. In CapDesk, at
application installation time the
application proposes a pet text and a pet graphic (the icon for the top
left corner, and the text in the title bar that is immediately
adjacent). The user may accept this petname or modify it. Windows
launched thereafter by the installed application are unforgeably marked
with the petname. Limited informal experimentation suggested that the
CapDesk petname system was intuitive and easy to use, like the buddy
lists.
Polaris is a derivative of
CapDesk that defends the Windows
operating system against several interesting classes of attack. Polaris
uses pet texts similar to the CapDesk pet texts for marking the
windows. Polaris was used in a larger set of pilot programs than
CapDesk ever experienced.
One result of the pilots that proved a pleasant surprise was that
people were  aware of and sensitive to the petname markings. This
supports the hope that petnames could indeed strongly impact phishing.
## Domain Names
The DNS system is perhaps the most widely used naming architecture in
the world. There are a couple of ways of viewing DNS from a petname
perspective. The most clarifying view is perhaps the view of the domain
name as both key and
nickname rolled into one -- a unique nickname that must try to support
security
properties. One powerful way to describe DNS is to say that DNS strives
to make keys that are memorable. In other words, it is a direct
violation of Zooko's triangle. And that is why mimicry is possible. *Mimicry is an emergent
property of the violation of Zooko's
triangle.* Mimicry emerges as
the system grows to large scale. DNS is the leading example of the
problem.
Several of the other examples
here treat the domain name as a trusted-path key.
Domain names are forgeable, but in practice they seem to be resistant
enough to forgery to be useful. Judging by the
prevalence of mimicry-based phishing over DNS forgery, it seems clear
that forgery is not the weakest link in DNS; mimicry is.
## Browser Bookmarks
Browser bookmarks combined with DNS have a remarkable similarity to a
petname system...with a fatal flaw. Think of the domain name as both a
key and a nickname (which is not fatal to a petname system, remember
the nickname has no security properties, it can be gibberish or
massively oversubscribed or mimicked without violation...though the
petname system has a better chance of success if users understand that
the nickname has no security properties, which is another problem with
DNS). With this characterization, the bookmark can be thought of as a
private name that points at the key,
suggested by the nickname. It sounds like a petname system.
However, the bookmark is not a
petname. Technically, it is a
*lambda name*. As noted earlier,
a true petname is a
*two-way* mapping: any
reference to the key is represented in the user's world as the petname.
However, lambda names like bookmarks only map from the private name to
the key, with no mapping back. When you follow a bookmark to a page, or
take any other path to get to the page, the domain name is used
throughout the user interface as the "name" for presentation to the
user, a fundamental violation of petname logic. Despite this violation,
bookmarks plus DNS demonstrate how even a partial implementation
of petnames will deliver some of the defense against
mimicry that a full petname system can achieve. Any person who uses the
strategy of reading an email allegedly from PayPal, and then clicking
on their existing bookmark to go to PayPal rather than following the
email-embedded link, is getting a security benefit derived from the
partial implementation of petnames afforded by bookmarks.
## OpenPGP and the Web of Trust
OpenPGP keys
carry nicknames with them, and the user can replace nicknames with a
name of the user's choosing, which would be a petname. When an entity's
key is observed by the software, the pet name is properly presented,
i.e., the petname is properly bidirectional.
The Web of Trust supplies an interesting way to associate these keys
with purposeful trust, by asking other entities who have vouched for
the new entity, what they recommend as a trust relationship.
With all these features,
OpenPGP supplies a true petname system
architecture. OpenPGP has not been tested by phishing attacks yet.
Since all the basic elements are there, the biggest question would be,
how must the user interfaces for applications using OpenPGP evolve to
face such a threat? This is another reminder that user interface is as
critical for any practical security architecture as is the crypto. A
security system whose user interface is written by cryptographers is no
more likely to succeed than a security system whose encryption
machinery is written by user interface designers.
## Waterken Petname Toolbar
This toolbar\[Waterken\] is a proposal for web browsers explicitly based
on petname
architecture, explicitly to prevent phishing. A certificate plus a
domain name is treated as the key. The petname is a true two-way
mapping between key
and private name. The alleged name for all sites is "untrusted"; there
is no nickname. For those
sites to which the user assigns a petname, the toolbar supplies
markings
that makes it easy for the user to unambiguously distinguish the site.
This toolbar has been implemented for Firefox. This author switched to
FireFox from Mozilla just to be able to use this tool. Limited
informal experimentation suggests that the petname toolbar is as
intuitive as the buddy lists and desktop systems described earlier.
## Certificate Authorities
Certificate
Authorities create
nickname/key pairs. The certificates
share with pgp keys the cryptographic strength to ensure
unforgeability. The claim is made that, because the nickname is unique
within the CA, interesting security properties may be ascribed to the
nickname. Petnames are not included in the scheme. It looks a fair bit
like DNS, with the CA root playing the role of the DNS root servers.
How do CA-based
systems fair against mimicry? The similarity to DNS is certainly
suspicious. A generous author
might just say, CA defense against mimicry is controversial in theory
and untested in practice. A less generous author would probably say no
more, since such an author would still desire people who
think that CAs are beneficial to read the rest of the paper.\
## Trustbar
The trustbar \[trustbar\] is a CA-based
browser system that
allows user construction of petnames, including both pet text and pet
graphics, for the certified entity.  In the 0.1 Mozilla
implementation, the distinction between a nickname (based on the cert)
and the petname is implied by the popup of a dialog box when the cert
is first encountered and no petname has yet been assigned. The petname
and the key are not quite fully bidirectional: the key is properly
represented by the petname in user interactions, but the petname cannot
be used to get to the key. This is just a quibble, however. The
Trustbar implements a petname system. It has, however, a big change
from a simple petname system: the inclusion of a
CA
in
the mix. Does this help
or hinder?
In the presence of the popular
"Just click Ok" mantra for certs, adding a CA
to the system may introduce new vulnerabilities. Two CA-based
attack examples: "We here at Verisign are upgrading our root key.
Please
follow the link and click Ok." Alternatively, "We here at Paypal have
fallen
into a legal dispute with Entrust. We are using a new CA that is every
bit as trustworthy. Please follow the link and click Ok." Brief
informal experimentation with the author's 83-year-old mother-in-law
suggests that an email asserting Paypal has changed domain names is
easily recognized as an attack. However, email asserting a cert has
changed is
viewed as a foolish demand impeding progress -- just click OK.
As noted earlier, user
interface design is every bit as important to
security as the strength of the keys. Simply stripping the trustbar
tool of the inevitable plethora of CA-related dialog boxes would
significantly improve usability, increasing the chances that real human
beings would tolerate it; all the security properties of a
petname system without CAs would remain intact. The Trustbar itself
pops dialogs at the user (sometimes several in a row, if the entity
maintaining a web site decides to use different certs for different
pages, as discovered during the author's experiments). Private
correspondence
with the designers of the trustbar suggest that evolution in a
direction reducing the frequency and annoyance of the dialogs is a
possibility.
How well will the current implementation of the trustbar work in
practice? Only
experimentation can tell.
## Pet Name Markup Language
PNML is an XML proposal for
using petname systems ubiquitously. In a
chat system, if Bob made a reference to Alice in the text he wrote to
Ted, and if Alice is Bob's petname for a person known to Ted with
petname Carol, the sent reference to Alice would be converted via the
magic of computers into a received reference to Carol. It would take
more effort to build PNML into an existing browser than to
integrate the Waterken Petname Toolbar, but the results
would be interesting indeed.
# Conclusions
Many informal experiments with
systems identified here that use
parts
of petname systems
have
demonstrated that they can be intuitive and easy to use (Buddy Lists,
Browser bookmarks, the petname toolbar, and the CapDesk and Polaris
secure desktops). A user who
understands his petname system and is alert to the information it
conveys can be extremely hard to trick using mimicry, making that user
a difficult target for phishing. Experimentation is required to
determine how much less vulnerable to phishing the typical user would
become given a petname system. Experimentation with
petnames for web browsers does not have to be expensive; both the
Trustbar and the Waterken
Petname Toolbar are ready now, both for usage and for further
experimentation by building variations based on the open-source code.
# Implementation Notes/Requirements
Following are key features
of a petname system. If an
implementation of a naming system for an application does not include
these properties, it is not fully following the logic of petnames:
- The key must be resistant
enough to forgery to survive in the
context of the application threat model.
- There can be at most one
petname per key per user per
application.\
- There can be at most one key
per petname (per user per
application).
- In the application user
interface, all references to the key are
represented by the petname.
- The user must be able to
assign a private petname to any key.
- The petname must be assigned
to the key only by explicit user
action.
- The user must be able to
repeatedly edit the petname of any key.
- The user interface shall
assist the user in assuring that two
petnames are not similar enough to enable mimicry, to the extent
necessitated by the complexity of the application context in which the
petnames are selected and manipulated. If the number of petnames needed
by the application is small and they are easily remembered, no
assistance may be required. If the number of petnames is large, and/or
difficult to remember and/or likely to be similar, and the resultant
forms of mimicry, accidental or intentional, leads to vulnerability
inside the threat model, assistance is required.
- Nicknames and alleged names
must be unambiguously visually
distinct from petnames.
- Nicknames are optional.
# Glossary
**Petname
System:** a naming system in
which, for each
individual entity recognized by another entity, three interlocking
names solve Zooko's Triangle. The three elements are the key
(global
and secure), the nickname (global and memorable), and the petname
(secure and memorable).
**Petname:**
This term has three distinct but related
usages in the literature on petnames. Sometimes it is used as a
shorthand for referring to the petname system as a whole. Sometimes it
is used as a direct reference to the naming element that is secure,
memorable, and private to the individual who refers to another
entity; this is the
meaning used throughout this paper. Sometimes "petname" is used to
refer to the textual component of a
petname (which may have graphical elements as well). In
contexts outside this paper, the reader must
ascertain the correct interpretation from that context. True petnames
are 2-way associative: given a petname in a specific application on a
specific machine, you can acquire the key, and given the key, you can
acquire the petname. The mapping back from the key to the petname is
always performed when presenting data to the user. This makes petnames
different
from lambda names, which only map from the name to the key.
**Pet
Text:** A petname, or part of
a petname, that is textual. The
owner of a machine upon which a petname resides can edit the text to
modify the petname.
**Pet
Graphic:** A petname, or part
of a petname, that is graphical.
**Pet
Face:** A petname, or part of
a petname, that is an image of a
human face. Pet faces are intended to exploit the special powers of the
human mind for associating purposeful trust with another human.
**Purposeful
Trust:** The type of
trust that is needed before a person
should empower another entity. Examples: "I trust Entity X to
hold N
dollars for me, and to perform transfers of that money on my behalf."
And, "I trust Entity Y to tell me whether or not to buy a car
from
Entity Z." We speak of purposeful trust to distinguish it from the many
other things computer people call "trust" these days. CAs, for
example supply "trust". But CAs do not tell you if you can trust a
certificate owner to pick up your garbage, or handle your
stock portfolio. It's just "trust".
**Forgery:**
An exact duplication
of a key, such that neither human nor computer can distinguish the
duplicate from the original.
**Mimicry:**
A duplication of
a name that is good enough to fool the human being, though not good
enough to fool a computer. A famous example is
the name *paypa1*
(with a "one" as the final character),
which mimics *paypal*
quite well.
The quality of the mimicry of paypal depends on the ambiguity of the
font in
use, and the alertness of the human reading the message.
**Lambda Names:**
Names that are memorable, secure, and
private, but
which only map from the name to the key: given the lambda name, you can
retrieve the key, but given the key there is no mapping back to the
name. Objects in programming languages follow this logic: the
programmer gives the object a name in the program, but once compiled,
neither the object nor much of anything else knows how to get back to
the name (though this is an imperfect example, since debuggers can
indeed map back). Bookmarks in browsers are another example: the
bookmark maps to a url, but once you go to the url, the url is
presented directly to the user, not the name embodied in the bookmark.
Consequently bookmarks cannot help against phishing.
# Acknowledgements
Thank you to everyone on the Cap-Talk mailing list for their help,
especially Ian Grigg for his deliciously relentless criticism, but also
notably including David Hopwood, Alan Karp, Mark Miller, Tyler Close,
Trevor Perrin, and Charles Landau, each of whom made comments that
directly caused modification to the early draft. Thank you also to Amir
Herzberg for his assistance in understanding the Trustbar.
# References
\[Zooko\] <http://zooko.com/distnames.html>\
\[Trustbar\] <http://eprint.iacr.org/2004/155/>
or [http://www.cs.biu.ac.il/\~herzbea//Papers/ecommerce/spoofing.htm](http://www.cs.biu.ac.il/%7Eherzbea//Papers/ecommerce/spoofing.htm)\
\[CapDesk\] <http://www.skyhunter.com/marcs/CapDeskSpec.html>
or <http://www.combex.com/tech/edesk.html>\
\[Polaris\] <http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html>\
\[Waterken\] <http://www.waterken.com/user/PetnameTool/>[](http://www.erights.org/elib/capability/pnml.html)\

0
docs/threshold_shnorr.pdf → docs/names/threshold_shnorr.pdf
View File

BIN
docs/names/zooko-triangle.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.0 KiB

11
docs/names/zookos_triangle.md
View File

@ -11,7 +11,16 @@ how do you know you have the right “Bob”? There are a lot of Bobs.
Zooko’s triangle is the solution to this problem. It is explained in several places
- [An Introduction to Petname Systems](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html)
- [An Introduction to Petname Systems](petnames.html)
![](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).
Without this essential piece of machinery, which no one ever gets around to implementing, the unbearable load of distinguishing public keys is dumped on the end user.
Zooko's triangle is thus a design for enabling humans to navigate public key systems, an as yet unimplemented design, though everyone, by rubbing up against problems, usually winds up implementing ad hoc something resembling a partial, incomplete, internally incosistent, and somewhat defective implementation of the Zooko name system.
- [Lambda for Humans: The PetName Markup Language](http://www.erights.org/elib/capability/pnml.html)
Each identity, whether a human, a server, or something else, has a globally

89
docs/names/zookos_triangle.svg Normal file
View File

@ -0,0 +1,89 @@
<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" >
PetNames
</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>
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

2
docs/net_money.html
View File

@ -171,4 +171,4 @@ deployed in a form that ordinary mortals can use. </p>
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>
</body></html>

2
docs/notes/merkle_patricia_dag.md
View File

@ -20,4 +20,4 @@ So what all engineers do in practice is use $\bigcirc$ to mean that the mathema
So, by the engineer's definition of $\bigcirc$, if an algorithm takes $\bigcirc(n)$ time it does *not* take $\bigcirc(n^2)$ time.
Which is why we never need to use Knuth's $\large\Omega$
Which is why we never need to use Knuth's $\large\Omega$

2
docs/openvpn.html
View File

@ -59,4 +59,4 @@ These days, every package and its little brother has gui elements, and you canno
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>
</html>

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>

24
docs/pandoc_templates/logo.svg Normal file
View File

@ -0,0 +1,24 @@
<svg
xmlns="http://www.w3.org/2000/svg"
width="width: 100%" height="100%"
viewBox="-2 -2 4 4">
<g fill="#0F0" font-family="Georgia" font-size="2.4">
<g id="h3">
<g id="h2">
<path id="flame" stroke="#0D0" stroke-width="0.05"
d="
M -0.2 -0.93
c .3 -.3, -.3 -.6, .5 -1
C -0.15 -1.5, 0.4 -1.5, 0.2 -0.94
"
/>
<use href="#flame" transform="rotate(111.24 0,0)"/>
</g>
<use href="#h2" transform="rotate(153.74 0,0)"/>
</g>
<use href="#h3" transform="rotate(153.74 0,0)"/>
<use href="#flame" transform="rotate(202.43 0,0)"/>
<circle r="1" />
<text x="0" y=".27" text-anchor="middle" style="fill:#000">ρ</text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 688 B

32
docs/pandoc_templates/mkdocs.cfg Normal file
View File

@ -0,0 +1,32 @@
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 --css=$templates/style.css -o"
for f in *.md
do
len=${#f}
base=${f:0:($len-3)}
if [ $f -nt $destdir$base.html ];
then
line=""
for i in 1 2 3 4 5 6
do
read line
if [[ $line =~ katex$ ]];
then
katex=" --katex=./"
fi
done <$f
pandoc $katex $options $destdir$base.html $base.md
echo "$base.html from $f"
#else
# echo " $base.html up to date"
fi
done

97
docs/pandoc_templates/pandoc.template Normal file
View File

@ -0,0 +1,97 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="$lang$" xml:lang="$lang$"$if(dir)$ dir="$dir$"$endif$>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
$for(author-meta)$
<meta name="author" content="$author-meta$" />
$endfor$
$if(date-meta)$
<meta name="dcterms.date" content="$date-meta$" />
$endif$
$if(keywords)$
<meta name="keywords" content="$for(keywords)$$keywords$$sep$, $endfor$" />
$endif$
$if(description-meta)$
<meta name="description" content="$description-meta$" />
$endif$
<title>$if(title-prefix)$$title-prefix$ – $endif$$pagetitle$</title>
<style>
$styles.html()$
</style>
$for(css)$
<link rel="stylesheet" href="$css$" />
$endfor$
<link rel="shortcut icon" href="$targetDocroot$rho.ico">
$for(header-includes)$
$endfor$
$header-includes$
$if(math)$
$if(mathjax)$
<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
$endif$
$math$
$endif$
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
$if(sidebar)$
<style>
body {
max-width: 49em;
margin-left: 1em;
}
</style>
$endif$
</head>
<body>
<div class="logo-header">
<a href="$targetDocroot$manifesto/motivation.html">
<img src="$targetDocroot$pandoc_templates/logo.svg" id="logo-graphic" alt="logo">
<div style="height:18px;"></div>
<div id="Rhocoin"></div>
</a>
</div>
$for(include-before)$
$include-before$
$endfor$
$if(sidebar)$
$if(toc)$
<div style=" float:left;
width: 38.2%;
position: sticky;
height: calc(100vh - $banner_height$);
margin 0;
overflow: auto;
top: 0;">
<nav id="$idprefix$TOC" role="doc-toc">
$if(toc-title)$
<h2 id="$idprefix$toc-title">$toc-title$</h2>
$endif$
$table-of-contents$
</nav>
</div>
<div style="margin-left:39%;">
$endif$
$endif$
$if(title)$
<header id="title-block-header">
<h1 class="title">$title$</h1>
$if(subtitle)$
<p class="subtitle">$subtitle$</p>
$endif$
$endif$
$body$
$if(sidebar)$
</div>
$endif$
$for(include-after)$
$include-after$
$endfor$
$if(notmine)$
$else$
<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>&nbsp;reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F<br />This work is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.</p>
$endif$
</body>
</html>

80
docs/pandoc_templates/style.css
View File

@ -45,8 +45,88 @@ td, th {
text-align: left;
}
pre.terminal_image {
font-family: 'Lucida Console';
background-color: #000;
color: #0F0;
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: #2C9F30;
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: #2C9F30;
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%;
}

2
docs/pandoc_templates/vscode.css
View File

@ -1,3 +1,3 @@
body {
font-size: 85%;
font-size: 100%;
}

18
docs/proof_of_stake.md
View File

@ -1,13 +1,13 @@
---
title:
Proof of Stake
proof of share
...
::: {style="background-color : #ffdddd; font-size:120%"}
![run!](tealdeer.gif)[TL;DR Map a blockdag algorithm equivalent to the
Generalized MultiPaxos Byzantine
protocol to the corporate form:]{style="font-size:150%"}
The proof of stake crypto currency will work like
The proof of share crypto currency will work like
shares. Crypto wallets, or the humans controlling the wallets,
correspond to shareholders.
Peer computers in good standing on the blockchain, or the humans
@ -15,7 +15,7 @@ controlling them, correspond to company directors.
CEO.
:::
We need proof of stake because our state regulated system of notaries,
We need proof of share because our state regulated system of notaries,
bankers, accountants, and lawyers has gone off the rails, and because
proof of work means that a tiny handful of people who are [burning a
whole lot of computer power]
@ -57,7 +57,7 @@ Because current blockchains are proof of work, rather than proof of
stake, they give coin holders no power. Thus an initial coin offering
(ICO) is not a promise of general authority over the assets of the
proposed company, but a promise of future goods or services that will be
provided by the company. A proof of stake ICO could function as a more
provided by the company. A proof of share ICO could function as a more
direct substitute for an initial public offering (IPO).  Thus we want it
to be easy to issue your own coins, and [to perform coin swaps between
chains without the need for an exchange] that would provide a potential
@ -376,7 +376,7 @@ actually does set the total order i decided retrospectively, equivalent to
continuous retrospective leader election in the classic Byzantine fault
resistant algorithms.
Proof of stake works like the corporate form, or can work like the
proof of share works like the corporate form, or can work like the
corporate form, with the crypto currency as shares, the wallets, or the
humans controlling the wallets, as shareholders, the peers in good
standing, or the humans controlling the peers in good standing as the
@ -384,7 +384,7 @@ board, and the primus inter pares, or the human controlling the primus
inter pares, as the CEO.
Thus the crypto currency works, or can work, like shares in a
corporation.  Proof of stake means that the shareholders can less easily
corporation.  proof of share means that the shareholders can less easily
be screwed over, since the shareholders elect the board from time to
time, and the board elects the CEO from time to time to time.
@ -396,7 +396,7 @@ privilege of being the source of root names, and its shares are the most
liquid, the most readily exchangeable, and this is the primary thing
that makes it “main”.
# Implementation of proof of stake
# Implementation of proof of share
Good blockdag protocols with high consensus bandwidth rely on forming
a consensus about the total past of the blockchain during the gossip
@ -451,7 +451,7 @@ than a dozen, less than a thousand, and an enormous number of client wallets,
billions of client wallets.  And we need to give client wallets power and
prevent the peers from having too much power.
Power to the wallets means our system has to run on proof of stake, rather
Power to the wallets means our system has to run on proof of share, rather
than proof of work. But since a wallet is not always on the internet, cannot
routinely exercise power moment to moment. So, we need a system where unspent
transaction outputs are hosted by particular blockchain peers, or large
@ -559,7 +559,7 @@ Byzantine failure, if intentional and malicious, is lying, either explicitly - g
In a blockdag, this always going to become visible eventually, but the problem is, it may become visible too late.
Mechanisms to protect against Byzantine failure look superficially like
proof of stake shareholder democracy but they are subtly different. They
proof of share shareholder democracy but they are subtly different. They
protect against the ten percent attack, but assume that any one outcome
selected by any one correctly functioning peer is equally acceptable, that
the problem is selecting one of many equally possible and equally

8
docs/recognizing_categories_and_instances.md
View File

@ -48,6 +48,14 @@ preserve distances within twenty five percent, in which case we need two
hundred and fifty six dimensions. So a dimensionally reduced point is not
necessarily reduced by a whole lot.
Two hundred and fifty six dimensions is still an impractically large
dimensionality, albeit an improvement on what was likely a near infinite
number of dimensions.
To reduce it to something actually useful, need principal component
analysis. If non linear methods required, as likely they will be, neural
network methods.
For spaces of dimension higher than fifteen or so, clever methods of
nearest neighbour search generally fail, and people generally wind up with
brute force search, comparing each point to each of the others, and then

2
docs/ripple.html
View File

@ -192,4 +192,4 @@ power law network.&nbsp; </p>
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>
</body></html>

1
docs/rootDocs/README.md
View File

@ -2,6 +2,7 @@
title: >-
README
---
[pre alpha documentation (mostly a wish list)](docs/index.htm)
[copyright © and license](./license.txt)

43
docs/rootDocs/mkdocs.sh Normal file
View File

@ -0,0 +1,43 @@
#!/bin/bash
set -e
cd `dirname $0`
docroot="../"
targetDocroot="docs/"
destdir="../../"
banner_height=banner_height:15ex
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
if [[ -z $targetDocroot ]]; then
targetDocroot=$docroot
fi
options=$osoptions"--toc --number-sections --toc-depth=5 --from markdown+smart+raw_html+fenced_divs+bracketed_spans --to html5 --wrap=preserve --metadata=lang:en --css=$targetDocroot/pandoc_templates/style.css -Bnavbar -o"
for f in *
do
[[ -d $item && -x $item/mkdocs.sh ]] && $item/mkdocs.sh
if [[ $f =~ (.*)".md"$ ]];then
base=${BASH_REMATCH[1]}
if [[ $f -nt $destdir$base.html ]]; then
katex=""
line=""
for i in 1 2 3 4 5 6
do
read line
if [[ $line =~ katex ]];then
katex=" --katex="$docroot
fi
done <$f
pandoc --variable $banner_height --variable targetDocroot:$targetDocroot --template $docroot"pandoc_templates/pandoc.template" $katex $options $destdir$base.html $base.md
echo "$destdir$base.html from $f"
#else
# echo " $base.html up to date"
fi
fi
done

7
docs/rootDocs/navbar Normal file
View File

@ -0,0 +1,7 @@
<div class="button-bar">
<a href="README.html">readme</a>
<a href="LICENSE.html">license</a>
<a href="NOTICE.html">notice</a>
<a href="RELEASE_NOTES.html">release notes</a>
</div>

2
docs/safe_operating_system.html
View File

@ -354,4 +354,4 @@ package.&nbsp; </p>
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>
</body></html>

2
docs/scale_clients_trust.md
View File

@ -143,7 +143,7 @@ None of these are yet implemented, and we will not get around to
implementing them until we start to take over the world. But it is
necessary that what we do implement be upwards compatible with this scaling design:
## proof of stake
## proof of share
Make the stake of a peer the value of coins (unspent transaction outputs)
that were injected into the blockchain through that peer. This ensures that

32
docs/setup/contributor_code_of_conduct.md
View File

@ -15,6 +15,13 @@ that frequently strange and overcomplicated design decisions are made,
decisions), decisions whose only apparent utility is to provide paths for
hostile organizations to exploit subtle, complex, and unobvious security holes.
McAffee reported that this is a result of plants - the state plants engineers
in nominally private organizations to create backdoors. Shortly after he
reported this he was arrested and murdered by the US government. (To be
precise he was arrested at the instigation of the US government, and then
"mysteriously" murdered while in prison. Prison murders remain
"mysterious" only if carried out by the state.)
These holes are often designed so that they can only be utilized efficiently
by a huge organization with a huge datacentre that collects enormous
numbers of hashes and enormous amounts of data, and checks enormous
@ -66,14 +73,37 @@ Login identities shall have no password reset, because that is a security
hole. If people forget their password, they should just create a new login
that uses the same GPG key.
Every pull request should be made using `git request-pull`, (rather than
some web UI, for the web UI is apt to identify people through the domain
name system and their login identities.)
The start argument of `git request-pull` should correspond to a signed
commit by the person requested, and the end argument to a signed and
tagged commit by the person requesting.
When creating the tag for a pull request, git drops one into an editor and
asks one to describe the tag. One should then give a lengthy description of
one's pull request documenting the changes made.
When accepting a pull request, the information provided by the requestor
through the tag and elsewhere should be duplicated by the acceptor into
the (possibly quite lengthy) merge message.
Thus all changes should be made, explained, and approved by persons
identified cryptographically, rather than through the domain name system.
# No race, sex, religion, nationality, or sexual preference
![On the internet nobody knows you are a dog](./images/nobody_know_you_are_a_dog.webp)
![On the internet nobody knows you are a dog](../images/nobody_know_you_are_a_dog.webp)
Everyone shall be white, male, heterosexual, and vaguely Christian, even
if they quite obviously are not, but no one shall unnecessarily and
irrelevantly reveal their actual race, sex, religion, or political orientation.
Unnecessarily informing people one is female or Jewish or nonwhite
should get similar treatment to unnecessarily informing people one is a
pure blooded Aryan.
All faiths shall be referred to respectfully. Even if they happen to be
making war on us, this software may not be very relevant to that kind of
warfare, in which case that discussion can be held elsewhere.

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"

491
docs/setup/set_up_build_environments.md
View File

@ -2,12 +2,35 @@
title:
Set up build environments
...
# partitioning for linux
For a gpt partition table, sixteen MiB fat32 partition with boot and efi flags
set, one gigabyte linux swap, and the rest your ext4 root file system.
With an efi-gpt partition table, efi handles multiboot, so if you have
windows, going to need a bigger boot-efi partition. (grub takes a bit over
four MiB)
For an ms-dos (non efi) partition table, fivehundred and twelve MIB ext4
partition with the boot flag set, (linux uses 220 MiB) one gigabyte linux swap,
and the rest your ext4 root file system.
In `gparted' an msdos partition table for a linux system should look
something like this
![msdos partition table](../images/msdos_linux_partition.webp)
And a gpt partition table for a linux system should look something like this
![gpt partition table](../images/gpt_partitioned_linux_disk.webp)
# Virtual Box
To build a cross platform application, you need to build in a cross
platform environment.
## Setting up Ubuntu in Virtual Box
## Setting up Ubuntu in VirtualBox
Having a whole lot of different versions of different machines, with a
whole lot of snapshots, can suck up a remarkable amount of disk space
@ -43,16 +66,20 @@ Debian especially tends to have security in place to stop random people
from sticking in CDs that get root access to the OS to run code to amend
the OS in ways the developers did not anticipate.
## Setting up Debian in Virtual Box
## Setting up Debian in VirtualBox
### Guest Additions
To install guest additions on Debian:
```bash
su -l root
apt-get -qy update && apt-get -qy install build-essential module-assistant git dnsutils curl sudo dialog rsync
sudo -i
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
mount -t iso9660 /dev/sr0 /media/cdrom
apt autoremove -qy
mount /media/cdrom0
cd /media/cdrom0 && sh ./VBoxLinuxAdditions.run
usermod -a -G vboxsf cherry
```
@ -65,9 +92,7 @@ system updates in the background, the system will not shut
down correctly, and guest additions has to be reinstalled with a
`shutdown -r`. Or copy and paste mysteriously stops working.
On Debian lightdm mate go to system/ control center/ Look and Feel/ Screensaver and turn off the screensaver screen lock
Go to go to system / control center/ Hardware/ Power Management and turn off the computer and screen sleep.
### auto gui login
To set automatic login on lightdm-mate
@ -91,23 +116,37 @@ autologin-user=cherry
autologin-user-timeout=0
```
### grub timeout
```bash
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
the directory `~/.config/autostart` and copy the appropriate `*.desktop`
files into it from `/usr/share/applications` or
`~/.local/share/applications`.
### Don't let the screen saver log you out.
On Debian lightdm mate go to system/ control center/ Look and Feel/ Screensaver and turn off the screensaver screen lock
Go to go to system / control center/ Hardware/ Power Management and turn off the computer and screen sleep.
### setup ssh server
In the shared directory, I have a copy of /etc and ~.ssh ready to roll, so I just go into the shared directory copy them over, `chmod` .ssh and reboot.
On the source machine
```bash
scp -r .ssh «destination»:~
scp -r etc «destination»:/
chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
```
On the destination machine
```bash
chmod 700 .ssh && chmod 600 .ssh/*
```
I cannot do it all from within the destination machine, because linux cannot follow windows symbolic links.
### Set the hostname
check the hostname and dns domain name with
@ -119,8 +158,9 @@ hostname && domainname -s && hostnamectl status
And if need be, set them with
```bash
domainname -b reaction.la
hostnamectl set-hostname reaction.la
fn=reaction.la
domainname -b $fn
hostnamectl set-hostname $fn
```
Your /etc/hosts file should contain
@ -152,32 +192,275 @@ ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
Note that visual studio remote compile requires an `ecdsa-sha2-nistp256` key on the host machine that it is remote compiling for. If it is nist, it is
backdoored
### .bashrc
If the host has a domain name, the default in `/etc/bash.bashrc` will not display it in full at the prompt, which can lead to you being confused about which host on the internet you are commanding.
```bash
nano /etc/bash.bashrc
```
Change the lower case `h` in ` PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '` to an upper case `H`
Change the lower case `h` in `PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '` to an upper case `H`
```text
PS1='${debian_chroot:+($debian_chroot)}\u@\H:\w\$ '
```
And, similarly, in two places in `etc/skel/.bashrc` Also
I also like the bash aliases:
```bash
cp -rv ~/.ssh /etc/skel
```text
alias ll="ls -hal"
mkcd() { mkdir -p "$1" && cd "$1"; }
```
# Actual server
Setting them in `/etc/bash.bashrc` sets them for all users, including root. But the default `~/.bashrc` is apt to override the change of `H` for `h` in `PS1`
## disable password entry
### fstab
The line for in fstab for optical disks needs to given the options `udf,iso9660 ro,users,auto,nofail` so that it automounts, and any user can eject it.
Confusingly, `nofail` means that it is allowed to fail, which of course it will
if there is nothing in the optical drive.
`'user,noauto` means that the user has to mount it, and only the user that
mounted it can unmount it. `user,auto` is likely to result in root mounting it,
and if `root` mounted it, as it probably did, you have a problem. Which
problem is fixed by saying `users` instead of `user`
## Setting up OpenWrt in VirtualBox
OpenWrt is a router, and needs a network to route. So you use it to route a
virtual box internal network.
Ignore the instructions on the OpenWrt website for setting up in Virtual
Box. Those instructions are wrong and do not work. Kind of obvious that
they are not going to work, since they do not provide for connecting to an
internal network that would need its own router. They suffer from a basic
lack of direction, purpose, and intent.
Download the appropriate gzipped image file, expand it to an image file, and convert to a vdi file.
You need an [x86 64 bit version of OpenWrt](https://openwrt.org/docs/guide-user/installation/openwrt_x86). There are four versions of them, squashed and not squashed, efi and not efi. Not efi is more likely to work and not squashed is more likely to work, but only squashed supports automatic updates of the kernel.
In git bash terminal
```bash
gzip -d openwrt-*.img.gz
/c/"Program Files"/Oracle/VirtualBox/VBoxManage convertfromraw --format VDI openwrt-22.03.3-x86-64-generic-ext4-combined.img openwrt-generic-ext4-combined.vdi
```
Add the vdi to oracle media using the oracle media manager.
The resulting vdi file may have things wrong with it that would prevent it from booting, but viewing it in gparted will normalize it.
Create a virtual computer, name openwrt, type linux, version Linux 2.6, 3.x, 4.x, 5.x (64 bit) The first network adaptor in it should be internal, the second one should be NAT or bridged/
Boot up openwrt headless, and any virtual machine on the internal network should just work. From any virtual machine on the internal network, configure the router at http://192.168.1.1
## Virtual disks
The first virtual disk attached to a virtual machine is `/dev/sda`, the second
is `/dev/sdb`, and so on and so forth.
This does not necessarily correspond to order in which virtual drives have
been attached to the virtual machine
Be warned that the debian setup, when it encounters multiple partitions
that have the same UUID is apt to make seemingly random decisions as to which partitions to mount to what.
The problem is that virtual box clone does not change the partition UUIDs. To address this, attach to another linux system without mounting, change the UUIDs with `gparted`. Which will frequently refuse to change a UUID because it knows
better than you do. Will not do anything that would screw up grub.
`boot-repair` can fix a `grub` on the boot drive of a linux system different
from the one it itself booted from, but to boot a cdrom on an oracle virtual
box efi system, cannot have anything attached to SATA. Attach the disk
immediately after the boot-repair grub menu comes up.
The resulting repaired system may nonetheless take a strangely long time
to boot, because it is trying to resume a suspended linux, which may not
be supported on your device.
`boot-repair` and `update-initramfs` make a wild assed guess that if it sees
what looks like a swap partition, it is probably on a laptop that supports
suspend/resume. If this guess is wrong, you are in trouble.
If it is not supported this leads to a strangely long boot delay while grub
waits for the resume data that was stored to the swap file:
```bash
#to fix long waits to resume a nonexistent suspend
sudo -i
swapoff -a
update-initramfs -u
shutdown -r now
```
If you have a separate boot partition in an `efi `system then the `grub.cfg` in `/boot/efi/EFI/debian` (not to be confused with all the other `grub.cfgs`)
should look like
```terminal_image
search.fs_uuid «8943ba15-8939-4bca-ae3d-92534cc937c3» boot hd0,gpt«4»
set prefix=($boot)'/grub'
configfile $prefix/grub.cfg
```
Where the «funny brackets», as always, indicate mutas mutandis.
Should you dig all the way down to the efi boot menu, which boots grub,
which then boots the real grub, the device identifier used corresponds to
the PARTUUID in
`lsblk -o name,type,size,fstype,mountpoint,UUID,PARTUUID` while linux uses the UUID.
If you attach two virtual disks representing two different linux
systems,with the same UUIDs to the same sata controller while powered
down, big surprise is likely on powering up. Attaching one of them to
virtio will evade this problem.
If you amend file system UUID's referenced in fstab and boot, have to amend `/etc/fstab` and `/boot/efi/EFI/debian/grub.cfg`, then rerun `update-grub`.
But a better solution is to change all the UUIDs, since every piece of software expects them to be unique, and edit `/etc/fstab` accordingly. Which will probably stop grub from booting your system, because in grub.cfg it is searching for the /boot or / by UUID.
However, sometimes one can add one additional virtual disk to a sata
controller after the system has powered up, which will produce no
surprises, for the disk will be attached but not mounted.
So cheerfully attaching one linux disk to another linux system so that you
can manipulate one system with the other may well have surprising,
unexpected, and highly undesirable results.
What decisions it has in fact made are revealed by `lsblk`
If one wants to add a several attached disks without surprises, then while
the virtual machines is powered down, attach the virtio-scsis controller,
and a bunch of virtual hard disks to it. The machine will then boot up with
only the sata disk mounted, as one would expect, but the disks attached to
the virtio controller will get attached as the ids /dev/sda, /dev/sdb,
/dev/sdc/, etc, while the sata disk gets mounted, but surprisingly gets the
last id, rather than the first.
After one does what is needful, power down and detach the hard disks, for
if a hard disk is attached to multiple systems, unpleasant suprises are
likely to ensue.
So when you attach a foreign linux disk by sata to another linux system,
attach after it has booted, and detach before you shutdown, to ensure
predictable and expected behavior.
This however only seems to work with efi sata drives, so one can only
attach one additional disk after it has booted.
Dynamic virtual disks in virtual box can be resized, and copied to a
different (larger size)
Confusingly, the documentation and the UI does not distinguish between
dynamic and fixed sized virtual disks - so the UI to change a fixed sized
disks size, or to copy it to a disk of different size is there, but has
absolutely no effect.
Having changed the virtual disk size in the host system, you then want to
change the partition sizes using gparted, which requires the virtual disk to
be attached, but not mounted, to another guest virtual machine in which
you will run `gparted`.
Over time, dynamic virtual disks occupy more and more physical storage,
because more and more sectors become non zero, even though unused.
You attach the virtual disk that you want to shrink to another guest OS as
`/dev/sdb`, which is attached but not mounted, and, in the other guest OS
`zerofree /dev/sdb1` which will zero the free space on partition 1. (And
similarly for any other linux file system partitions)
You run `zerofree`, like gparted, in another in a guest OS, that is mounted
on `/dev/sda` while the disk whose partitions you are zeroing is attached,
but not mounted, as `/dev/sdb1`.
You can then shrink it in the host OS with
```bash
VBoxManage modifyhd -compact thediskfile.vdi
```
or make a copy that will be smaller than the original.
To resize a fixed sized disk you have to make a dynamic copy, then run
gparted (on the other guest OS, you don't want to muck with a mounted
file system using gparted, it is dangerous and broken) to shrink the
partitions if you intend to shrink the virtual disk, resize the dynamic copy
in the host OS, then, if you expanded the virtual disk run gparted to expand
the partitions.
To modify the size of a guest operating system virtual disk, you need that
OS not running, and two other operating systems, the host system and a
second guest operating system. You attach, but not mount, the disk to a
second guest operating system so that you can run zerofree and gparted in
that guest OS.
And now that you have a dynamic disk that is a different size, you can
create a fixed size copy of it using virtual media manager in the host
system. This, however, is an impractically slow and inefficient process for
any large disk. For a one terabyte disk, takes a couple of days, a day or
so to initialize the new virtual disk, during which the progress meter shows
zero progress, and another day or so to do actually do the copy, during which
the progress meter very slowly increases.
Cloning a fixed sized disk is quite fast, and a quite reasonable way of
backing stuff up.
To list block devices `lsblk -o name,type,size,fsuse%,fstype,fsver,mountpoint,UUID`.
To mount an attached disk, create an empty directory, normally under
`mnt`, and `mount /dev/sdb3 /mnt/newvm`
For example:
```terminal_image
root@example.com:~#lsblk -o name,type,size,fsuse%,fstype,fsver,mountpoint,UUID
NAME TYPE SIZE FSTYPE MOUNTPOINT UUID
sda disk 20G
├─sda1 part 33M vfat /boot/efi E470-C4BA
├─sda2 part 3G swap [SWAP] 764b1b37-c66f-4552-b2b6-0d48196198d7
└─sda3 part 17G ext4 / efd3621c-63a4-4728-b7dd-747527f107c0
sdb disk 20G
├─sdb1 part 33M vfat E470-C4BA
├─sdb2 part 3G swap 764b1b37-c66f-4552-b2b6-0d48196198d7
└─sdb3 part 17G ext4 efd3621c-63a4-4728-b7dd-747527f107c0
sr0 rom 1024M
root@example.com:~# mkdir -p /mnt/sdb2
root@example.com:~# mount /dev/sdb2 /mnt/sdb2
root@example.com:~# ls -hal /mnt/sdb2
drwxr-xr-x 20 root root 4.0K Dec 12 06:55 .
drwxr-xr-x 5 root root 4.0K Dec 20 16:02 ..
drwxr-xr-x 4 root root 4.0K Dec 12 06:27 dev
drwxr-xr-x 119 root root 4.0K Dec 20 12:58 etc
drwxr-xr-x 3 root root 4.0K Dec 12 06:32 home
drwxr-xr-x 3 root root 4.0K Dec 12 06:27 media
drwxr-xr-x 2 root root 4.0K Dec 12 06:27 mnt
drwxr-xr-x 11 root root 4.0K Dec 12 06:27 var
```
when backing up from one virtual hard drive to another very similar one,
mount the source disk with `mount -r`
We are not worried about permissions and symlinks, so use `rsync -rcv --inplace --append-verify`
If worried about permissions and symlinks `rsync -acv --inplace --append-verify`
There is some horrid bug with `rsync -acv --inplace --append-verify` that makes it excruciatingly slow if you are copying a lot of data.
`cp -vuxr «source-dir»/«.bit*» «dest-dir»` should have similar effect,
but perhaps considerably faster, but it checks only the times, which may
be disastrous if you have been using your backup live any time after you
used the master live. After backing up, run your backup live once briefly,
before using the backed up master, then never again till the next backup.
# Actual server
Setting up an actual server is similar to setting up the virtual machine
modelling it, except you have to worry about the server getting overloaded
and locking up.
## disable password entry
On an actual server, it is advisable to enable passwordless sudo for one user.
issue the command `visudo` and edit the sudoers file to contain the line:
@ -186,32 +469,16 @@ issue the command `visudo` and edit the sudoers file to contain the line:
cherry ALL=(ALL) NOPASSWD:ALL
```
That user can now sudo any root command, with no password login nor ssh in for root. And can also get into the root shell with `sudo su -l root`
On an actual server, you may want to totally disable passwords to
accounts that have sensitive information by corrupting the shadow file
```bash
usermod -L cherry
```
But this tactic is very risky, because it can, due to bug in Linux, disable
ssh public key login. And then you are really hosed. Better to use a very
long random password, and then throw it away.
When an account is disabled in this manner, you cannot login at the
terminal, and may be unable to ssh in, but you can still get into it by
`su -l cherry` from the root account. And if you have disabled the root account,
but have enabled passwordless sudo for one special user, you can still get
into the root account with `sudo -s` or `sudo su -l root` But if you disable
the root account in this manner without creating an account that can sudo
into root passwordless, you are hosed big time. So instead, once `ssh` is
working, give one user passwordless sudo, make sure you can ssh into that
account, and disable password and ssh access to the root account.
You can always undo the deliberate corruption by setting a new password,
providing you can somehow get into root.
That user can now sudo any root command, with no password login nor
ssh in for root. And can also get into the root shell with `sudo su -l root`
On an actual server, you may want to totally disable passwords to accounts
that have sensitive information. Unfortunately any method for totally
disabling passwords is likely to totally disable ssh login, because the
people writing the software have "helpfully" decided that that is what you
probably intended, even though it is seldom what people want, intend, or
expect . So the nearest thing you can do is set a long, random, non
memorable password, and forget it.
## never enough memory
@ -376,19 +643,53 @@ of (multi-)user utilities and applications.
## Setting up ssh
When your hosing service gives you a server, you will probably initially
have to control it by password. And not only is this unsafe and lots of
utilities fail to work with passwords, but your local ssh client may well fail
to do a password login, endelessly offering public keys, when no
`~/.ssh/authorized_keys` file yet exists on the freshly created server.
To force your local client to employ passwords:
```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=no root@«server»
```
And then the first thing you do on the freshly initialized server is
```bash
apt update -qy
apt upgrade -qy
shutdown -r now && exit
```
And the *next* thing you do is login again and set up login by ssh key,
because if you make changes and *then* update, things are likely to break
(because your hosting service likely installed a very old version of linux).
Login by password is second class, and there are a bunch of esoteric
special cases where it does not quite 100% work in all situations,
because stuff wants to auto log you in without asking for input.
Putty is the windows ssh client, but you can use the Linux ssh client in
windows in the git bash shell, and the Linux remote file copy utility
`scp` is way better than the putty utility PSFTP.
windows in the git bash shell, which is way better than putty, and the
Linux remote file copy utility `scp` is way better than the putty utility
`PSFTP`, and the Linux remote file copy utility `rsync` way better than
either of them, though unfortunately `rsync` does not work in the windows bash shell.
The filezilla client works natively on both windows and linux, and it is very good gui file copy utility that, like scp and rsync, works by ssh (once you set up the necessary public and private keys.) Unfortunately on windows, it insists on putty format private keys, while the git bash shell for windows wants linux format keys.
Usually a command line interface is a pain and error prone, with a
multitude of mysterious and inexplicable options and parameters, and one
typo or out of order command causing your system to unrecoverably die,but even though Putty has a windowed interface, the command line
typo or out of order command causing your system to unrecoverably
die,but even though Putty has a windowed interface, the command line
interface of bash is easier to use.
(The gui interface of filezilla is the easiest to us, but I tend not to bother
setting up the putty keys for it, and wind up using rsync linux to linux,
which, like all comand line interfaces is more powerful, but more difficult
and dangerous)
It is easier in practice to use the bash (or, on Windows, git-bash) to manage keys than PuTTYgen. You generate a key pair with
```bash
@ -426,7 +727,7 @@ I make sure auto login works, which enables me to make `ssh` do all sorts of
things, then I disable ssh password login, restrict the root login to only be
permitted via ssh keys.
In order to do this, open up the SSHD config file (which is ssh daemon
In order to do this, open up the `sshd_config` file (which is ssh daemon
config, not ssh_config. If you edit this into the the ssh_config file
everything goes to hell in a handbasket. ssh_config is the global
.ssh/config file):
@ -438,22 +739,18 @@ nano /etc/ssh/sshd_config
Your config file should have in it
```default
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PrintMotd no
PasswordAuthentication no
UsePAM no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
HostKey /etc/ssh/ssh_host_ed25519_key
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
PasswordAuthentication no
PubkeyAuthentication yes
PermitTunnel yes
X11Forwarding yes
AllowAgentForwarding yes
AllowTcpForwarding yes
TCPKeepAlive yes
AllowStreamLocalForwarding yes
GatewayPorts yes
PermitTunnel yes
PermitRootLogin prohibit-password
HostKey /etc/ssh/ssh_host_ed25519_key
ciphers chacha20-poly1305@openssh.com
macs hmac-sha2-256-etm@openssh.com
kexalgorithms curve25519-sha256
@ -461,6 +758,11 @@ pubkeyacceptedkeytypes ssh-ed25519
hostkeyalgorithms ssh-ed25519
hostbasedacceptedkeytypes ssh-ed25519
casignaturealgorithms ssh-ed25519
# no default banner path
Banner none
PrintMotd no
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
@ -1153,7 +1455,8 @@ map to the old server, until the new server works.)
```bash
apt-get -qy install certbot python-certbot-nginx
certbot register --register-unsafely-without-email --agree-tos
certbot run -a manual --preferred-challenges dns -i nginx -d reaction.la -d blog.reaction.la
certbot run -a manual --preferred-challenges dns -i nginx \
-d reaction.la -d blog.reaction.la
nginx -t
```
@ -1161,13 +1464,23 @@ This does not set up automatic renewal. To get automatic renewal going,
you will need to renew with the `webroot` challenge rather than the `manual`
once DNS points to this server.
This, ` --preferred-challenges dns`, also allows you to set up wildcard
certificates, but it is a pain, and does not support automatic renewal.
Automatic renewal requires of wildcards requires the cooperation of
certbot and your dns server, and is different for every organization, so only
the big boys can play.
But if you are doing this, not on your test server, but on your live server, the easy way, which will also setup automatic renewal and configure your webserver to be https only, is:
```bash
certbot --nginx -d mail.reaction.la,blog.reaction.la,reaction.la
certbot --nginx -d \
mail.reaction.la,blog.reaction.la,reaction.la,\
www.reaction.la,www.blog.reaction.la,\
gitea.reaction.la,git.reaction.la
```
If instead you already have a certificate, because you copied over your `/etc/letsencrypt` directory
If instead you already have a certificate, because you copied over your
`/etc/letsencrypt` directory
```bash
apt-get -qy install certbot python-certbot-nginx
@ -1765,16 +2078,16 @@ apt -qy install postfix
```
Near the end of the installation process, you will be presented with a window that looks like the one in the image below:
![Initial Config Screen](./images/postfix_cfg1.webp){width=100%}
![Initial Config Screen](../images/postfix_cfg1.webp){width=100%}
If `<Ok>` is not highlighted, hit tab.
Press `ENTER` to continue.
The default option is **Internet Site**, which is preselected on the following screen:
![Config Selection Screen](./images/postfix_cfg2.webp){width=100%}
![Config Selection Screen](../images/postfix_cfg2.webp){width=100%}
Press `ENTER` to continue.
After that, you’ll get another window to set the domain name of the site that is sending the email:
![System Mail Name Selection](./images/postfix_cfg3.webp){width=100%}
![System Mail Name Selection](../images/postfix_cfg3.webp){width=100%}
The `System mail name` should be the same as the name you assigned to the server when you were creating it. When you’ve finished, press `TAB`, then `ENTER`.
You now have Postfix installed and are ready to modify its configuration settings.
@ -2871,7 +3184,7 @@ when your subkey expires.
```bash
save
gpg --list-keys --with-subkey-fingerprints --with-keygrip «master key»
gpg -a --export-keys «master key»
gpg -a --export «master key»
gpg -a --export-secret-keys «master key»
```
@ -2923,6 +3236,7 @@ not signing code, though that will be our first use of it, but to enable
[sovereign corporations] to act through remote employees and safely use
servers in the cloud. Information wants to be free, but programmers want
to be paid.
### Phabricator
Server Size : 2GB Ram – 1 CPU Core – 50GB SSD
@ -3149,11 +3463,34 @@ name](https://gitlab.com/gitlab-org/gitlab-ce/issues/13530).
## coupling to the desktop
[base directory specifications]:https://specifications.freedesktop.org/basedir-spec/latest/
[Linux desktop standard]:https://specifications.freedesktop.org/menu-spec/latest/
[Desktop Application Autostart Specification]:https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html
To couple to the desktop requires a pile of information and configuration,
which most people ignore most of the time. To the extent that they provide it,
they seem to write it for the Gnome based desktops, Cinnamon and Mate – more
for Mate because it is older and has changed less.
An install program should use `desktop-file-install` which is presumably
customized for each desktop,
The autostart directory `$XDG_CONFIG_HOME /autostart' is a part of the
freedesktop.org/XDG [Desktop Application Autostart Specification].
`$XDG_CONFIG_HOME` is seldom set, in which case it is equal to `~/.config`, hence the autostart directory is nearly always `~/.config/autostart`
The desktop specification is chock full of references to `$XDG_foo_bar`,
which is confusing because these are environment variables that no one
ever sets, and which should never be set, which means that their default
values *almost* always apply. Further, many of the directories are not
default created, so the first program to write a file into them has to create them. Which is likely to be your program, because superuser is likely to
create a user specially for your program.
This mysterious usage is explained, cryptically, in [base directory specifications]
Since wxWidgets is written for GDT in its linux version, it is written for Gnome.
Gnome3, the default Debian desktop, is broken, largely because they refuse to
@ -3170,10 +3507,10 @@ Linux has its command line features polished and stable, but is still
wandering around somewhat lost figuring out how desktops should work.
Under Mate and KDE Plasma, bitcoin implements run-on-login by generating a
`bitcoin.desktop` file and writing it into `~/.config/autostart`
`bitcoin.desktop` file and writing it into `~/.config/autostart` (`$XDG_CONFIG_HOME/autostart`).
It does not, however, place the `bitcoin.desktop` file in any of the
expected other places. Should be in `/usr/share/applications`
expected other places. Should be in `/usr/share/applications` (`$XDG_DATA_DIRS/applications`).
The following works

169
docs/setup/wireguard.md
View File

@ -139,7 +139,7 @@ apt install -qy wireguard wireguard-tools linux-headers-$(uname -r)
On the server
```bash
mkdir -p /etc/wireguard
sudo mkdir -p /etc/wireguard
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
sudo chmod 600 /etc/wireguard/ -R
```
@ -147,7 +147,7 @@ sudo chmod 600 /etc/wireguard/ -R
On the client
```bash
mkdir -p /etc/wireguard
sudo mkdir -p /etc/wireguard
wg genkey | sudo tee /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key
sudo chmod 600 /etc/wireguard/ -R
```
@ -155,6 +155,8 @@ sudo chmod 600 /etc/wireguard/ -R
## Create WireGuard Server Configuration File
This configuration file is for two clients, one of which is a bitcoin peer for which port forwarding is provided, and to provide them a nat translated IPv4 address, and an IPv6 address on a random /112 subnet of the vpn servers /64 subnet. Adjust to taste. IPv6 is tricky.
Use a command-line text editor like Nano to create a WireGuard configuration file on the Debian server. `wg0` will be the network interface name.
```bash
@ -165,6 +167,30 @@ Copy the following text and paste it to your configuration file. You need to use
The curly braces mean that you do not copy the text inside the curly braces, which is only there for example. You have to substitute your own private key (since everyone now knows this private key), and your own client public key., mutas mutandis.
```default
[Interface]
# public key = CHRh92zutofXTapxNRKxYEpxzwKhp3FfwUfRYzmGHR4=
Address = 10.10.10.1/24, 2405:4200:f001:13f6:7ae3:6c54:61ab:0001/112
ListenPort = 115
PrivateKey = iOdkQoqm5oyFgnCbP5+6wMw99PxDb7pTs509BD6+AE8=
[Peer]
PublicKey = rtPdw1xDwYjJnDNM2eY2waANgBV4ejhHEwjP/BysljA=
AllowedIPs = 10.10.10.4/32, 2405:4200:f001:13f6:7ae3:6c54:61ab:0009/128
[Peer]
PublicKey = YvBwFyAeL50uvRq05Lv6MSSEFGlxx+L6VlgZoWA/Ulo=
AllowedIPs = 10.10.10.8/32, 2405:4200:f001:13f6:7ae3:6c54:61ab:0019/128
[Peer]
PublicKey = XpT68TnsSMFoZ3vy/fVvayvrQjTRQ3mrM7dmyjoWJgw=
AllowedIPs = 10.10.10.12/32, 2405:4200:f001:13f6:7ae3:6c54:61ab:0029/128
[Peer]
PublicKey = f2m6KRH+GWAcCuPk/TChzD01fAr9fHFpOMbAcyo3t2U=
AllowedIPs = 10.10.10.16/32, 2405:4200:f001:13f6:7ae3:6c54:61ab:0039/128
```
```default
[Interface]
Address = 10.10.10.1/24
@ -221,13 +247,18 @@ Next, find the name of your server’s main network interface.
```bash
ip addr | grep BROADCAST
server_network_interface=$(ip addr | grep BROADCAST |sed -r "s/.*:[[:space:]]*([[:alnum:]]+)[[:space:]]*:.*/\1/")
echo $server_network_interface
```
As you can see, it’s named `eth0` on my Debian server.
```terminal_image
:~# ip addr | grep BROADCAST
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
:~# server_network_interface=$(ip addr | grep BROADCAST |sed -r "s/([[:alnum:]]+):[[:space:]]*(.*)[[:space:]]*:(.*)/\2/")
:~# echo $server_network_interface
eth0
```
To configure IP masquerading, we have to add iptables command in a UFW configuration file.
@ -278,7 +309,7 @@ The above lines will append `-A` a rule to the end of the`POSTROUTING` chain of
Like your home router, it means your client system behind the nat has no open ports.
If you want to open some ports, for example the bitcoin port 8333 so that you can run bitcoin core
If you want to open some ports, for example the bitcoin port 8333 so that you can run bitcoin core and the monaro ports.
```terminal_image
NAT table rules
@ -286,8 +317,11 @@ NAT table rules
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p tcp --dport 8333 -j DNAT --to-destination 10.10.10.2:8333
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p udp --dport 8333 -j DNAT --to-destination 10.10.10.2:8333
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p tcp --dport 8333 -j DNAT --to-destination 10.10.10.«5»:8333
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p udp --dport 8333 -j DNAT --to-destination 10.10.10.«5»:8333
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p tcp --dport 18080 -j DNAT --to-destination 10.10.10.«5»:18080
-A PREROUTING -d «123.45.67.89»/32 -i eth0 -p tcp --dport 18089 -j DNAT --to-destination 10.10.10.«5»:18089
COMMIT
```
@ -296,20 +330,28 @@ Then open the corresponding ports in ufw
```bash
ufw allow in 8333
ufw enable
ufw status verbose
```
If you have made an error in `/etc/ufw/before6.rules` enable will fail.
If you have enabled UFW before, then you can use systemctl to restart UFW.
## Configure forwarding on the Server
### Allow routing
By default, UFW forbids packet forwarding. We can allow forwarding for our private network, mutas mutandis.
```bash
ufw route allow in on wg0
ufw route allow out on wg0
ufw allow in on wg0
ufw allow in from 10.10.10.0/24
ufw allow in from 2405:4200:f001:13f6:7ae3:6c54:61ab:0001/112
ufw allow «51820»/udp
ufw allow to «2405:4200:f001:13f6:7ae3:6c54:61ab:1/112»
ufw allow to 10.10.10.1/24
ufw allow to 2405:4200:f001:13f6:7ae3:6c54:61ab:0001/112
```
As always «...» means that this is an example value, and you need to substitute your actual value. "_Mutas mutandis_" means "changing that which should be changed", in other words, watch out for those «...» .
@ -326,6 +368,7 @@ windows, mac, and android clients in the part that is not open.
`wg0` is the virtual network card that `wg0.conf` specifies. If you called it `«your name».conf` then mutatis mutandis.
### Enable routing
You just told ufw to allow your vpn clients to see each other on the internet, but allowing routing does not in itself result in any routing.
@ -341,6 +384,12 @@ net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
```
For these changes to take effect:
```bash
sysctl -p
```
Now if you list the rules in the POSTROUTING chain of the NAT table by using the following command:
```bash
@ -374,15 +423,26 @@ Sample output:
```terminal_image
:~$ systemctl status bind9
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-05-17 08:11:26 UTC; 37s ago
Docs: man:named(8)
Main PID: 13820 (named)
Tasks: 5 (limit: 1074)
Memory: 14.3M
CPU: 8.709s
CGroup: /system.slice/named.service
└─13820 /usr/sbin/named -f -u bind
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-09-21 20:14:33 EDT; 6min ago
Docs: man:named(8)
Main PID: 1079 (named)
Tasks: 5 (limit: 1132)
Memory: 16.7M
CPU: 86ms
CGroup: /system.slice/named.service
└─1079 /usr/sbin/named -f -u bind
Sep 21 20:14:33 rho.la named[1079]: command channel listening on ::1#953
Sep 21 20:14:33 rho.la named[1079]: managed-keys-zone: loaded serial 0
Sep 21 20:14:33 rho.la named[1079]: zone 0.in-addr.arpa/IN: loaded serial 1
Sep 21 20:14:33 rho.la named[1079]: zone 127.in-addr.arpa/IN: loaded serial 1
Sep 21 20:14:33 rho.la named[1079]: zone 255.in-addr.arpa/IN: loaded serial 1
Sep 21 20:14:33 rho.la named[1079]: zone localhost/IN: loaded serial 2
Sep 21 20:14:33 rho.la named[1079]: all zones loaded
Sep 21 20:14:33 rho.la named[1079]: running
Sep 21 20:14:33 rho.la named[1079]: managed-keys-zone: Initializing automatic trust anchor management for zone '.'; >
Sep 21 20:14:33 rho.la named[1079]: resolver priming query complete
```
If it’s not running, start it with:
@ -391,31 +451,74 @@ If it’s not running, start it with:
systemctl start bind9
```
Check that lookups still work:
```bash
curl -6 icanhazip.com
curl -4 icanhazip.com
```
See what dns server you are in fact using
```bash
dig icanhazip.com
```
You will notice you are not using your own bind9
Edit the BIND DNS server’s configuration file.
```bash
nano /etc/bind/named.conf.options
```
Add the following line to allow VPN clients to send recursive DNS queries.
Add some acls above the options block, one for your networks, and one for potential attackers.
```default
allow-recursion { 127.0.0.1; 10.10.10.0/24; ::1/128; };
```
Add some real forwarders
And add allow recursion for your subnets.
After which it should look something like this:
Save and close the file.
```terminal_image
:~# cat /etc/bind/named.conf.options | tail -n 9
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 { any; };
allow-recursion { 127.0.0.1; 10.10.10.0/24; ::1/128; };
acl bogusnets {
0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};
acl my_net {
127.0.0.1;
::1;
116.251.216.176;
10.10.10.0/24;
2405:4200:f001:13f6::/64;
};
options {
directory "/var/cache/bind";
forwarders {
2a02:6b8::feed:0ff;
2a02:6b8:0:1::feed:0ff;
77.88.8.8;
77.88.8.1;
};
//==========================
// If BIND logs error messages about the
// root key being expired,
// you will need to update your keys.
// See https://www.isc.org/bind-keys
//==========================
dnssec-validation auto;
listen-on-v6 { any; };
allow-recursion { my_net; };
blackhole { bogusnets; };
};
```
Then edit the `/etc/default/named` files.
@ -439,10 +542,13 @@ Restart `bind9` for the changes to take effect.
```bash
systemctl restart bind9
systemctl status bind9
dig -t txt -c chaos VERSION.BIND @127.0.0.1
```
Your ufw firewall will allow vpn clients to access `bind9` because you earlier allowed everything from `wg0` in.
## Start WireGuard on the server
Run the following command on the server to start WireGuard.
@ -550,6 +656,11 @@ You can also run the following command to get the current public IP address.
curl https://icanhazip.com
```
To get the geographic location
```bash
curl https://www.dnsleaktest.com |grep from
```
# Troubleshooting
## Check if UDP port «51820» is open

2
docs/spam_filtering.html
View File

@ -32,4 +32,4 @@
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>
//////
//////

2
docs/the_internet_money_solution.html
View File

@ -181,4 +181,4 @@ 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>
</body></html>

2
docs/the_login_problem.html
View File

@ -160,4 +160,4 @@ mindlessly do a one click add.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>
</body></html>

25
docs/vision_statement.html
View File

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

93
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
@ -181,7 +183,6 @@ compile correctly, but `\ln` and `\log` is more likely to compile correctly than
symbol.
$$\ln(1+x)=x-\bigcirc(x^2)$$
$$H(a|b|v)$$
though it is subtly prettier with katex, and some maths expressions will
break Pandoc unless one tells it to use katex.
@ -340,15 +341,28 @@ Alignments can be specified as with pipe tables, by putting colons at the bounda
| Right | Left | Centered |
+---------------+---------------+--------------------+
# diagrams
# Images
Images are preferably `*.webp`, and are expressed as the markdown code
`![](./image_name.webp){style="width: 479px; height: 386px;"}`
assuming the actual image size is 479 pixels wide and 386 pixels high, 479 pixels being the typical width of an image rendered at 100% of the text width with my default formats, and indeed a whole lot of other people's default formats on a typical screen. But obviously pixel size is getting smaller, so for device independence and simplicity, might well give a larger image, and leave out the style command.
# Diagrams
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
@ -374,8 +388,9 @@ that causes the least grief, and gives you a nice smooth curve.
The first point is the starting position, the last point is the end
position. The direction of the first control point sets the starting
direction, the direction of the second control point sets the end
direction, and how far the control points are out controls how
direction, and how far the control points are out controls how and
where the curve changes direction. If the curve is weird and pathological, there is something funny with your control points.
Some control point positions lead to singularities in the derivative
of the curv but for reasonable control point positions, you get a
nice smooth curve.
@ -396,14 +411,11 @@ curve, the further its influence propagates into the next S curve.
Which can have surprising results if the next S curve is very short, so
that influence of the previous control point propagates far beyond its end.
If you want a smooth and gentle curve, you want the last C or S
control point to be around the middle of the curve, and its
reflection in the next S curve to be around the middle of the next S curve
If you want a smooth and gentle curve, you want the the reflection of the previous C or S control around the middle of the next S curve
You only need additional points when you want the curve to go
through a narrow pass, in which case you are going to have a C
curve going to the narrow pass, and an S curve going to the
destination or the next narrow pass.
curve going to the narrow pass, the last control point before the narrow pass, its reflection in the next S curve after the narrow pass.
When you want to join two points, and don't care about the path, use an L straight line
@ -448,15 +460,48 @@ the C to be in line with the last two points of the prior curve.
M point q point point t point t point ... t point
```
Is also guaranteed to give you a nice smooth curve for any
reasonably sane choice of the initial control point and the position
of the t points, but you cannot easily control the direction the curve
takes through the points. Changing the control point of the first q
will result in things snaking all down the line, and changing any of
the intermediate t points will change the the direction the curve
takes through all subsequent t points, sometimes pushing the curve
into pathological territory where bezier curves give unexpected and
nasty results.
<div style="width: 100%; height: auto; overflow: auto;">
<svg
xmlns="http://www.w3.org/2000/svg"
width="width: 100%" height="100%"
viewBox="0 0 120 80"
style="background-color:ivory">
<g stroke-width="2">
<path fill="none" stroke="#00f000"
d="
M14,45, c40,-20, 30,-56 54,-18, s55,15 40,15
s-15,10 -30,15
M 5,45, q 10,20 30,1, t 10,10, t 10,12
" />
</g>
</svg>
</div>
```html
<div style="width: 100%; height: auto; overflow: auto;">
<svg
xmlns="http://www.w3.org/2000/svg"
width="width: 100%" height="100%"
viewBox="0 0 120 80"
style="background-color:ivory">
<g stroke-width="2">
<path fill="none" stroke="#00f000"
d="
M14,45, c40,-20, 30,-56 54,-18, s55,15 40,15
s-15,10 -30,15
M 5,45, q 10,20 30,1, t 10,10, t 10,12
" />
</g>
</svg>
</div>
```
Is also guaranteed to give you a nice smooth curve for any reasonably sane
choice of the initial control point and the position of the t points, but you cannot easily control the direction the curve takes through the points. Changing the control point of the first q will result in things snaking all
down the line, and changing any of the intermediate t points will change
the the direction the curve takes through all subsequent t points,
sometimes pushing the curve into pathological territory where bezier
curves give unexpected and nasty results.
Scalable vector graphics are dimensionless, and the `<svg>` tag's
height, width, and ViewBox properties translate the dimensionless