wallet/docs/contracts_on_blockchain.md

---
title:
    Contracts on the blockchain
...
# Terminology

A rhocoin is an unspent transaction output, and it is the public key
that identifies that unspent transaction output, the private key that
can sign with that public key, the point which is the mathematical
object of which that public key is the text representation, and the
scalar which is the mathematical object that the secret can construct.

A public key and and its associated secret key can do all sorts of
things as well as control rocoins – logons, identifying participants in
a conversation, and signing a message, among them.

We talk about points and scalars, meaning points on the elliptic curve
and scalars, large numbers modulo the order of the curve, the
mathematical objects underlying these keys, when we combine them
mathematically in interesting ways, for example adding several points to
create a public key that requires several secrets, possessed by several
different people, to use. Scalars can be added and multiplied, points
can be added or subtracted from other points, and points can be
multiplied by scalars. When we design contracts on the blockchain, we
should refer to scalars and points, but the rest of the time, we should
talk about coins, public keys, and private keys. Normal people should
never need to hear of points and scalars, and should not need to know
what they are. Only people writing software to manage blockchain based
interactions need to talk about or think about points and scalars.

# Instant irrevocable transctions

## Why we need Schnorr signatures

In order that people can meet in person to exchange fiat for blockchain
money in person, they need a transfer that is instant and irrevocable.

Bob wants to buy blockchain money for cash. Ann wants to sell for cash.
They agree to meet in person, and do the exchange – paper money in a
brown paper bag.

Ann and Bob cooperate over the network to create a postdated transaction
spending an as yet nonexistent coin whose public key is the sum of a
public key whose secret key is known only to Bob, and a public key whose
secret key is known only to Ann, and *after* that transaction is
created, Ann issues a transaction placing value an unspent transaction
output in that coin, creates a rhocoin for that public key, knowing that
if nothing further is done, the coin eventually comes back to her. Then,
before the postdated transaction becomes placeable on the blockchain,
they meet in person, and once the cash is in her hands and she has
counted it, she then reveals her secret key to Bob, and his wallet can
instantly tell him that the coin is in his wallet right and spendable
right now – but will become spendable by Ann at block number so and so.
Bob can now spend that coin, but Ann still cannot spend it and needs to
spend it before the postdated transaction becomes spendable on the
blockchain. He presumably spends it to a coin wholly controlled by him,
or uses it in some other transaction, and Ann discards the now useless
postdated transaction.

Note that such a joint shnorr signature is absolutely indistinguishable
on the blockchain from any other signature, so no one, except for Ann
and Bob, can tell there was anything different about this transaction.

To represent this contract to normies, we call it a coin commitment, a
coin locked to someone else’s wallet for a certain period. We refain
from talking about points and scalars. Ann creates a coin that she
cannot use for anything except paying Bob, until a certain time has
passed, and once this coin is registered on the blockchain, Bob knows
she has created this coin and what it is worth, (though no one except
Ann and Bob knows it is for this purpose) but once the coin is on the
blockchain, she can use it to instantly pay Bob, in a message over the
network that his wallet will immediately register as payment completed,
without needing a third party escrow agent that governments will want to
register and regulate, as you have use in order to do instant payments
with bitcoin, or offline by Bob manually typing in the secret that makes
the coin spendable by Bob, though it can be texted in the clear, since
no one but Bob can make use of it. It only needs to be kept secret until
the time comes for Bob to receive the payment. But if she does not
instantly pay Bob, she can convert it into a regular coin, spendable by
her and only by her at any time, once its lockup time has expired.
conversely, once she has given Bob the secret, Bob can use it any
transaction, such as a transaction spending it to himself, before its
time is up. The blockchain contains no information showing this
committed coin is any different from any other, the information that
makes this coin different being in the secrets in Ann’s and Bob’s
wallets, not in the blockchain where governments are likely to look for
someone to regulate. The information that makes this coin different is
that the secret that controls it is split between Ann’s wallet and
Bob’s wallet, and Ann and Bob have already created a secret
transaction, stored in Ann’s wallet, spending the coin to a destination
determined by Ann, which transaction remains in her wallet until the
time is up, or until Bob, having received the secret from Ann, spends
the coin. This transaction is made possible, not by any terribly clever
cryptographic mathematics, but by the fact that our blockchain, unlike
the others, is organized around client wallets chatting privately with
other client wallets. Every other blockchain has necessary cryptographic
mathematics to do the equivalent, usually more powerfull and general
than anything on the rhocoin blockchain, and Monaro has immensely
superior cryptographic capabilities, but somehow, they don’t, the
difference being that rhocoin is designed to avoid uses of the internet
that render a blockchain vulnerable to regulation, rather than to use
clever cryptography to avoid regulation. The attack points whereby
government is getting hold of crypto currencies are not the
cryptography, which is usually bulletproof, but the domain name system,
the certificate authorities, and the world wide web, which is completely
vulnerable.

# General purpose scripts

Ethereum has a general purpose script language, which seems like
overkill, and indeed it was overkill, since humans started to misbehave,
and other humans started to judge transactions, so that the laws of
mathematics failed to dictate the outcomes, and those human judges are
predictably misbehaving.

Bitcoin has a also has a fully general stackbased language
pay-to-scripthash (P2SH) also called Bitcoin script.  But this led to
problems, so they effectively disabled it, by making only a small set of
scripts permissible.  Seems that we have not yet figured out how to
safely enable run time user designed contracts on the blockchain.  We
instead need a short list of payment rules fixed at compile time.  We
shall not create a script language capable of embedding arbitrary
contracts in the blockchain at runtime, as it would be impossible for one of
the parties to figure out the gotchas cooked up by the other party.

Rather than our model being the infamous click through contract and shrink
wrap contract, our model should be the returnable writs of The Lion of
Justice, Henry the First.  The Anglo Saxon legal system has been going
downhill since the death of Henry the second.  It is time for a restoration.
If we cannot restore, bypass.  People wanted to use the legal system of The
Lion of Justice, rather than the ecclesiastical legal system, and if we do
things right, people will want to use our legal system.

A returnable writ is a royal command that has blanks that the parties to a
dispute or a contract can fill in, but they cannot write their own writ
ad hoc.

The trouble with excessive flexibility is that the parties to a dispute are
likely to have asymmetric knowledge of the implications of the contract, which
problem can be mitigated by having as few possible contracts as possible, and
those contracts authorized by the consensus of the blockchain.  We can
increase flexibility by having multi transaction transactions, where different
elements of the aggregate transaction invoke different writs, but too much
flexibility is likely to bite people.

# Atomic Swaps on separate blockchains

A proof of share currency is like a corporation, like shares in a
corporation.  So we are going to have many corporations, and individuals
will want to exchange shares in one corporation, with shares in
another.  We would like to do this without direct linking of
blockchains, without trusted intermediaries, because a trusted
intermediary is a target for regulation, where the state imposes
mandatory trust, while protecting profoundly untrustworthy behavior.

Bob is owns some crypto currency in the foo blockchain, and wants to
exchange it with Carol’s crypto carrency in the bar blockchain. 

Bob agrees with Carol to give her three units of his foo currency, for
five units of her bar currency. 

But, how do we make it so that the transaction is completed? We don’t
want Carol giving five units, and Bob replying “Hah hah fooled you”.

So Carol creates an output of five units that can be spent by a secret
key that only she knows after ten blocks, but until then can be spent by
Bob’s secret, plus a preimage that only she knows. The output contains
Bob’s public key, Carol’s public key, and the public hash of a secret
preimage known only to Carol. Bob waits until that output becomes final
and spendable in the bar blockchain. Bob then creates an output of three
units that can be spent by a secret key that Bob knows after five blocks
in the foo chain, but until then, can be spent by a carol’s secret key,
plus the preimage of a value known only to Carol. The output also
contains Carol’s public key, Bob’s public key, and the pubic hash of a
secret preimage known only to Carol, except that the public keys in
Bob’s output are in the opposite order to Carol’s, and the times are
different.  After a while, both outputs become final and spendable in
their respective blockchains.  Carol then uses her preimage to spend
those three units in the foo chain, thereby automatically revealing it
to Bob, which preimage Bob immediately employs to spend the output on
the bar chain.

To spend an output, it has to be an input, one of many, to a
transaction, and the whole transaction has to be signed by every
signature required by every input, as each input defines a valid
signature. So an input/output carries information amounting to a
quantity of money, possibly a user name, and a signature definition. In
the simplest and most common case, a public key defines what would
constitute a valid signature.

The immutability of the output comes from the fact that is part of
transaction, and the entire transaction has to be as signed, that the
transaction has to be signed by the signatures for all the inputs. For
this case, contract conditional on pre-image for a certain range of
block numbers, the signature block has to the pre-image as well as the
regular signature.

# Micro and Nanopayments.

The blockchain is heavy, thus unsuitable for small and fast payments,
such as the payments needed for storage and bandwidth while pirating
files.

Small fast payments require trust, thus trusted intermediaries backed up
by the blockchain.

How do we know if we can trust an intermediary?

Because he has a history of signed contracts, that it is easy to prove
whether a contract has been honored, and no one has produced a contract
that he signed, alleged that contract was dishonored, and he could not
prove it was honored.

Assume Bob is a trusted intermediary between Ann and Carol. Ann wants to
pay people, Carol among them, probabilistically – in lottery tickets
that if won will result in payments on the blockchain.

The protocol is that Ann creates the unspent transaction output, which
comes to exist, unspent, on the blockchain, and no one can spend it
except Bob says so, since any transaction spending that output will need
a Bob signature.  So if Bob is an OK guy, no double spending shall ever
happen. If no double spending has ever happened, we can probably trust
Bob for transactions similar to past transactions. If no past double
spends, likely no future double spends.

Ann promises to give Carol a lottery ticket for services rendered, Carol
gives Ann a signed hash of a secret preimage, and renders those
services. Ann issues a lottery ticket by creating a random number, and
giving Carol a signed hash of Carol’s hash and the lottery identifier.
The ticket will be valid if the hash of Ann’s secret preimage, and
Carol’s secret preimage has certain properties – typically that its
value in big endian order modulo 2^64^ is less than a certain amount. 
The ticket commits Ann to the lottery conditions, being a hash of their
secrets, and the conditions agreed to.

Carol shows Bob the lottery ticket, and asks

> “will I get paid if the secrets under the hashes meet the required
> condition.”

Bob tells Carol

> “Sure. I will issue a payment for block number such of the blockchain,
> the current block, if the preimage meets the conditions.”

thereby assuring Carol that Ann is on the up and up and providing the
data needed to create a valid transaction if the lottery ticket is
valid.  Bob provides a link to the transaction output that will be used
showing that Carol has put real money where her mouth is, asserts it is
unspent, and promises not to validate any further potentially winning
lottery tickets for this block period, unless shown evidence that
previously validated lottery tickets were losing tickets.

Carol, who has some reason to trust Bob, now knows that Ann is issuing
valid lottery tickets – even if this was a losing lottery ticket.  Bob
will refuse to issue more validations for this lottery and this block
period. unless Carol provides proof that this was a losing lottery
ticket.

If Carol goes dark at this point, the money is frozen till the next
block period, which causes minor and temporary inconvenience for Ann and
Bob but does not benefit Carol.

Suppose it is a winning lottery ticket – she informs Bob and Carol so
that they know to issue a new lottery, and now injects it into the
blockchain with the required data, and hashes that links to the
conversations between herself, Bob, and Alice. If the payment goes
through – the transaction inputs are real and have not been previously
spent.  then done. If the transaction fails for block n of the block
chain, when Bob said it would succeed, she uses the proof of failure -
that blockchain input was invalid or spent in this block when Bob said
it would be valid and unspent for this block, plus the previous
conversations between herself, Bob, and Carol, to prove to the world
that Bob was cheating.

If, on the other hand, there are lots of transactions of this form that
have successfully gone through, and none that failed in this fashion,
these provide compelling evidence that Bob is an honest dealer.

If Bob goes dark at some point (going dark means ceasing to respond, or
issuing responses that will be rejected and ignored as invalid) the
money remains unspent and unspendable, Ann and Carol are inconvenienced,
no one wins, and no proof of bad behavior is generated.  But Bob cannot
stay up for losing lottery tickets, but then conveniently go dark for
winning lottery tickets because he issues the data required for a
winning lottery ticket (or data that would prove he is a cheater) before
he knows whether the ticket is winning or not.

If Carol goes dark, she does not get paid, but does not get proof of bad
behavior by Ann or Bob.

If Ann goes dark, she does not pay Carol. Carol knows Ann is behaving
badly, ceases to deal with her, but may not get proof of bad behavior by
Ann that she can show to other people.  But getting such proof is not
very useful anyway, since Carol’s identity is cheap and expendable,
while Bob’s identity is durable and valuable.

Random stranger Ann contacts random stranger Carol, offers to pay in
lottery tickets for data. Perhaps she wants to watch some movies. Shows
proof that lottery prize recently existed in a recent block on the
blockchain, which shows that Ann is not a total flake. Gets some data on
trust. Provides lottery ticket. Bob says lottery ticket could win,
depending on a secret that Carol has committed to, but not revealed.
Carol checks that in the past Bob has paid out on lots of lottery
tickets and not defected on any lottery ticket. More trust ensues.  Ann
now has reason to trust Carol, Carol has reason to trust Ann, without
anyone being exposed to large risks and without any actual blockchain
transactions taking place. It takes an expensive blockchain transaction
to create the lottery prize, but having created it, Ann and Bob can do
very large numbers of transactions off blockchain on trust.

# Institutions on the blockchain

A lot of people, instead of controlling outputs on the bitcoin
blockchain by secret keys, have a login account, username and password,
with an “exchange”.  That “exchange” (the institution, not the
particular transaction mediated by the institution) owes them bitcoins,
payable on demand.  And from time to time an exchange goes belly up,
blaming the federal government or hackers, and just does not pay its
clients the bitcoins it owes.

We call them “exchanges”, not “banks”, because the word “banks” implies
a government guarantee, and a long past of honoring transactions, which
these exchanges seldom have, but they are performing bank like
functions.

We would like to have evidence of the institutions reserve fraction, of
its term transformation (maturity transformation).

Solution: Institution runs its own side chain, with a small number of
peers. The Merkle-patricia dac of unspent transaction outputs has in
each node the sum of the money in each subtree, and the hash of subtree
hashes and sums. Thus the standard client wallet will report the total
owing/shares on issue