18 KiB
| 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 stake 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