wallet/docs/social_networking.md

-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 Kademlia distributed hash -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.

-So the hashes of identities are tracked by the distributed hash table, but the -hashes of posts are not, because that would result in excessive numbers of -lookups in a table that would very quickly hit its scaling limits. The hashes -of posts are tracked by the repository of the feed that you are looking at, so -require only local lookup, which is faster and less costly than a distributed -lookup. This is equivalent to a fully distributed hash table where the key is -not hash of post, but global name of area of interest, zooko nickname, -zooko public key followed by his human readable thread name (branch -name or tag name in git terminology) followed by hash of post, so that -items that are likely to be looked up together are likely to be located -physically close together on the same disk and will be sent along the same -network connection.

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

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.

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.

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

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.

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 books 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.

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 books 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.

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 books 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 books. 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 books 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 bookkeeping 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 bookkeeping, 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 books 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.