forked from cheng/wallet
1069 lines
57 KiB
Markdown
1069 lines
57 KiB
Markdown
---
|
||
title:
|
||
Social networking
|
||
...
|
||
# the crisis of censorship
|
||
|
||
We have a crisis of censorship.
|
||
|
||
Every uncensored medium of public discussion is getting the treatment.
|
||
|
||
We need a pseudonymous social network on which it is possible to safely
|
||
discuss forbidden topics.
|
||
|
||
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, most of them about
|
||
money rather than politics.
|
||
|
||
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 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
|
||
have instead for its repository name system a Kamelia distributed has
|
||
table within which local repositories 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.
|
||
|
||
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 committed 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.
|
||
|
||
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.
|
||
|
||
This handles public posts.
|
||
|
||
## 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.
|
||
|
||
In order to do money over a private room, you need a `reliable 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 reliable broadcast in private rooms,
|
||
and is generally used in ways and for purposes that do not need it. And
|
||
anything that does implement reliable 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 reliable 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. 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.
|
||
Wasabi wallet has a cure for bitcoin traceability, but it is not easy to use
|
||
that Wasabi 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 Monaro.) 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 reliable 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.
|
||
|
||
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 stake 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"
|
||
|
||
[book]:./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.
|
||
|
||
# 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 stake 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 stake 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 stake 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 stake.
|
||
|
||
# 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.
|
||
|
||
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. 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.
|
||
|
||
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 stake 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,
|
||
each stakeholder playing by the rules because all the other stakeholders
|
||
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.
|
||
|
||
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.
|