wallet/docs/manifesto/social_networking.md

---
# katex
title: >-
	Social networking
sidebar: true
notmine: false
misc_links: >-
	Let’s eat <a href="SWIFT.html"  target="_blank">SWIFT's lunch</a>.<br>
abstract: >-
	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
"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.

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.

The difference between censorship and moderation is that a moderator acts
to protect the discussion from shills, spam, and scammers, while a censor
acts to prevent the discussion of dangerous ideas.

What the censor is suppressing is stuff that is not generally known and not
generally available. What moderators are needed for is to suppress is stuff
that is very hard to avoid, because a thousand sock puppets are robotically
posting from the same script on a thousand forums.

# Social net architecture

You want to be able to message everyone in the world, but you don’t want
spammers and shills to be able to message you.  (The difference between a
spammer and a shill is that a shill is spearphishing.  A shill’s script is
narrowly targeted to a specific target community, like Trotsky declaring
himself to be a peasant in order to kill the peasants, or the innumerable pump
and dump “investment opportunities”.)

You want to be able to communicate to the broad public (equivalent of
web pages) as well as specific individuals (equivalent of text messages,
email), and you want people to be able to comment before the broad
public on content you have communicated to the broad public (equivalent
of blogs).  You want to be notified when someone sends a message
specifically to you, and you want to be notified when someone responds to
content you have communicated to the broad public, you want to be able
to turn off the ability to respond, or turn it off for any new respondents,
want to be able to close comments, and you want, with considerably less
urgency, to be notified when something appears before the broad public by
people you are following.

Thus the social network system of followers, followed, buddies, and feeds,
which combines the functionality of the web, the functionality of
messaging, and functionality of the blog. We can model everything as a
web, except that some parts of the web are directed acyclic graphs under
some directionality criterion.  A directed acyclic graph has an implicit time
order, hence notifications and feeds.

if  we try to distinguish between posts and comments as blogs do, there are
several tricky edge cases when we have replies to replies.

Usenet made no substantial distinction between posts and comments.
Making the distinction, as blogs do, breaks the conversation and
complicates the code and the interface.

Usenet died of shills, as for example the science fiction and fantasy
discussion groups dying as a side effect of progressive takeover of science
fiction fandom organizations.  Somehow the conversation would invariably
turn into attacks on capitalism, the market, family, fatherhood, and private
property, which did not have much to do with science fiction and fantasy.

If fantasy came up at all, it was in a conversation that presupposed the
evils of feudalism, and the Marxist history that capitalism was the
successor of feudalism, rather than in a conversation that presupposed the
reader’s yearning for Kingship, kinship, leadership, and the hero with a
thousand faces.

In the end the conversation in the science fiction and fantasy Usenet
discussion groups tended to be about the power of classes as defined by
Marx, rather than about power of heroes, Kings, and vigilantes. And so the
Usenet science fiction and fantasy discussion groups, and just about every
Usenet discussion group, died of shills.

Conversations became one man with one microphone attached to a
thousand megaphones, and replying was like talking back to the national
news broadcast, because you could reply to a shill, but the man giving the
shill her script was not listening, because he was running a hundred
similar shills, and his shill would just stick to her script, the script he had
assigned to her no matter what you replied to her script.

Her replies to your reply would be unresponsive, because they came from
a script written by a man who had never thought about or foreseen your
reply.

Conversations came to resemble the conversations you have with a non
player character in a video game, a scripted robotic simulation of actual
conversation, or the conversations on a help line with an unhelpful third
world help line worker to whom English is a second language, and who is
reading from a script, a script written by a man whose native tongue is
English, but his script is designed to deal with certain common problems
that do not in the slightest resemble the problem you have with the
product, because the man writing her script did not foresee your problem.

Usenet was designed for conversations, but was hijacked by Harvard and
the New York Times to give one way lectures, resembling those given in
Harvard and the pages of the New York Times.  Speaking back was
pointless, no one was listening, and eventually everyone stopped
speaking back, and Usenet died.

The conversation in the Usenet science fiction and fantasy groups died,
because the shills would stick to script no matter what, providing the
superficial simulation of a conversation about fantasy and science fiction
without the substance of a real conversation. And the same was happening
in every Usenet group, though what was being shilled varied from one
group to the next, with an immense multitude of different shilling
organizations running an immense multitude of unresponsive scripts
promoting an immense multitude of different scams, initially
most of them about money rather than politics, but what killed usenet
was political shills.
In the 3rd Reich there were no chess clubs or sewing circles only
national socialist chess clubs and sewing circles. Clownworld has
adopted the policy that there be only progressive and gay chess
clubs and dykey and progressive sewing circles.

Two real participants in the science fiction and fantasy Usenet group would
be having a conversation about the hero’s journey, and the computer of
the man writing the economic Marxist scripts would detect a keyword or key
phrase that it had been programmed to treat as relevant to a Marxist script,
and direct a shill to interject that script into the conversation, and the shill
would do so, mixing the script up a little with random fragments from the
actual conversation to prevent it from being too readily recognizable as the
same script already posted a thousand times before in a hundred Usenet
groups, and the conversation would be derailed.  Or worse, a robot
promoting class conflict based on sexual preference classes would be
triggered on seeing the post by a robot promoting class conflict based on
economic classes, and the conversation thereafter would consist of one
robot pushing scripts about economic Marxist classes, and another robot
pushing scripts about Cultural Marxist classes with the bored economic
Marxist shill industriously interweaving random fragments from Cultural
Marxist script into the economic Marxist script, and the bored Cultural
Marxist shill industriously interweaving random fragments from the
economic Marxist script into the Cultural Marxist script to create the
semblance of a conversation where no actual conversation existed, merely
random variations on scripts already robotically pushed a thousand times
in a hundred places.

The real participants eventually left the Usenet group leaving the robots to
robotically talk to each other.

To prevent shills, you need moderation.  But moderation is apt to get
centrally controlled and become censorship, shutting down vitally needed
conversations.  We need mandatory moderation, to prevent what happened
to Usenet, but we need completely decentralized moderation, to prevent
censorship.

If you don’t have a means of stopping one way broadcasts into a medium
designed for conversations, your social net is going to be flooded with one
way broadcasts.

The particular axe that was being ground was not the problem.  There is no
end of large, wealthy, and powerful organizations with axes to grind.  In
the Science Fiction and Fantasy group, the primary problem seemed to be
organizations created and funded by Harvard and the New York Times
promoting cultural Marxism and old type economic Marxism, but if it had
not been them, would have been someone else promoting something else.
One way broadcasts provide the opportunity for power and money.

So what should happen is that when you have a feed, and are a follower of
Bob, Bob’s public posts that you have not yet seen are marked as unread
in the feed, and listed by title or first line if no title.  And if you look at one
of them, the thing he is replying to is just a click away, and the replies he
has approved are just a click away.  But you don’t see, and cannot click on,
the replies he has not approved, unless you are following those
commenters also.  Though he might give blanket approval to Alice’s feed,
in which case you would also see Alice and everything she approved.

Because if you could click on them, a million shills and spammers would
reply, rendering the link worthless.

If you want two way narrowcasts, you need a means to keep out
broadcasts, or else narrowcast memes sent by individuals to individuals
will be drowned out by mass produced broadcast memes sent to everyone
indiscriminately by large bureaucratic organizations.   If it had not been
Harvard and the New York Times, might have been some megachurch.
Indeed, in the early days of the internet, it was some megachurch.

In the early days of the internet, every group, regardless of topic,
regardless of its area of interest, was full of repetitious stuff about young
earth creationism, material indistinguishable from what I had seen before
in every other group, with any attempt to debate the posters receiving
unresponsive scripted responses to the unscripted response, responses
suspiciously similar to a thousand similarly unresponsive responses in a
thousand different interest groups attempting to pursue a thousand quite
different interests.

If young earth creationist shilling died out, it was because bigger and more
powerful organizations with more important axes to grind got in on the
business of broadcasting one way broadcasts into narrowcast two way
media.  The old indiscriminate one way broadcasts were drowned out by
new indiscriminate one way broadcasts reflecting the concerns of bigger
and more powerful organizations, in the end, the biggest and most
powerful organizations of all.

When you look at your set of feeds, you want to see which feeds have
activity on them by real people that you are following, and when you look
at a particular feed, you want to see only new activity by the person you
are following, and also which items on the feed have new replies approved
by the person you are following.

Which, unless the person you are following is issuing indiscriminate
approvals, is going to keep out the one way broadcasts by shills,
spammers, and scammers.  And if he is issuing indiscriminate approvals,
people will soon stop following his feed in the same way everyone
dropped out of Usenet groups as the shilling of one way broadcasts became
intolerable.

If Bob replied to Carol, and you are not following Carol, and you click on
Bob’s post, you should see in his post a link to the post by Carol that Bob
replied to, and if you click on that, you see Carol’s post containing a link
that will show all the replies to that Carol approved.  Which might include
Dave’s reply to Bob’s reply to Carol, a reply to Bob that Carol approved, but
Bob did not.

In which case, if you click on Carol’s replies link, you will see Dave’s
reply to Bob in her comments page, but if you click on Bob’s replies link,
you will not see it in Bob’s comments page.

What posts you can see will depend on the path by which you reached
them.  The mesh of reply links, reply-to links, and approval links form a
graph, and when you click around the conversation you are following that
graph. So people will learn to follow the paths of good moderators, and
will ignore the paths of bad moderators.

The web also forms a graph.  What is missing from the web whose lack
makes it not a social network is the time element: feeds.  You cannot have a
conversation over the web.  We need to support conversations, thus need to
have different and distinct reply links, reply-to links, and approvals
while the web only has one kind of link, losing the information that makes
a conversation a conversation.  A social network is a superset of the web,
email, and instant messaging, and a moderated but truly decentralized
social network is going to replace all of them.

So everything is a post – and a reply is just a post that has a reply-to link to
the post that it replies to.  And the reply-to link works both ways, in that the
post with the link will appear in the comments page of the original post
that it links to, if approved by the poster it links to.

So we treat replies and posts the same, everything a post.  If you are
following someone, you get his posts on your feed, and when you see a
post that he made public, you can click on a link to the post that he replied
to, and a link to any replies to him, or replies to his replies, that he
approved.

So everything you can click on and read  has to be by someone you are
following, a post approved by someone you are following, or approved by
the author of the post that you are now reading, supposing you clicked on
it to see the replies that he approved.  Otherwise we get the Usenet problem
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
the same principles as Git and git repositories, except that Git relies on
SSL and the Certificate Authority system to locate a repository, which
dangerous centralization would fail under the inevitable attack.  It needs to
find the network addresses of remote repositories on the basis of the public
key of a Zooko identity of a person who pushed a tag or a branch to that
repository, a branch being a thread, and the branch head in this case being
the most recent response to a thread by a person you are following.

We want to support a zooko identity for a machine whose owner wants
anyone in the world to be able to connect to, perhaps because he wants an
audience for his ideas, or for what he is selling.  And we also want to
support machines for which the connection information is a shared
secret, distributed on a need to know basis.

And we do not want a central authority with the capability to decide
what that address is.

For the normal case, zooko identity with public connect information, the
controller of the machine makes public a small number of other zooko
identities which have publicly accessible connect information, and very
long lived network addresses, so that lots of entities are going to have their
current network address cached, which identities  he promises to regularly
inform of his current network address.  And those entities make public
what they know of that network address, how recently they were informed
of it, the likelihood of that network address suddenly changing, and
apparent uptime of the entity whose network address they are reporting on.

The final authority for each such item of information is the Zooko
signature of the entity that wishes to be found, and the Zooko signatures of
the other entities that he keeps informed.  Thus, the authority over the
informations is fully distributed.

But in order to collect, distribute, and efficiently obtain this potentially
very large pile of data, there has to be a fair bit of centralization in
practice.  Git source code distribution provides a model of how to handle
this without dangerous or harmful centralization, or a central point of
failure.

For any one library on Git, there are an enormous number of branches.  But
in practice, everone winds up following one branch of that library, and if
you make changes in it, and want your changes included, you have to get
the man (and it is always a man) who runs that branch to pull your branch
into his.  And that is the centralization that is needed for efficient
distribution of data.  But if he is not doing a very good job, some people,
and eventually everyone, eventually winds up following a repository with a
different name, reflecting the fact that a different man is running it.  And
that is decentralization that is needed to prevent misconduct or single point of failure.

So, if someone is providing the service of making other people's network
addresses publicly available, he has to get that one man to pull his data.
Or get another man, whose data is pulled by that one man, to pull his data.

The reason git repositories scale is that the one man who in fact controls
the one repository that matters the most trusts several other men, each of
whom trust several others, and so information percolates through many
trusted people, eventually into the central repository, where everyone sees it.

Perhaps that one man might fail to include some zooko identity data for
wicked reasons, that he does not want people to hear what those people are
saying, that he wants to get between the man who wishes to speak, and the
man who wishes to hear.  Then some people will start pulling an additional
branch that does include those people, and eventually everyone winds up
pulling that branch, and after a while not pulling the old branch, and
eventually nearly everyone will do the same.

On the other hand, that one man might fail to include some zooko identity
data because he thinks it is a pile of sybils, shills, scammers, and
entryists, and the pile is too large, wasting too much disk space and
bandwidth, and if he is right, most people will not want that useless
misinformation cluttering up their disks.  Or some people might disagree,
and pull a branch that does include those questionable identitities.

Once our system starts to attract substantial use and attention, a vast pile
of sybil Zooko identities will appear, whose network addresses seem to be
located all over the world, but a very large proportion of them will in fact
be located on one computer in the bowels of the State Department or
Harvard, and to avoid collecting and distributing a hundred gigabytes of
this worthless and meaningless information will require human judgement
and human action, which judgment and action will have to be done by a
rather small number of humans, who will thus have rather too much
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.

### 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
a single human, rather than needing to exercise their own judgement.

With Git, you usually have one master repository.  Sometimes you do not,
and have to exercise your own judgement.  I have often enough tripped
over this, and often enough managed fine.

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 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
repositories out there is enormous and the number of hashes in each
repository is enormous, so this algorithm and data structure will scale, and
the responses to that thread that they have approved, by people you are not
following, will be commits in that repository, that, by pushing their latest
response to that thread to  a public repository, they did the equivalent of a
git commit and push to that repository.

Each repository contains all the material the poster has approved, resulting
in considerable duplication, but not enormous duplication.

The underlying protocol and mechanism is that when you are following
Bob, you get a Bob feed from a machine controlled by Bob, or controlled
by someone that Bob has chosen to act on his behalf, and that when Bob
replies to someone, the post that he replies to is copied onto his machine,
containing a link to a feed controlled by the person he replies to, and
similarly with replies that he approves.  So posts and links to feeds spread
around the net Usenet style, being duplicated on every machine that
comments on them or approves them and every machine that follows a
feed that contains them.  You access a feed BitTorrent style, sharing Bob’s
feed with everyone that follows Bob.  Each feed is a mutable torrent, a
Merkle-patricia tree with a single authority determining the current total
state of that tree, with the continually changing root of Bob’s Merkle-patricia
tree signed by Bob using his secret key which is kept in a BIP39
style wallet.

When Dave replies to a text in Carol's feed, the Carol text and the reply by
default goes into his feed, and if it does there will be metadata in his feed
about his social network connection to Carol, which, if Bob is following
Dave's feed, can be used by Bob's client to navigate the distribute hash
table to Carol's  feed.

And if Carol approves Dave's reply, or is following Dave or has buddied
Dave, and Bob is following Carol, but not following Dave, then there will
be in metadata in Carol's feed that can be used by Bob's client to navigate
the distribute hash table to Carol's  feed.

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

This design deleted, because its scaling properties turned out to be unexpectedly bad.

I am now writing up a better design.

##   Private messaging

Private messaging is trivial.  There is no end of excellent existing software
to  do it, in particular Jitsi Meet, Element, and, most secure of all
Bitmessage.  The hard problem is the public social net on which people
meet so that they can then engage in private messaging and form private
rooms.  Our social network’s private rooms are not going to be competitive
with the innumerable excellent existing systems supporting private conversations and private rooms, except that we need to provide efficient,
convenient, and secure means to launch private rooms and private
conversations from our public social network, and, most importantly,
because programmers need to be paid, we need to support private
conversations about money and payments, which existing private
messaging systems do not provide.  You cannot securely embed a private
payment in a private message in existing private messaging systems.

The most private solution for video conferencing is Jitsi Meet *if* you run
your own Jitsi Meet server. If you are using someone else’s Jitsi Meet your
messages are still private, but the someone else owns your metadata. A
more private and far more convenient solution for text and voice is
Element, and for text alone, the most secure is Bitmessage, which leaks no
metadata.

The highest priority for a crypto currency should be to re-open free public
discussion. (Since we are, at the moment, out of power, we are temporarily
free speech enthusiasts) But the second highest priority, and the one that
will get us money, is re-opening the path to entrepreneurship, thus we
should primarily be interested in freedom of speech about money and
transactions. The enemy is shutting down forums where people can
discuss unregulated crypto currency transactions.

Since we are going to need a BIP39 style wallet, need to put a crypto
currency in it, and the ability to have private conversations, which will
typically be about orders, payments, and receipts.  I just received over
email in the clear a payment acknowledgment containing most of my
credit card number and the three digit shared secret authorization on the
back of my credit card.  This is intolerably bad.  Similar things are
happening with crypto currency payments, linking crypto currency wallets
to physical locations such that the owner of the wallet can be found and
shaken down, because there is no wallet infrastructure for communicating
metadata about payments, so all the metadata, such as “deliver these goods
to this physical address” goes over public networks.

Jitsi is great for private human conversations about human things, but we
lack an environment useful for conversations about orders, payments, and
receipts, which is going to need integration with the payments and
accounting system, and needs to be based on BIP39 identities. Jitsi Meet
XMPP identities are not really useful for the purpose.  We are at present
using SSL identities based on the Domain Name System for this purpose,
hence the grossly inappropriate email I received, and these are
unsatisfactory, because there are a thousand certificate authorities, and any
organization that has a certificate authority in its pocket can intercept and
interfere with a supposedly private conversation.

This, rather than blockchain analysis, is the big problem with crypto
currencies that needs to be fixed.

Hence we need human readable messages that can have crypto coins,
unspent transaction outputs, and lightning network payments  embedded in
them.

A conversation between two people is an encrypted immutable
authenticated but unsigned data structure shared between two parties,

## Private rooms

There is plenty of excellent software supporting private messaging and
private rooms.  What is lacking is a public social network where it is safe
to have conversations that would give people a reason to to move to a
private room.

The infrastructure proposed in [Anonymous Multi-Hop Locks] for lightning
network transactions is also private room infrastructure, so we should
implement private rooms on that model.  Indeed we have to, in order to implement
a gateway between our crypto currency and bitcoin lightning, without which
we cannot have a liquidity event for our startup.

In order to do money over a private room, you need a `total order broadcast channel`,
so that Bob cannot organize a private room with Ann and Carol,
and make Ann see one three party transaction, and Carol see a different
three party transaction.

In this context, a broadcast channel is reliable if each of the participants
can know that all the other participants saw the message, or knows that the
room crashed and the conversation failed to complete.

For most purposes, this is seldom a concern, and existing private room
software fails to address this concern, which is hard to fix without
increasing the likelihood of leaking metadata.  But if we want to get paid,
need to address this concern, possibly at the expense of the usability and
security for other uses of our private rooms.

Existing software does not implement total order broadcast in private rooms,
and is generally used in ways and for purposes that do not need it.  And
anything that does implement total order broadcast channel is apt to leak
more metadata than software that does not implement it. So for most
existing uses, existing software is better than this software will be.  But to
do business securely and privately over the internet, you need a reliable
broadcast channel

Well then, as many dags as there are groups, and if someone is added, the
adding party adds a reply link in the data structure of the smaller group to
the larger group, and if someone is deleted, a subset of the parties to large
group get invited to the smaller group, which contains a reply-to link into
the larger group.  Every conversation is a room, and if you buddy someone,
he has authority to invite you to a room.  The bilateral shared secrets that
make a room possible are frequently discarded and replaced.  They are not
part of the immutable data structure, but infrastructure used to
communicate what is in the room.

Each room corresponds to a dag, a narrowly shared and transient
blockchain, so that all participants know that all participants are seeing the
same conversation.  But once the shared secrets have been discarded, the
room can no longer get new messages, and its data can no longer be
decrypted.  The  conversation is immutable but deletable.

Private rooms are recreated from time to time, with new transient keys,
and the old transient keys lost forever.  The participants may have a record
of what was said in the old private room, but the old conversation is not
present in the new room nor accessible from the new room, whereas a feed
is around forever, and its past rendered immutable by the Merkle-patricia
tree.

When you join a room, you submit a transient public key to each of the
participants in the room, and they respond with a transient public key,
constructing a shared secret between each pair of participants.

You then use symmetric encryption with that shared secret.  And then, over
the encrypted connection, set up a shared secret based on both the durable
public and private keys, and the transient keys.  So you now have, for each
pair of participants, a shared secret that depends on both parties durable
and transient keys.  Possession of the shared secret proves you know the
secret key corresponding to your public key, and you get perfect forward
secrecy because the shared secret and the transient keys are abandoned
when there is no further action in the private room.

Assume Bob’s secret key is $b$, and his public key is $B$, and similarly
Carol’s secret key is $c$ and her public key is $C$.

[Scriptless Scripts]:https://tlu.tarilabs.com/cryptography/scriptless-scripts/introduction-to-scriptless-scripts.html
"Introduction to Scriptless Scripts – Tari Labs University"

[Anonymous Multi-Hop Locks]: anonymous_multihop_locks_lightning_network.pdf
"Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability"

In order to support [Scriptless Scripts] and [Anonymous Multi-Hop Locks]
the private keys need to be scalars of an elliptic curve of prime order, such
as Ristretto25519, and the public keys need to be elliptic points on that
curve.

$b×C=c×B$.  (Lower case letters denote scalars modulo the order of
the curve, upper case denote the corresponding elliptic points on the
curve) So, to construct a shared secret that can be used for symmetric
encryption, Bob calculates $b×C$ and Carol calculates $c×B$

Suppose that Bob’s transient private and public keys are $b_t$ and $B_t$, and
his durable private and public keys are $b_d$ and $B_d$, and similarly for
Carol.

Then to construct a shared secret that depends on both the transient and
the durable keys, and proves knowledge of the durable private key, Bob
calculates $(b_d + b_t)×(C_d + C_t)$, and similarly Carol calculates
$(c_d + c_t)×(B_d + B_t)$.  (But this is only safe if both Bob and Carol
have first proven that they also know the shared secret $b_t×C_t = c_t×B_t$,
by first successfully decrypting and encrypting stuff symmetrically
encrypted to that secret)

A bilateral pair conversation is a pair of feeds that should have identical
content and hashes, and though they are not signed, they are authenticated.

A multilateral conversation is n bilateral conversations, n feeds.

For money matters, where the point is proving to third parties, we want
signatures on the hashes and immutable messages, but for bilateral
conversations we want authentication without signing

So the multilateral shared room is constructed through people
communicating over bilateral shared secrets constructed from unilateral
unshared secrets. The signed contents of the room are flood filled around
the participants, rather than each participant being required to communicate
his content to each of the others.

To provide a total order broadcast channel, a hash of the total state of the room is continually constructed

# signing and immutability

For money, we want signatures, and money is the highest priority.
Information wants to be free, but programmers want to be paid.  Carol
signs what she said to Bob, and she is stuck with it. Less cases to handle.
When you send money, you not only sign it, thus rendering it immutable
but deletable, you sign the message, thus signing all the previously
mutable conversations linked in through the “reply-to” and “regarding”
links in your message.  The preceding conversation was authenticated but
unsigned, thus potentially mutable and deniable, but becomes signed by
and one party, and thus immutable, when he sends money, and signed by
the other party when he accepts the money.

[Zooko’s triangle]: ./zookos_triangle.html

A message with a single recipient is always authenticated, though possibly
only by a cheap readily discardable [Zooko’s triangle]  identity.  If it is about
money, normally signed, and thus immutable but discardable.

A message with two or more recipients is always signed, regardless of
whether it has money or not, because there are too many cases to handle
otherwise, and thus immutable though deletable, and it retains perfect
forward secrecy, in that if one of the recipients loses control of his durable
secret keys, but all three participants keep their mouths shut, no one else
can know what was in it. It also renders any bilateral messages linked in
immutable, because they are linked by two fifty six bit hash, thus signing a
message acknowledges sending or receiving all messages linked to by the
signed message and renders them immutable by linking them into a
hashdag.

# Name System

We need an unbreakable and untraceable name system like that Jitsi or
namecoin,  but Jitsi relies on the Ether blockchain, which is rather too
breakable. and in  the hands of the Social Justice Warriors.  Has to rely on
crypto wallet type identity keys, rather than some authority mapping names.

You need the functional equivalent of blogs, where everything published and
every approved comment on a blog gets shared BitTorrent/Usenet style – so you
and everyone has a copy on their hard disk of everything and everyone they are
following, and shares that data with everyone who follows the same entity,
with no central server.

And you need the functional equivalent of reposts and likes, so that if
someone you are following endorses what someone said, it eventually gets
downloaded, BitTorrent style, on your disk, and you get to see it, and comment
on it, also.

One minor difference you will need is that the person who issued the thing
being commented on gets to moderate the comments, though obviously this will
have no effect on comments by anyone you are already following.

A repost by someone you are following should go into your feed. His likes
should put links in your feed.  Comments on the thing reposted should put
links in your feed if they survive moderation, and the comment should go into
your feed whether moderated or not if you are already following the commenter.

You need private messages, which are easy, and we have lots of systems to
securely provide that already.

You need private groups that no outsiders can follow, except the moderator
regularly sends them  the latest keys.

# Blockchains

You need a cryptocurrency like Bitcoin, but Bitcoin is too readily traceable.
Sparrow wallet has a cure for bitcoin traceability, but it is not easy to use
that Sparrow capability, and most people will not, despite the very nice user
interface.  The lightning network over bitcoin could fix those problems, and
also overcome Bitcoin’s scaling limit, but I don’t think much of the current
implementation of the lightning network.  The latest bitcoin upgrade,
supporting Schnorr signatures and smart contracts, makes a true lightning network possible, but backwards compatibility and government pressure may prevent that from happening.

People don’t actually understand fiat money, but are plenty comfortable
when their browser tells them they have such and such an amount in their
bank.

And they don’t understand the difference between their wallet telling them
that secrets sitting in their wallet are worth such and such an amount, and
Coinbase telling them that secrets held by Coinbase, supposedly on their
behalf, are worth such and such an amount.  They do not understand this
big important difference.  But that is going to be OK if we get the user
interface done right.

A major obstacle to crypto currency taking over the world is that making
payments in crypto currency is hard.

[BTCPay] solves the problem of enabling your internet store to receive
payments directly to your own wallet, and integrates with your database,
automating the bookkeeping and stock keeping

[BTCPay]:https://docs.btcpayserver.org/WooCommerce/
"BTCPay/WooCommerce integration"

But though it is easy on internet shopkeepers, it is hard on internet
shoppers.  The fundamental user interface problem is inherent in all
existing wallets.

You navigate through a nice easy shop page, choose some goods or
services, and proceed to a BTCPay page that is well integrated with the
shop, and the BTCPay page gives you a receive address and an amount,
presented in the context of your purchase.  And then you have to launch
your wallet, and copy and paste that amount and that address into your
wallet, and tell it to pay, and when you are doing that, you are no longer
in the context of your purchase and your interaction with the internet
shopkeeper.  Your wallet does not know anything about the metadata
associated with the transaction.  Which makes it hard, and makes the
records kept by your wallet not very useful.  The wallet of the seller is
integrated into their book keeping by BTCPay, but the buyer's wallet
cannot be integrated into the buyer's bookkeeping.

The complexity and difficulty is because that we are using one rather
insecure channel for the metadata about the transaction, and a different
channel for the transaction.  (This is also a gaping and gigantic security
hole, even if you are using Monero.) For a truly usable crypto currency
payment mechanism, transactions and metadata have to go through the
same channel, which means human to human communication through
wallets - means that you need to be able to send human to human
messages containing requests for money, *and containing money*.

We can make the client wallets easier to use, and third worlders are
already using payment methods that are not that easy when they have to do
transactions over distance.

The internet tends to be unreliable in third world, and people will do
their interneting whenever it available, which is often at strange hours.

Everyone who matters in the third world sends and receives text messages.
We want to be able to implement a wallet that everyone in third world can
use, can chat to friends and people they do business with, send money to
them, and receive money from them.

If the wallet integrates an identity and messaging system, then making
payments and receiving payments over the wallet can be made easier than
with any existing system.

We have to put the medium for communication about money, for
communicating metadata about transactions, inside the wallet, as in the old
days you sent a sealed envelope containing both a cheque and a letter.
Then everyone is going to use that wrapper, owning their secrets the way
they used to own their correspondence. A third party like Coinbase will
not have a handle to get inside the transaction.

Private messages need to be able to carry the cryptocurrency embedded in
them, so that the social net is useful for business, just as you can mail a
check in an envelope with a document.  So the lightning network needs to
be an application, the primary application, of the private messaging and
private room system.

The elegant cryptography of [Scriptless Scripts] using adaptive Schnorr
signatures and of [Anonymous Multi-Hop Locks] assumes and presupposes
a lightning network that has a private room with a total order broadcast
channel (everyone in the room can know that everyone else in the room
sees the same conversation he is seeing, and a reliable anonymous
broadcast channel within the private room.  "We also assume the existence
of a functionality $F_{anon}$ which provides user with an anonymous
communication channel."

So, before we can implement a reliable anonymizing lightning network
using the elegant cryptography of these papers, have to implement a
corresponding social media capability, even though that capability is
unlikely to be competitive with Jitsi and others for purely social purposes.
Whereupon when finally we do implement a lightning network, it will
work like paper payments sealed in envelopes, which are generally
accompanied in that envelope by metadata about the human purpose and
intent of that payment and the obligations that ensue, unlike the present
lightning networks, where such metadata goes over separate and insecure
channels.

Business will move to the decentralized social net to escape the
increasingly disruptive social controls that are sending so many businesses
down the drain.  Nasa lost the ability to build rockets  because of Social
Justice (The SLS is built around rocket parts built long ago that Nasa can no
longer make).  Intel lost the ability to build CPUs because of social
justice.  (They now rely on a Taiwanese owned and operated chip fab), and
Disney destroyed to Star Wars franchise, turning it into a lecture on social
justice. Debian broke Gnome3 and cannot fix it because of social justice.

[book]:./triple_entry_accounting.html
"triple entry accounting"

Business needs a currency and [book] keeping system that enables them to
operate a business instead of a social justice crusade.

A blockchain is just a public ledger with an immense number of columns.
Triple entry [book] keeping with immutable journal entries is a narrowly
shared ledger with a considerably smaller number of columns.  Every
business needs its books on its own blockchain, to escape government
regulation of its book keeping, which public regulation tends to result in
the creation of holiness being recorded as the creation of value, as in the
Great Minority Mortgage Meltdown and MF Global.

The disruptive interference of Human Resources in hiring and firing
shows up on the books as a profit centre instead of a cost centre, and the
legal and accounting departments work for regulators and the taxman
similarly.

# Monetization

Information wants to be free, but programmers want to be paid.

An environment created to allow people to have uncensored public and
private conversations can make its creators rich if it allows businesses to
focus on creating value and making profit.

[sox]:sox_accounting.html
"Sarbanes-Oxley accounting"

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.

And then in your liquidity event, these shares would become liquid (back
in those days traded on the public stock exchange), and, if the startup was
successful, everyone gets rich.

But since [SOX] blew up that institutional and organizational structure, we
have to recreate it, before we get paid.

The intent is to recreate the organizational form that SOX destroyed, and
recreate it for ourselves before we recreate it for anyone else.

Its blockchain unit of value will be adopted by businesses and private
individuals if it allows them to message each other securely about
transactions, and if it allows businesses to keep their [book]s in ways that
reflect a focus on the creation of value and profit.

At the time I write this there is an immense amount of money in play on
Taiwan Semiconductor.  All the modern semiconductor fabs in the west
have died, because Human Resources forces them to hire people into
critical high  tech positions on the basis of race, sex, and sexual preference,
except for one company that is privately held by the King of Dubai, who
being a foreign King with his own loyal army is in a better position than
the average boss to resist political pressure.  It is easier to resist demands
from Human Resources when you have men at your back who will kill
and die for you.

There are a lot of high tech tasks where if you have a single dud member
on the team, the whole team will fail – and if you have a woman on the
team, and exclude her from the stuff she is going to wreck, you are guilty
of mansplaining, sexual harassment, and probably rape.  There will be a
big emotional scene with so much of the drama that women so love, and
even though will be absolutely obvious that the woman is disruptively
manufacturing drama, no one will admit to noticing her bad behaviour.

Censorship resistant social media is part of the necessary infrastructure
for moron resistant high tech teams, though additional infrastructure will
be needed.

[sovereign]:white_paper.html#sovereign-corporation

To maintain technology, and for business to create value, the west is going
to have to create companies that can resist political pressure.  Which
means that we are going to have to create software that enables companies,as
well as discussion groups, that can resist political pressure, their books
being triple entry [book]s with immutable entries, rather than [Sox], and
their shares traded on the blockchain instead of the quasi governmental
stock exchanges, sovereign corporations rather than state created
corporations. The software will be open source, so the programmers
cannot make money off it directly, but can make money from the
seigniorage and implementing the lightning network where such shares
will be traded in a way that gives the developers seigniorage.

[triple entry accounting]:./triple_entry_accounting.html
"triple entry accounting"

Software that enables businesses that can resist political pressure is a
superset of software than enables discussion groups that can resist political
pressure.  We start by enabling discussion groups, which will be an
unprofitable exercise, but the big money is in enabling business.
Discussion groups are a necessary first step.

## Cold Start Problem and Metcalf's law

Metcalf's law:  The usefulness of a network to any one person
considering joining it depends on how many people have already joined.

Cold Start Problem:  If no one is on the network, no one wants to be on it.

The value of joining a network depends on the number of other people already using that network.

So if there are big competing networks, no one wants to join the new network.

To solve the cold start problem, you have to start by solving a
very specific problem for a very specific set of people,
and expand from there.

No one is going to want to be the first to start a Sovcorp.  And until people do,
programmers are not going to get paid except by angel investors expecting that
people will start Sovcorps. So to get a foot in the door, we have to cherry pick
and snipe little areas where the big network is failing, and once we have a foot
in the door, then we can get rolling.

## elevator pitch:

Grab a privacy niche where Monero cannot operate, because of its inherent
lack of smart contracts and social networking capability, due to the nature of its
privacy technology.
Then take over Monero's niche by being a better Monero.
Then take over Bitcoin and Nostr's niche by being a better Bitcoin and a better Nostr,
because recursive snarks can do lots of things, such as smart contracts, better than they can.

This is the tactic that keet, holepunch, pear, and Particl are attempting to deploy, but
their software is so far unusable.  The niche is still effectively vacant and open
for the taking.

## failure of previous altcoins to solve Cold Start.

During the last decade, numberless altcoins have attempted to compete with
Bitcoin, and they all got crushed, because the differences between them and
Bitcoin really did not matter that much.

They failed to differentiate themselves from bitcoin.  They could
not find a niche in which to start.

Ether did OK, because they  supported smart contracts and Bitcoin did not,
but now that Bitcoin has some limited smart contract capability,
they are going down too, because Bitcoin has the big network advantage.

Being the biggest, it is far more convertible into goods and services
than any other.  Which means Ether is doomed now that Bitcoin is
doing smart contracts.

Monero did OK, because it is the leading privacy coin.  It has a niche, but
cannot break out of the not very large niche.  Because its privacy mechanism means it is
a worse Bitcoin than Bitcoin in other respects.

And the cold start problem means we cannot directly take over Monero's niche either.

But our proposed privacy mechanism means we have a tech advantage over both
Bitcoin and Monero - better contract capability than Bitcoin or Ether, because
a snark can prove fulfillment of a contract without burdening the network
with a costly proof of fulfillment, and without revealing everything to the
network, and without the rest of the network needing to know what that there was
a contract, what that contract is nor to be able to evaluate it.
Because of its privacy mechanism,

Monero cannot do contracts, which renders atomic exchange between Monero
and Bitcoin difficult and unduly complicated, and prevents Monero from
doing a lightning network that would enable fast atomic exchange between
itself and Bitcoin lightning.

In order to do atomic exchanges between two blockchains, which is to say,
to enable people to move value between one blockchain and another without
registering for Know Your Customer, have to have contracts on the blockchain.

In order to provide DeFi markets for the exchange of fiat for crypto currency,
have to have contracts on the blockchain.

In order to have a lightning network, have to have contracts on the blockchain.

To compete, have provide people with an off ramp and on ramp to bitcoin,
in the expectation that there will in due course the off ramp will be
a whole lot busier than the on ramp. If no contracts on the blockchain, no ramp,
making it a whole lot harder to solve Metcalfe’s law and the cold start problem.

So if we get a niche, get differentiation from Monero and Bitcoin,
we can then break out of that niche and eat Monero, being a better
privacy coin, a better Monero, and from the Monero niche eat Bitcoin,
being, unlike Monero, a better Bitcoin.

## Solving the cold start problem

### Bitmessage

The lowest hanging fruit of all, (because, unfortunately, there is
no money or prospect for money in it) is to replace Bitmessage,
Which is currently abandonware, which has ceased working on most platforms,
has never supported humanly intelligible names, and lacks the
moderation capability to grey list, blacklist, and whitelist names
on discussion groups, but is widely used
because it does not reveal the sender or recipient's IP address.

In particular, it is widely used for crypto currency payments.
So next step, after capturing its abandoned market niche,
is to integrate payment mechanisms, in particular to integrate
core lightning, which brings us a little closer to the faint smell of money.

Bitmessage is long overdue to be replaced, and Keef and Particl attempted
to replace it, as a starting point to get their respective crypto currencies of the ground
so far without success, for their software is so far even less usable and more broken
than Bitmessage.

### Integrating money

So we create our own currency.  But because it will be created on sovcorp model
people cannot obtain it by proof of work - they have to buy it.  Which
will require gateways between bitcoin lightning and the currency supported by
by the network, supporting atomic lightning exchange
and gateways between the conversations on the privacy network and the conversations on nostr.

# Development sequence

First we need a replacement for Quic, TCP, and SSL.  Quic and SSL encryption
is joined at the hip to the quasi governmental domain name system, and if
we put our custom encryption and name system on top of TCP, it is
inefficient, as SSL without Quic is inefficient, and will be dependent on
big quasi governmental organizations to protect against distributed denial of
service attacks, which will start up as soon as the social media has
important discussions, and redouble when the project starts to develop
serious monetary value.

But such a communications protocol will have no value, until there is
software that uses it to communicate, no value till there is a social media
system on top of it.

In order to communicate, it will need network addresses, and a system to
associate durable public keys with frequently changing network addresses,
though these should not have any direct one to one relationship with
durable public keys of humans, and do not always need to be very durable.

Initially we just use the equivalent of a hosts file, though as SQLite
rather than text, but this does not scale to anything useful.  For scaling,
when one computer connects to another, each learns the durable public keys
and most recent network addresses of those public keys from the other, and
if one has connections to several others, it can perform nat penetration to
allow direct connection, after the model used by Jitsi, where all
participants have a durable connection to a Jitsi meet server, which
enables them to form direct connections with each other.  Though there is
no reason why every computer should not be able to perform that role
rather than just the central server as in Jitsi meet.

If a participant does not sign the network address proposed for it by its
counterparty, perhaps because  it thinks it is incorrect, perhaps because it
thinks it likely to be far from durable, or for privacy reasons, the network
address does not get propagated through network address pooling.  So only
participants with stable network addresses and accessible ports get
propagated, get the relationship between durable key and network address
widely known, so if the network address is unstable, or no accessible port,
you can only contact directly if both connected to same third computer.
Which drastically limits the usefulness of this protocol in general, but it
works fine for propagating message pools, Usenet/BitTorrent style.  At some
time in the future we will address nameservers, with will serve names that are
recorded on the blockchain, but at this point, we do not yet have a
blockchain, and without a domain name system for network addresses and
nameservers, we cannot do much with the protocol.  And we cannot use the
quasi state domain name system, or it is going to be yanked out
underneath us as soon as we succeed.

But we can do the important things, which are social media and blockchain.

With social networking on top of this protocol, we can then do blockchain
and crypto currency.  We then do trades between crypto currencies on the
blockchain, bypassing the regulated quasi state exchanges, which trades
are safe provided a majority of the shares of peers on the blockchain that is
held by peers holding two peer wallets, one in each crypto currency being
exchanged, are honest.

This, a crypto currency and the capability to across blockchain exchanges
on our blockdag, gives us our liquidity event, enabling investors to fund
software.  At which point we start plugging all the wonderful things we are
going to do to make the currency actually useful in the near future.  Which
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 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
funds, and proper [book]s so that the board can keep an eye on the chief
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 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
blockchain.

Information wants to be free, but programmers need to be paid.   We want
the currency, the blockdag, to be able to function as a corporation so that it
can pay the developers to improve the software in ways likely to add value
to the shares.

# Many sovereign corporations on the blockchain

We have to do something about the enemy controlling speech. No
namefag can mention or acknowledge any important truth, as more
and more things, even in science, technology, and mathematics,
become political. Global warming and recent horrifying ineffective
and dangerous vaccinations are just the tip of the iceberg – every
aspect of reality is being politicized. Our capability to monitor
reality is being rapidly and massively eroded.

Among those capabilities, are bookkeeping and accounting, which
is becoming Environmental, Social, and Governance and is
increasingly detached from reality. The latter is an area of truth that
can get us paid for securing the capability to communicate truth.
Information wants to be free, but programmers want to be paid.

Increasingly, the value of shares is not physical things, but "goodwill"

Domino’s does not sell pizzas, and Apple does not sell computers. It
sets standards, and sells the expectation that stuff sold with its
brand name will conform to expectations.  Domino's does not make the
pizza dough, does not make the pizzas.  It sells the brand.  It also
organizes supply and delivery of flour, cheese, and so on and so forth
without itself producing or delivering the materials.

The latest, and one of the biggest, jewels in Apple’s tech crown, at
the time of writing, is the M1 chip. Which is *designed* by Apple. It is
not *built* by Apple. And similarly if you buy a Domino’s pizza it was
cooked according to a Domino’s recipe from Domino’s approved
ingredients. But it was not cooked in a Domino’s owned oven, was
not cooked by a Domino’s employee, and it is unlikely that any of
the ingredients where ever anywhere near Domino’s owned
physical property or a Domino’s direct employee.  Domino's does
not cook pizzas, and Apple does not build computers.  It designs
computers and set standards.

Most businesses are in practice distributed over a network, and
their capital is less and less big centralized physical things like steel
refineries that can easily be found and coerced, and more and more
“goodwill”. “Goodwill” being the network of relationships and social
roles within the corporation and between its customers and
suppliers, and customer and supplier expectations of employee
roles enforced by the corporation. *This*, we can move to the
blockchain and protect from governments.

An enterprise is not a physical thing.  It is not buildings
and machines and all that. It is a thirteenth century accounting fiction
that fourteenth century businessmen imagined into reality, in that
the group of people the accounting fiction represented acted as
one person in reality.  In the seventeenth century the Dutch and
Charles the Second created modern corporate capitalism, by merging this accounting
fiction with the Roman legal fiction of the corporation,
to create the publicly traded joint stock limited liability for profit corporation.
We now, however have postmodern capitalism, in that a multitude of "stakeholders"
are subverting its corporateness, because the legal, accounting,
and human resources have power derived from the state,
rather than the corporation, pulling the corporation apart.
With blockchains, we can return from postmodern capitalism to modern capitalism.

A huge amount of what matters, a major proportion of the value
represented by shares, is in the social network. Which is
increasingly, like Apple and Google, scarcely attached to anything
physical and coercible, and is getting less and less attached.

It mostly information, which is a present organized in a highly
coercible form. It does not have to be.

There are a whole lot of government hooks into the corporation
associated with physical things, but as more and more capital takes
the form of “goodwill”, the most important hooks in the Global
American Empire are Human Resources and Accounting.

We have to attach employee roles and brand names to individually
held unshared secrets, derived from a master secret of a master
wallet, rather than the domain name system.

With SSL, governments can, and routinely do, seize that name, but
that is a flaw in the SSL design, the sort of thing blockchains were
originally invented to prevent. The original concept of an
immutable append only data structure, what we now call, not very
accurately, a blockchain, was invented to address this flaw in SSL,
though its first widely used useful application was bitcoin. It is now
way past time to apply it to its original design purpose.

These days, most of the wealth of the world is no longer in physical
things, and increasingly companies are outsourcing that stuff to
large numbers of smaller businessmen, each of whom owns some
particular physical thing that is directly under his physical control,
and who are therefore hard for the state to coerce.  One is more
likely to get shot when one attempts to coerce the actual owner
who is physically present on his property than when coercing his
employee who is supervising and guarding his property. And who
can switch from Dominoes at the cost of taking down one sign and
putting up another. (Also at the cost of confusing his customers.)
Uber does not own any taxis, nor move any passengers, and
Dominoes bakes no pizzas. Trucking companies are converging to
the Uber model.  Reflect on the huge revolutionary problem the
Allende government got when attempting to coerce large numbers
of truckers who each owned their own truck.  The coup was in large
 part the army deciding it was easier and less disturbing to do
 something about Allende than to do something about truckers. One
 trucker is no problem.  Many truckers are a problem. One Allende …

 The value of a business is largely the value of its social net of suppliers, customers, and employee roles.  Our job is protecting social nets.  Among them, social nets who will pay us.

 And with Information Epoch warfare looming, the surviving
 governments will likely be those that are good at protecting their
 social graph information from enemies internal and external, who
 will enjoy ever increasing capability to reach out and kill one
 particular man a thousand miles away. Though governments are
 unlikely to  pay us. They are going to try to make us pay them. And
 in the end, we probably will, in return for safe locations where we
 have freedom to operate. Which we will probably lease from
 sovereign corporations who leased the physical facilities from
 small owners, and the freedom to operate from governments.

## source of corporateness

State incorporated corporations derive their corporateness from the
authority of the sovereign, but a proof of share currency derives its
corporateness from the cryptographically discovered consensus that gives
each shareholder incentive to go along with the cryptographically
discovered consensus because everyone else is going with the consensus,
each shareholder playing by the rules because all the other shareholders
play by those rules.

Such a corporation is sovereign.

## shares, bookkeeping, and sidechains

We then implement sidechains, so that many sovereign corporations will
have some place to trade their shares and to keep the narrowly shared
immutable journals for their triple entry [book]s.  The shares will be on a
broadly shared blockchain, but some aspects of the books may well be
very narrowly shared and selectively revealed. A total order of a sidechain
will be reflected in a total state of the main chain, through the total state of
peers that are also managing side chain wallets, or who have clients (or
clients of clients) and that are managing side chain wallets, and each
client’s total order is Merkle linked into the client’s total state, which is
Merkle linked into the peer’s total state, so that the main block chain
contains a Merkle link that can prove that machines operating a sidechain
are in agreement about a total order for transactions that happened a little
time ago.  The total order of transactions on a sidechain will be the order in
which they get linked into the mainchain.

If a peer on a sidechain is a client of a client of a client of a peer on the
mainchain, and adds some new transactions to its sidechain wallet, the
total order of those transactions within the sidechain is the order in which
the main chain gives that total state of the mainchain peer, and within that
order the order that the peer gives the total state of the client, and within
that order …

This does not occupy mainchain space, because a single two fifty six bit
hash on the mainchain can represent to the total state and total order of
many very large sidechains, with the very large preimage of the hash being
known to peers on the sidechain, but not to peers on the mainchain unless
they are also peers on the sidechain.

A two fifty six bit hash gives unlimited compression, which is lossy in the
sense that it is one way compression, but lossless in that if you know the
preimage, you can always verify that the hash must have been made from
that preimage, and a hash that is the root of a Merkle tree of two fifty
six bit hashes gives the same, but with the added benefit that one can generate
a short proof that some part of the preimage, possibly a very small part of
a vast preimage, a part so small that it fits in single network packet, but
part of a preimage so vast that no one possesses all of it, that no one could
possess all of it, was part of the data from which that hash was generated.

And, associated with the current root of the merkle dag will be a
recursive snark that proves that someone verified a proof that
each path through the dag conformed to the requirements for that path --
even if these requirements are known to very few people.

The mainchain is a Merkle dag, structured in a way that makes it possible
to give a single total order for the gossip vertexes of which it is composed,
and every gossip vertex in the dag is a Merkle tree that reflects, among
other things, a total state of two peers on the blockchain, each total state of
a peer being incorporated in one and only one gossip event,  and every total
state of a peer contains Merkle tree that reflects the prior state of the
blockchain, and the state of its clients who want their current state
committed to the blockchain, and thus whenever one party wants to prove
to another party that he is telling the same story to all the parties involved
(has not engaged in Byzantine failure) he can generate a short proof rooted
in the mainchain.  Thus shares and triple entry books will be in the
mainchain, even though much of the information in the books is going to
be private and narrowly shared. Whenever one man’s computer presents
something from the [book]s to another man’s computer, it will present a
short proof rooted in the blockchain, rooted in the same hash that everyone
can see and vast numbers of people do see, that it is telling the same story
to anyone it tells, even if only very few people should be told.

What should happen is that every time you make a payment to a business,
you get a receipt that is connected by a Merkle chain to a Merkle tree of
the business’s narrowly shared books, which is connected by a Merkle
chain to the broadly shared main blockchain.

[Sox] bookkeeping relies on the books being widely shared among
supposedly respectable and highly regulated people, which does not help
you much if, as in the Great Minority Mortgage Meltdown, the regulators
are engaged in evil deeds, or if, as with Enron and MF Global, the
accountants are all in the pay of powerful men engaged in evil deeds.
Triple entry [book keeping] with immutable journal entries works in a low
trust world of badly behaved elites, works in the circumstances now
prevailing, and, unlike Sox accounting, it does not require wide sharing of
the books.

## Corporate cohesion

The corporation exists by [book keeping], which enables the shareholders to
keep an eye on the board, and the board to keep an eye on the CEO, and our
current system of bookkeeping is failing for lack of trust and honour.

Corporate cohesion is hard and apt to be fragile.  You are apt to have board
members that want to participate in executive decisions, want to tell the
CEO what to do instead of merely evaluating how well he is doing it and
making sure he is not stealing from the shareholders, and executives that
have a power base external to the company.  And telework and video
conferencing does not make this any easier.

But while the purchasing officer who is too pally with certain suppliers is
always a natural and inevitable problem, and your lawyer apt to be too
well connected to the judge and the other guy’s lawyers, the big problem
today with state created corporations is that the meddling of the state gives
HR, accounting, and the legal department power bases external to the
company, undermining corporate cohesion.  If HR does not get its way, it is
apt to organize lawsuits against the CEO, board, and shareholders.

Things can easily fall apart, and a cohesive group of people within the
company is apt to push on those fault lines.

Corporate cohesion is hard, but the regulatory state is making it harder.
Sovereignty will improve the capability of corporations to cohere, because
the CEO really will be able to fire anyone, the board really able to fire the
CEO, and shareholders really able to fire the board.

And, with the corporate [book]s better connected to reality, the shareholders
will have better information on whether to do so.  A necessary precondition
for corporations to function at all is that we fix bookkeeping to work in a
world of untrustworthy elites.

## share holding and trading

It used to be the case that shares were a direct relationship between the shareholder and the company.
The company issued a certificate directly to the shareholder.  That was the modern corporate capitalism
of Charles the Second, and it still existed within living memory, within my memory.

Today, in postmodern capitalism, there is a custodian in the middle.
You do not own shares. You own promises made by big finance.
And as we saw in the Gamestop shenanigans,
there can be a very big difference between these two things.

Gamestop was trying to raise money from its shareholders for a change in business plan.
The net effect of these shenanigans was that most of the money went into the pockets of
people in big finance running the stock exchange.

As our elites become ever less trustworthy, and we trust them ever less,
they insist on systems that force us to give them ever more trust.

As elite virtue collapses, we strangely find ourselves forced to rely on systems that
strangely become ever more reliant on elite virtue.
Custodial shares to money and investment what absentee voting is to elections.

The corporate form needs to be put on blockchains, so that your shares are
owned through private secrets derived from each party's master secret.

The financial businesses of the stock exchange are creaming off a vast amount of wealth.

Information wants to be free, but programmers want to paid.  If we liberate corporations
and shareholders from this tyranny, we can arrange for a very small part of this mountain
of wealth to stick to us.  And a very small part of this mountain is still a mighty big
mountain.