685 lines
37 KiB
Markdown
685 lines
37 KiB
Markdown
---
|
||
title:
|
||
Proof of Stake
|
||
---
|
||
::: {style="background-color : #ffdddd; font-size:120%"}
|
||
![run!](tealdeer.gif)[TL;DR Map a blockdag algorithm equivalent to the
|
||
Generalized MultiPaxos Byzantine
|
||
protocol to the corporate form:]{style="font-size:150%"}
|
||
|
||
The proof of stake crypto currency will work like
|
||
shares. Crypto wallets, or the humans controlling the wallets,
|
||
correspond to shareholders.
|
||
Peer computers in good standing on the blockchain, or the humans
|
||
controlling them, correspond to company directors.
|
||
CEO.
|
||
:::
|
||
|
||
We need proof of stake because our state regulated system of notaries,
|
||
bankers, accountants, and lawyers has gone off the rails, and because
|
||
proof of work means that a tiny handful of people who are [burning a
|
||
whole lot of computer power]
|
||
control your crypto money. Apart from being wasteful, they don’t
|
||
necessarily have your best interests at heart, producing a bias towards
|
||
inflation as in Monero, and/or high transaction fees as in Bitcoin.
|
||
|
||
[burning a whole lot of computer power]: https://news.bitcoin.com/businessman-buys-two-electric-power-stations-to-do-bitcoin-mining-in-russia/
|
||
|
||
The entire bitcoin network
|
||
[currently consumes just over 46 terawatt hours of energy every year].
|
||
This is almost as much as the annual energy consumption of Portugal,
|
||
with its population of roughly 10 million. Simply settling a transaction
|
||
in the bitcoin network consumes around 427 kilowatt hours. This amount
|
||
of energy is enough to supply an average German four-person household
|
||
with electricity for more than a month.
|
||
|
||
[currently consumes just over 46 terawatt hours of energy every year]: https://arstechnica.com/tech-policy/2018/02/european-bankers-scoff-at-bitcoin-for-its-risk-huge-energy-inefficiency/
|
||
|
||
Notaries, bankers, accountants and lawyers, are professionals whom
|
||
people hire because they don’t trust each other. They are in the trust
|
||
business. And then there is some failure of trust, some bad behavior,
|
||
as for example Enron’s accounting, and then they turn to the government
|
||
to make trust mandatory, whereupon due to regulatory capture and the
|
||
malincentives of the state, the untrustworthy behavior becomes standard
|
||
and compulsory.
|
||
|
||
[Sarbanes-Oxley] was the response to the misconduct of Enron’s
|
||
accountants, and was theoretically intended to make behavior similar to
|
||
that of Enron’s accountants forbidden, but the practical consequence was
|
||
that in substantial part, it made such behavior compulsory. Which is
|
||
why Gab is now doing an Initial Coin Offering (ICO) instead of an
|
||
Initial Public Offering (IPO).
|
||
|
||
[Sarbanes-Oxley]:sox_accounting.html
|
||
"Sarbanes-Oxley accounting"
|
||
|
||
Because current blockchains are proof of work, rather than proof of
|
||
stake, they give coin holders no power. Thus an initial coin offering
|
||
(ICO) is not a promise of general authority over the assets of the
|
||
proposed company, but a promise of future goods or services that will be
|
||
provided by the company. A proof of stake ICO could function as a more
|
||
direct substitute for an initial public offering (IPO). Thus we want it
|
||
to be easy to issue your own coins, and [to perform coin swaps between
|
||
chains without the need for an exchange] that would provide a potential
|
||
target for regulation.
|
||
|
||
[to perform coin swaps between chains without the need for an exchange]: ./contracts_on_blockchain.html#atomic-swaps-on-separate-blockchains
|
||
|
||
The block chain, an immutable append only data structure, is a
|
||
replacement for public notaries, and on that foundation of public
|
||
notarization, we can and should recreate banking, the corporate form,
|
||
accounting, and, eventually, lawyering, though the Ethereum attempt to
|
||
build lawyering is premature and wicked. We will not be able to build
|
||
lawyering until the crypto currency system is well established and has a
|
||
good reputation and record system linked to it, and attempting to build
|
||
lawyering into it prematurely will result in bad conduct.
|
||
|
||
The blockchain governed by proof work is failing. We need a better
|
||
solution for notarizing, based on some form of Paxos, and on that better
|
||
system of notarizing, we should build banking. And on that banking, the
|
||
corporate form, and on that corporate form, accounting. We will worry
|
||
about lawyering and justice at some much later date, after crypto
|
||
currency values stabilize.
|
||
|
||
We build public notarization, then build money on top or that. When
|
||
that is working and stable, we promptly build accounting and a
|
||
replacement of the joint stock corporation, which replacement for the
|
||
joint stock corporation will manifest as the “Initial coin offering”,
|
||
like Gab’s initial coin offering.
|
||
|
||
The business of Enron’s accountants failed because no one trusted them
|
||
any more.
|
||
|
||
Facing massive loss of trust in the wake of the Enron scandal,
|
||
accountants rushed to the government, and demanded the government
|
||
provide them with mandatory state supplied and state enforced trust, and
|
||
got [Sarbanes-Oxley], with the result that they failed upwards instead of
|
||
downwards. This created a situation where it is impossible for a mid
|
||
sized company to go public. So venture capitalists, instead of having
|
||
an initial public offering of a successful venture, attempt to sell the
|
||
successful venture to Google. Hence Gab’s Initial Coin Offering.
|
||
Google will not buy them, for obvious reasons, and they cannot do an
|
||
initial public offering, because of [Sarbanes-Oxley], hence the initial
|
||
coin offering.
|
||
|
||
Actually existent governments and bankers are evil and untrustworthy,
|
||
and the burdens of using trust mediated by bankers and governments to do
|
||
business are rapidly becoming intolerable. Accounting and HR have
|
||
become vast onerous bureaucracies, burdensome tentacles of the state in
|
||
every business, making businesses larger than a family and smaller than
|
||
giant multinational corporation with a skyscraper full of Harvard
|
||
lawyers each drawing \$300 per hour, increasingly impractical.
|
||
|
||
Proof of work is a terrible idea, and is failing disastrously, but we
|
||
need to replace it with something better than bankers and government.
|
||
|
||
The gig economy represents the collapse of the corporate form under the
|
||
burden of HR and accounting.
|
||
|
||
The initial coin offering (in place of the initial public offering)
|
||
represents an attempt to recreate the corporate form using crypto
|
||
currency, to which existing crypto currencies are not well adapted.
|
||
|
||
The corporate form is collapsing in part because of [Sarbanes-Oxley],
|
||
which gives accountants far too much power, and those responsible for
|
||
deliverables and closing deals far too little, and in part because HR
|
||
provides a vector for social justice warriors to infect corporations.
|
||
|
||
When a corporation goes social justice it abandons its original
|
||
functions, and instead dedicates itself, its resources and the wealth of
|
||
its share holders full time to infecting other corporations with social
|
||
justice, like a zombie turning those still living into zombies.
|
||
|
||
I have been working on the problem of creating a crypto currency well
|
||
adapted for this purpose, and what I conclude always implies pre-mining,
|
||
that existing owners of a crypto currency shall be like shareholders in
|
||
an existing business, transferring shares between each other.
|
||
|
||
Which immediately leads us to the idea of a mass of competing
|
||
currencies, with share swaps – which automatically has scalability,
|
||
particularly if one some of these crypto corporations have as their
|
||
major asset shares in the main currency, and a system of enforcement
|
||
that makes it difficult for some shareholders to steal that dangerously
|
||
liquid asset from other shareholders, in which case they are sidechains,
|
||
rather than separate shares systems.
|
||
|
||
Western civilization is based on double entry accounting, the joint
|
||
stock corporation, and the scientific method, all of which have come
|
||
under massive attack.
|
||
|
||
Crypto currencies need to make accounting and corporations workable
|
||
again, and are needed for this purpose.
|
||
|
||
The joint stock corporation has always existed, and our earliest records
|
||
of them come from the time of the Roman Empire in the West, but before
|
||
Charles the Second they were grants of Kingly power to private
|
||
individuals for state purposes – they were socialism.
|
||
|
||
Under Charles the Second, they were still theoretically socialism, but
|
||
now it was expected and high status to get rich in the course of
|
||
pursuing state purposes, socialism similar to “Socialism with Chinese
|
||
characteristics” which is not very socialist at all, or “The party
|
||
decides what communism is”, which is not very communist at all.
|
||
|
||
Under Charles the second we first see the Randian Hero Engineer Chief
|
||
executive officer, using other people’s money and other people’s labour
|
||
to advance technology and apply technological advance to the creation of
|
||
value. There was a sort of Silicon Valley under Charles the second, but
|
||
instead of laying down optical fibre they were laying down canals and
|
||
conquering the Indies.
|
||
|
||
During late Victorian times, we see the corporation become wholly
|
||
private. Corporations are now people, a situation parodied by Gilbert
|
||
and Sullivan – but at the same time, we see the regulatory state
|
||
rendering them socialist again by the back door, a problem starting in
|
||
Victorian times, and now getting out of control.
|
||
|
||
Human Resources has long been an ever more burdensome branch of the
|
||
socialist state inserted parasitically into every business, and
|
||
[Sarbanes-Oxley] has now destroyed double entry accounting, which is
|
||
fundamental to the survival of western civilization.
|
||
|
||
Under [Sarbanes-Oxley], the tail wags the dog. Instead of monitoring
|
||
actual reality, accounting decides on official reality.
|
||
|
||
Power in business has been taken out of the hands of those who provide
|
||
the capital, those responsible for closing deals, and those responsible
|
||
for deliverables, and into the hands of Accounting and Human Resources,
|
||
who have government granted power to obstruct, disrupt, delay, and
|
||
criminalize those responsible for providing capital, those responsible
|
||
for closing deals, and those responsible for deliverables.
|
||
|
||
We need to construct crypto currency around this function. The original
|
||
intent was for buying drugs, buying guns, violating copyright, money
|
||
laundering, and capital flight.
|
||
|
||
These are all important and we need to support them all, especially
|
||
violating copyright, capital flight and buying guns under repressive
|
||
regimes. But we now see big demand for crypto currencies to support a
|
||
replacement for Charles the Second’s corporate form, which is being
|
||
destroyed by HR, and to restore double entry accounting, which is being
|
||
destroyed by [Sarbanes-Oxley].
|
||
|
||
[Sarbanes-Oxley] is more deeply immoral than forcing doctors to perform
|
||
abortions, forcing businesses to pay for abortions, and forcing males to
|
||
pay for abortions by single women with whom they have no relationship
|
||
through “free” medical care.
|
||
|
||
People lost their trust in accountants, so accountants went to the
|
||
government, and asked the government to force corporations to act as if
|
||
they trusted accountants – which undermines the cooperation and good
|
||
behavior on which our economy is based, by undermining the accounting
|
||
system that distinguishes positive sum behavior from negative sum
|
||
behavior, the accounting system that tracks the creation of value. This
|
||
makes the entire crypto anarchy black market program legitimate and
|
||
necessary. We are morally obligated to obey a government that supports
|
||
our civilization and holds it together, keeping peace and order,
|
||
defending the realm from enemies internal and external, protecting the
|
||
property of taxpayers, enforcing contracts, and honoring warriors. We
|
||
are not morally obligated to obey a hostile regime that seeks to destroy
|
||
western civilization. If the state will not uphold trust, cooperation,
|
||
and positive sum behavior, we must find other ways. Undermining
|
||
accounting undermines cooperation.
|
||
|
||
Used to be that the state church was the state church. Then Education
|
||
media complex was the State Church, Harvard seamlessly transitioning
|
||
from being the headquarters of the State Church of New England, to being
|
||
the headquarters of the American Empire running the entire Education
|
||
Media complex of most of the world.
|
||
|
||
Now the social media are the state church.
|
||
|
||
This is a problem because the unofficially official state belief system
|
||
is more and more out of touch with reality, resulting in an increasingly
|
||
oppressive social media, that continually censors and bans an ever
|
||
increasing number of people for an ever increasing number of crime
|
||
thoughts. Thus we need for an anarchic and chaotic social media system
|
||
to oppose and resist it. We need the chans, and things like the chans.
|
||
|
||
If we had a saner and more functional state belief system, one that did
|
||
not compel belief in so many egregious lies, and force so many
|
||
compelled affirmations of egregious point-deer-make-horse lies, then it
|
||
would be right to repress a chaotic, chan style, darknet style social
|
||
media system. If the state church was sane, then censorship to support
|
||
the state belief system would be morally justified, and resisting it
|
||
morally wrong, but because the quasi state social media are egregiously
|
||
untruthful and therefore egregiously repressive, anarchic and chaotic
|
||
social media is morally justified and necessary.
|
||
|
||
Our system of client wallets needs to support the minimum chat system
|
||
necessary to agree to transfer of value to value, and to support
|
||
lightning networks to prevent traceability, but we need to architect it
|
||
so that wallets are potentially capable of becoming a social media
|
||
platform. This capability is not part of the minimum viable product, and
|
||
will not be part of early releases, but the minimum viable product needs
|
||
to be able to support and prove conversations comprising a contract to
|
||
exchange value. Design of the minimum viable product needs to be done in
|
||
a way that supports the future capability of wallets supporting general
|
||
conversations similar to the chans. If the state church had stuck to
|
||
commanding people to believe that God is three and God is one, no one
|
||
can prove anything different, but when the state church commands us to
|
||
believe that blacks are being unfairly targeted by police, and therefore
|
||
quotas limiting arrests of minority groups are totally justified, and
|
||
simultaneously totally nonexistent, not only can we prove something
|
||
different, but if we were to believe the official truth and official
|
||
science that are social media requires us to believe, are likely to get
|
||
killed, thus today’s state church is necessarily more repressive than it
|
||
was back when it was openly a a state church. God being both three and
|
||
one is harder to falsify than arrest quotas being both morally
|
||
obligatory and nonexistent, thus higher levels of repression are
|
||
required to enforce official belief.
|
||
|
||
When the state religion was transliterated from the next world to this,
|
||
it became readily falsifiable, resulting in the necessity of disturbing
|
||
levels of repression, to which repression crypto anarchy is the morally
|
||
appropriate response. With a saner state religion, crypto anarchy would
|
||
be a morally objectionable attack on order and social cohesion, but the
|
||
current officially unofficial state religion is itself a morally
|
||
objectionable attack on order and social cohesion. Hence we need a
|
||
distributed system of wallet to wallet encrypted chat with no
|
||
monopolistic center. In the minimum viable product we will not attempt
|
||
to compete with chat and social media, but we need to have the ability
|
||
to discuss payments in wallets, with no monopolistic
|
||
center, and will set this up in a way compatible with future expansion
|
||
to a future challenge against current social media. In war, all things
|
||
are permitted, and the state is making war on society. A minimum system
|
||
that allows people to pay each other unsupervised
|
||
is not very different from a centreless system that allows people to
|
||
associate to discuss any hate fact, nor very different from a centerless
|
||
lightning network.
|
||
|
||
# General structure
|
||
|
||
The blockchain is managed by the peers. Peers are fully accessible on
|
||
the internet, in that they have a port that one can receive UDP messages
|
||
from any peer or any client on the internet. If they are behind a NAT,
|
||
the port is forwarded to them by port forwarding, a load balancer, or
|
||
failover redirection. Each peer keeps a copy of the entire blockchain.
|
||
Clients only keep a copy of the data that is relevant to themselves, and
|
||
are commonly behind NATs, so that their communications with each other
|
||
must be mediated by peers.
|
||
|
||
The blockchain contains data linked by hashes, so that any peer can
|
||
provide any client with a short proof that the data supplied is part of
|
||
the current global consensus, the current global consensus being
|
||
represented by a short hash, which is linked to every previous global
|
||
consensus. This chain of hashes ensures that the record of past events
|
||
is immutable. Data can be lost, or can become temporarily or permanently
|
||
inaccessible, but it cannot be changed. The fundamental function of the
|
||
blockchain is to function as a public notary, to ensure that everyone
|
||
sees the same immutable story about past events. The hash dag is
|
||
structured so that a peer can also produce a short proof to a client
|
||
that it has presented all events, or the all the most recent events,
|
||
that relate to a given human readable name or a given public key. For
|
||
the hash dag to be capable of being analysed with reasonable efficiency,
|
||
the hash dag must correspond to a very small number of approximately
|
||
balanced Merkle trees
|
||
|
||
In order to produce short proofs that can be proven to contain all
|
||
transactions relevant to a given key or human readable name, there have
|
||
to be Merkle-patricia trees organized primarily by block number, but
|
||
also Merkle trees organized by key and by name, and the root hash of the
|
||
current consensus has to depend on the root hash of each of these three
|
||
trees, and all past versions of these trees, the root hashes of all past
|
||
consensuses. The blockchain will contain a Merkle-patricia dag of all
|
||
unspent transaction outputs, and all spent transaction outputs, enabling
|
||
a short proof that a transaction output was spent in block it, and that
|
||
as of block n, a another transaction output was not yet spent.
|
||
|
||
In order to produce a short proof, the consensus of the block chain has to
|
||
be organized a collection of balanced binary Merkle trees, with the state of
|
||
the consensus at any one point in time being represented as the list of roots
|
||
of the Merkle trees.
|
||
|
||
This enables people with limited computing power and a quite small
|
||
amount of data to prove that the state of the consensus at any one time for
|
||
which they have that quite small amount of data, includes the consensus at
|
||
any earlier time for which they have that quite small amount of data.
|
||
|
||
We need this capability because at scale, full peers are enormous and have
|
||
and handle enormous amounts of data, so we wind up with few peers and
|
||
an enormous number of clients, and the clients need to be able to monitor
|
||
the peers to resist being scammed.
|
||
|
||
Clients need the capability to know that at any moment, the current
|
||
consensus of the peers includes that past in which value was committed to
|
||
public keys on the blockchain whose secrets he controls.
|
||
|
||
We build a system of payments and globally unique human readable names
|
||
mapping to [Zooko’s triangle] names (Zooko’s quadrangle) on top of this
|
||
public notary functionality.
|
||
|
||
[Zooko’s triangle]: ./zookos_triangle.html
|
||
|
||
All wallets shall be client wallets, and all transaction outputs shall
|
||
be controlled by private keys known only to client wallets, but most
|
||
transactions or transaction outputs shall be registered with one
|
||
specific peer. The blockchain will record a peer’s uptime, its
|
||
provision of storage and bandwidth to the blockchain, and the amount of
|
||
stake registered with a peer. To be a peer in good standing, a peer has
|
||
to have a certain amount of uptime, supply a certain amount of bandwidth
|
||
and storage to the blockchain, and have a certain amount of stake
|
||
registered to it. Anything it signed as being in accordance with the
|
||
rules of the blockchain must have been in accordance with the rules of
|
||
the blockchain. Thus client wallets that control large amounts of stake
|
||
vote which peers matter, peers vote which peer is primus inter pares,
|
||
and the primus inter pares settles double spending conflicts and
|
||
suchlike.
|
||
|
||
In the classic Byzantine Fault Resistant algorithms, the leader is decided
|
||
prospectively, and then decides the total order of all transactions. In a
|
||
blockdag algorithm, the leader is determined retrospectively rather than
|
||
prospectively. Each peer in each gossip event (each vertex of the dag)
|
||
makes a decision that implies a total order of all transactions, which
|
||
decisions are unlikely to agree, and then which vertex is the one that
|
||
actually does set the total order i decided retrospectively, equivalent to
|
||
continuous retrospective leader election in the classic Byzantine fault
|
||
resistant algorithms.
|
||
|
||
Proof of stake works like the corporate form, or can work like the
|
||
corporate form, with the crypto currency as shares, the wallets, or the
|
||
humans controlling the wallets, as shareholders, the peers in good
|
||
standing, or the humans controlling the peers in good standing as the
|
||
board, and the primus inter pares, or the human controlling the primus
|
||
inter pares, as the CEO.
|
||
|
||
Thus the crypto currency works, or can work, like shares in a
|
||
corporation. Proof of stake means that the shareholders can less easily
|
||
be screwed over, since the shareholders elect the board from time to
|
||
time, and the board elects the CEO from time to time to time.
|
||
|
||
But we need many corporations, not just one. OK, each crypto
|
||
corporation corresponds to a sidechain, with its primus inter pares as a
|
||
named peer on the mainchain. Buying and selling shares corresponds to
|
||
swapping shares. The mainchain, if all goes well, has the special
|
||
privilege of being the source of root names, and its shares are the most
|
||
liquid, the most readily exchangeable, and this is the primary thing
|
||
that makes it “main”.
|
||
|
||
# Implementation of proof of stake
|
||
|
||
Good blockdag protocols with high consensus bandwidth rely on forming
|
||
a consensus about the total past of the blockchain during the gossip
|
||
protocol where they share transactions around.
|
||
|
||
During gossip, they also share opinions on the total past of the blockchain.
|
||
|
||
If each peer tries to support past consensus, tries to support the opinion of
|
||
what looks like it might be the majority of peers by stake that it sees in
|
||
past gossip events, then we get rapid convergence to a single view of the
|
||
less recent past, though each peer initially has its own view of the very
|
||
recent past.
|
||
|
||
Blockdag algorithms of this class of consensus algorithm, if correct and
|
||
correctly implemented, are equivalent to Practical Byzantine Fault
|
||
Tolerant Consensus with continuous leader election, with the important
|
||
differences being that the the leader is elected retrospectively rather than
|
||
prospectively, with later peers deciding whom the past leader was and
|
||
adopting his opinion of the total past, rather than whom the next leader
|
||
will be, and if consensus fails to happen, we get a fork, rather than the
|
||
algorithm stalling. The one third limit is fork detection, which is not quite
|
||
the same thing as the one third limit in Practical Byzantine Fault Resistant
|
||
Consensus, though in a sense equivalent, or closely related.
|
||
|
||
Satoshi’s design for bitcoin was that every wallet should be a peer on the
|
||
mainchain, every peer should be a miner.
|
||
|
||
In Satoshi’s design every peer needs to be a miner, and every wallet a peer,
|
||
because that is where the power is. If you don’t have power over your money,
|
||
going to get ripped off and oppressed one way or the other way.
|
||
|
||
This design fell apart under scaling pressure, with there being two or perhaps
|
||
three mining pools that control the blockchain, a massively centralized
|
||
system, and people are increasingly reliant on client wallets and exchanges in
|
||
a system never designed to securely support client wallets or exchanges,
|
||
leading to notorious exchange failures and ripoffs. Getting miners to validate
|
||
your transactions is slow and expensive, and getting slower and more
|
||
expensive. The lightning network is likely to wind up with all transactions
|
||
going through two big exchanges, as credit card transactions do.
|
||
|
||
Wallets are by Satoshi’s design linked to output keys. And now every exchange
|
||
demands to see your face and evidence of your true name. What I am seeing now
|
||
is scaling failure and anonymity failure.
|
||
|
||
Bitcoin has failed due to scaling problems, resulting in high costs of
|
||
transactions, high delay, heavy use of client wallets in a system in which
|
||
client wallets are inherently unsafe, heavy use of exchanges in a system where
|
||
exchanges are inherently unsafe.
|
||
|
||
For scaling, we need to design a system with a limited number of peers, more
|
||
than a dozen, less than a thousand, and an enormous number of client wallets,
|
||
billions of client wallets. And we need to give client wallets power and
|
||
prevent the peers from having too much power.
|
||
|
||
Power to the wallets means our system has to run on proof of stake, rather
|
||
than proof of work. But since a wallet is not always on the internet, cannot
|
||
routinely exercise power moment to moment. So, we need a system where unspent
|
||
transaction outputs are hosted by particular blockchain peers, or large
|
||
transaction outputs are hosted by particular peers, but controlled by client
|
||
wallets, and the power of a peer depends on hosting sufficient value.
|
||
|
||
The architecture will be somewhat similar to email, where you run an email
|
||
client on your computer, whose server is an email agent somewhere out in the
|
||
internet. An email agent is a peer in relation to other email agents, and a
|
||
host and server in relation to your email client.
|
||
|
||
Wallets will rendezvous with other wallets through peers, but the peer will set
|
||
up a direct connection between wallets, where wallets send encrypted packets
|
||
directly to each other, and the peer cannot know what wallets are talking to
|
||
what wallets about what transactions. By analogy with email agents, we will
|
||
call peers on the blockchain blockchain agents when they perform the role of
|
||
servicing wallets, but, following the tradition established by Satoshi, peers
|
||
when they perform the role of cooperating with each other to operate the
|
||
blockchain.
|
||
|
||
The blockchain will be a directed acyclic graph indexed by Merkle trees. Being
|
||
a directed acyclic graph, the peers will have to download and process the
|
||
entire blockchain. The Merkle trees will be approximately balanced, thus of
|
||
depth of order log N, hence a blockchain agent can provide a wallet a short
|
||
chain of hashes linking any fact about the blockchain to the current root of
|
||
the blockchain.
|
||
|
||
A wallet has a login relationship to a blockchain agent, which is a peer to
|
||
all the other blockchain hosts on that blockchain, just as an email client has
|
||
a login relationship with an email agent. A wallet is the client of its
|
||
blockchain agent. Your wallet client will be software and a user interface
|
||
that manages several wallets. Thus a wallet will be like an email account,
|
||
which has a single login relationship with a single host, and your wallet
|
||
client, which may manage several wallets, is like an email client, which is
|
||
the client of an email agent or a small number of email agents.
|
||
|
||
What then stops the blockchain agent from lying to the wallet about the root
|
||
and contents of the blockchain?.
|
||
|
||
Wallets perform transactions by interacting directly with other wallets
|
||
through an encrypted connection. [If both wallets are behind a firewall the
|
||
connection is set up by servers, but it does not pass through the servers]
|
||
(how_to_punch_holes_in_firewalls.html). For the interaction to succeed, for a
|
||
transaction to go through, both wallets must have the same Merkle root for the
|
||
blockchain, or one Merkle root must be a recent subsidiary of the other. The
|
||
wallet receives a short proof (log N hashes where N is the number of events on
|
||
the block chain in the last few months) that proves that the past that Bob’s
|
||
wallet received from its peer is part of the same past as the past that Ann’s
|
||
wallet received from her peer, that both wallets are on the same blockchain,
|
||
that the data about the past that one wallet has is consistent with the data
|
||
about the past that the other wallet has.
|
||
|
||
Sometimes a wallet name will be a Zooko name, consisting of a public key,
|
||
secret key, nickname, and petname. Sometimes it will also have a globally
|
||
unique human readable name controlled by a Zooko name. Peers will usually have
|
||
globally unique human readable names controlled by a Zooko name human.
|
||
However, wallets will most commonly have login names, `wallet_name@peer_name`.
|
||
All transaction outputs and inputs have an associated secret key, and the
|
||
hash of the transaction must be signed by Schnorr multisignature of all the
|
||
inputs.
|
||
|
||
Wallets should retain not the full block chain, but relevant transactions and
|
||
outputs, and for each transaction and output, log N hashes connecting that to
|
||
hashes close to the root.
|
||
|
||
Peers check the entire blockchain for validity, and construct short proofs
|
||
showing to wallets that they are seeing the same view of those facts that they
|
||
care about are the same for everyone, that the past does not get rewritten,
|
||
and every wallet on the same blockchain sees the same past. Wallets only
|
||
download short and relevant parts of the blockchain.
|
||
|
||
Peers on the blockchain are not
|
||
behind NATS, or if they are they have port forwarding, or some similar NAT
|
||
penetration set up. One wallet sets up a connection to another wallet through
|
||
a peer, but once the connection is set up, information does not pass through
|
||
the peer, but rather information is sent directly from wallet to wallet. The
|
||
peer negotiates a port for two wallets that wish to communicate and informs
|
||
each of the other’s external IP address. It also negotiates a shared secret,
|
||
and informs each wallet of the id associated with the shared secret. Both
|
||
parties send off introduction UDP packets to the other’s IP address and port
|
||
number – thereby punching holes in their firewall for return packets. When
|
||
they get a return packet, an introduction acknowledgement, the connection is
|
||
assumed established.
|
||
|
||
Where a wallet has a login type name, `wallet_name@peer_name`, the peer could
|
||
potentially engage in a man in the middle attack against the wallet. However,
|
||
during transactions, it is necessary to prove control of the secret key of an
|
||
unspent transaction output, which the man in the middle cannot do, with the
|
||
result that the connection will break with an error message blaming the peer
|
||
that set up the connection.
|
||
|
||
When a group of wallets want to perform a transaction, they rendezvous on one
|
||
particular wallet, who constructs the transaction, and feeds it to his
|
||
blockchain agent. A rendezvous on a particular wallet is a room on that
|
||
wallet. A wallet can have several rooms, and each room can have several other
|
||
wallets connected to it. One wallet connected to a room, and also connected to
|
||
another wallet by a separate connection, can invite that other wallet to that
|
||
room, without needing to go through a peer. This prevents peers from reliably
|
||
knowing who is party to a transaction.
|
||
|
||
## Byzantine failure.
|
||
|
||
Byzantine failure, if intentional and malicious, is lying, either explicitly - giving one party inconsistent with the information given to another party, the classic example being one Byzantine General telling one other general he is going to advance, and another general that he is going to retreat, so that the general expecting to be part of an advance finds himself alone and he is killed and his army destroyed.
|
||
|
||
In a blockdag, this always going to become visible eventually, but the problem is, it may become visible too late.
|
||
|
||
Mechanisms to protect against Byzantine failure look superficially like
|
||
proof of stake shareholder democracy but they are subtly different. They
|
||
protect against the ten percent attack, but assume that any one outcome
|
||
selected by any one correctly functioning peer is equally acceptable, that
|
||
the problem is selecting one of many equally possible and equally
|
||
acceptable outcomes, that the decision of any peer of the two thirds of
|
||
peers not engaged in byzantine failure is equally OK.
|
||
|
||
We need fifty one percent rule, shareholder authority, and we need to
|
||
protect against Byzantine failure, the ten percent attack, both.
|
||
|
||
We need computer algorithms that prevent the ten percent attack, one third
|
||
minus one, and we need social mechanisms that detect and penalize one third
|
||
plus one.
|
||
|
||
We need computer shareholder democracy and human shareholder democracy layered
|
||
on top of and underneath byzantine fault resistance.
|
||
|
||
Byzantine fault tolerance looks superficially like shareholder democracy, but
|
||
it is not. We need all the mechanisms, each to address its own problem space.
|
||
|
||
If two thirds plus one voluntarily follow the
|
||
policy of half plus one, and one third plus one testify that one rather
|
||
arbitrarily selected outcome is consistent with the policy commanded by
|
||
half plus one, then that is the one verified outcome of the blockchain.
|
||
|
||
And, to make sure we have mostly honest participants, human level social
|
||
enforcement, which means that Byzantine faults need to have some probability
|
||
of being detected and Streisanded.
|
||
|
||
But, in the event of complete breakdown of a major connection of the
|
||
network, we need the one third plus one to reliably verify that there
|
||
is no other one third plus one, by sampling geographically distant
|
||
and network address distant groups of nodes.
|
||
|
||
So, we have fifty percent by weight of stake plus one determining policy,
|
||
and one third of active peers on the network that have been nominated by
|
||
fifty percent plus one of weight of stake to give effect to policy
|
||
selecting particular blocks, which become official when fifty percent plus
|
||
one of active peers the network that have been nominated by fifty percent
|
||
plus one of weight of stake have acked the outcome selected by one third
|
||
plus one of active peers.
|
||
|
||
In the rare case where half the active peers see timeouts from the other
|
||
half of the active peers, and vice versa, we could get two blocks, each
|
||
endorsed by one third of the active peers, which case would need to be
|
||
resolved by a fifty one percent vote of weight of stake voting for the
|
||
acceptable outcome that is endorsed by the largest group of active peers,
|
||
but the normal outcome is that half the weight of stake receives
|
||
notification (the host representing them receives notification) of one
|
||
final block selected by one third of the active peers on the network,
|
||
without receiving notification of a different final block.
|
||
|
||
# Funds need to be fully traceable, and fully untraceable
|
||
|
||
A crypto currency needs to be totally traceable and totally untraceable.
|
||
A common application is money lending in the third world. The money
|
||
lender needs to be able to prove he loaned the peasant such and such an
|
||
amount, on such and such terms, with such and such an agreement, and the
|
||
[peasant needs to be able to prove he repaid the money lender such and
|
||
such an amount]
|
||
in relation to that agreement and in fulfillment those terms.
|
||
|
||
[peasant needs to be able to prove he repaid the money lender such and
|
||
such an amount]: http://www.scmp.com/week-asia/business/article/2148658/how-bitcoin-and-cryptocurrencies-went-wall-street-high-streets,
|
||
|
||
The peasant’s daughter is working in Saudi Arabia. She buys some crypto
|
||
currency, perhaps for cash, and sends it to her mother. She trusts her
|
||
mother, her mother trusts her, she does not need any traceability, but
|
||
the government wants to tax transfers, and the financial system that has
|
||
a government monopoly wants to charge her and her mother a fee for getting in
|
||
her way.
|
||
|
||
The parties to a transaction can send proof of transaction, and proof
|
||
that the transaction is in accord with an agreement, and proof of what
|
||
the agreement was, to anyone, or make it public. But if they take no
|
||
action to make it public, no one can know who the transaction took place
|
||
between, nor what the transaction was about.
|
||
|
||
An unhappy customer can make his transaction public. A happy customer
|
||
can send a favorable acknowledgment to the supplier, that the supplier
|
||
will likely make public. But if neither of them does anything to make it
|
||
public, it remains untraceable by default, unless one of the parties
|
||
does something special to change the default.
|
||
|
||
A company has an initial coin offering instead of an initial share
|
||
offering. It goes bust. People who claim to be owed money by the company
|
||
want to find the people who bought the initial coins. They do not want
|
||
to be found.
|
||
|
||
# the corporate form
|
||
|
||
To better support the corporate form, the crypto currency maintains a
|
||
name system, of globally unique human readable names on top of [Zooko’s
|
||
triangle] names.
|
||
|
||
[Zooko’s triangle]: ./zookos_triangle.html
|
||
|
||
Transactions between [Zooko’s triangle] identities will be untraceable,
|
||
because amounts will be in fixed sized amounts, and transactions will
|
||
mingle many people paying many recipients. Transactions with globally
|
||
unique human readable names will usually be highly traceable, since that
|
||
is what the name is for – but you don’t have to use the name in the
|
||
payment, and by default, do not.
|
||
|
||
A wallet name will typically look like an email address,
|
||
`human readable login name @ human readable peer name`, but the
|
||
transaction outputs it controls will be largely controlled by public
|
||
keys, which are not provably connected to the wallet, unless the wallet
|
||
operator chooses for it to be provable.
|
||
|
||
If someone makes a traceable and provable payment to a human readable
|
||
name, he can then associate an arbitrary URL with that payment, such as
|
||
a review of the service or product provided by the entity with the human
|
||
readable name, so that people can find out what people who paid that
|
||
entity are saying.
|
||
|
||
So if you make a provable payment to a recipient with a human readable
|
||
name, [you will have some assurance of getting what you paid
|
||
for](trust_and_privacy_on_the_blockchain.html).
|
||
|
||
Peers may have human readable names, and wallets may have names of the
|
||
form `LoginName@PeerName`.
|
||
|