Companion video at: http://youtu.be/VDRYZ122mXA
Tim Swanson discusses cryptocurrencies, cryptoledgers, smart contracts, smart property, decentralized autonomous organizations and cryptobarter. There are footnotes included as well. Filmed at Hacker Dojo on February 14, 2014 during Ethereum meetup. More info at: www.ofnumbers.com
2.
Virtual token (e.g., a
bitcoin, a litecoin) having
at least one moneyness
attribute such as medium
of exchange
It is transported and
tracked on an encrypted,
decentralized ledger called
a cryptoledger (managed
by a cryptoprotocol)
Trustlessness
3.
Computer protocols that
facilitate, verify, execute and
enforce the terms of a contract
Current proto examples include:
◦ Some digital financial instruments
used on electronic securities
exchanges
◦ Point-of-sale terminals
◦ Electronic Data Interchange (EDI)
4.
They do not have a physical
enforcement arm the way
legal contracts do; they just
move the defined asset(s)
automatically under certain
conditions.
Unforgeability (encrypted),
confidentiality, and
divisibility
Reduce the fraud and
enforcement costs of many
commercial transactions
Doable today (e.g. small
business loan)
5.
Version 0.9 (80 byte
hash)
Bitcoin currently manages
one asset via one token
Dev team has limited
resources
Yet in theory, a token can
represent any asset
And a token can be a
type of „smart contract‟
8.
Not all gadgets, devices
or digital appliances are
technically smart
property
Ownership must be able
to transferred and
managed via smart
contracts
10. • Manage, trade and exchange assets globally,
pseudonymously (perhaps anonymously) entirely
without going into fiat
TAM is a fusion of:
◦
◦
◦
◦
◦
Cryptoledger
Smart Contracts (e.g., tokens)
Smart Property („proplets‟)
Decentralized exchanges
DAO/DACP*
11.
Near frictionless within the network
Entirely decentralized (e.g. DEX, Coinality,
BankToTheFuture)
Reputation-based at address level (credit
score)
Independent arbitration (Judge.me,
Coinsigner)
Escrow (BTCrow)
Tokens to represent most contractual
agreements (e.g., „labor‟ token to represent X
amount of time used as invoice and
(dis)approved via atomic-transaction)
12.
70 year leases are often
40-50 year leases
4 million rural Chinese
evicted each year
Local gov‟t generate
70% of annual income
from land sales
120-150 million
migrant workers
without urban hukou‟s
13.
Low Bitcoin adoption (1-2 million users)
User interfaces and adoption
Consumer education
Legal uncertainties
Institutional/incumbent inertia
Reinventing the wheel
Is an ideal scenario, just like PGP
“Decentralization for decentralizations sake”
15.
Contracts very often use multi-signature outputs in order to allocate value to a group of users
... typically, the participants in the contract protocol. Multi-signature outputs are easy to create
with bitcoinj.
// Create a random key.
ECKey clientKey = new ECKey();
// We get the other parties public key from somewhere ...
ECKey serverKey = new ECKey(null, publicKeyBytes);
// Prepare a template for the contract.
Transaction contract = new Transaction(params);
List<ECKey> keys = ImmutableList.of(clientKey, serverKey);
// Create a 2-of-2 multisig output script.
Script script = ScriptBuilder.createMultiSigOutputScript(2, keys);
// Now add an output for 0.50 bitcoins that uses that script.
BigInteger amount = Utils.toNanoCoins(0, 50);
contract.addOutput(amount, script);
// We have said we want to make 0.5 coins controlled by us and them.
// But it's not a valid tx yet because there are no inputs.
Wallet.SendRequest req = Wallet.SendRequest.forTx(contract);
wallet.completeTx(req); // Could throw InsufficientMoneyException
// Broadcast and wait for it to propagate across the network.
// It should take a few seconds unless something went wrong.
peerGroup.broadcastTransaction(req.tx).get();
16.
A common requirement when implementing contract protocols is to pass around and sign incomplete transactions.
The Wallet class doesn't know how to handle outputs that aren't fully owned by it. So we'll have to sign the spending transaction
ourselves.
The key point to bear in mind is that when you sign a transaction, what you actually sign is only parts of that transaction. Which parts are
controlled by the signature hash (sighash) flags. But no matter which flags you select, the contents of input scripts are never signed.
Indeed that must be the case, because otherwise you could never build a transaction - the act of signing the second input would modify
the version of the transaction signed by the first, breaking the signature.
This means that signatures can be calculated and sent between different parties in a contract, then inserted into a transaction to make it
valid.
// Assume we get the multisig transaction we're trying to spend from
// somewhere, like a network connection.
ECKey serverKey = ....;
Transaction contract = ....;
TransactionOutput multisigOutput = contract.getOutput(0);
Script multisigScript = multisigOutput.getScriptPubKey();
// Is the output what we expect?
checkState(multisigScript.isSentToMultiSig());
BigInteger value = multisigOutput.getValue();
// OK, now build a transaction that spends the money back to the client.
Transaction spendTx = new Transaction(params);
spendTx.addOutput(value, clientKey);
spendTx.addInput(multisigOutput);
// It's of the right form. But the wallet can't sign it. So, we have to
// do it ourselves.
Sha256Hash sighash = spendTx.hashTransactionForSignature(0, multisigScript, Transaction.SIGHASH_ALL, false);
ECKey.ECDSASignature signature = serverKey.sign(sighash);
// We have calculated a valid signature, so send it back to the client:
sendToClientApp(signature);
17.
The server receives the contract and decides to give all the money back to the client (how generous of it!). It
constructs a transaction and signs it. Now the client must repeat the process and construct exactly the same
transaction and calculate a signature in the same way. It is then in possession of two valid signatures over the
same transaction, one from itself and one from the server. All that is left is to put them both into the
transaction:
TransactionOutput multisigContract = ....;
ECKey.ECSDASignature serverSignature = ....;
// Client side code.
Transaction spendTx = new Transaction(params);
spendTx.addOutput(value, clientKey);
TransactionInput input = spendTx.addInput(multisigOutput);
Sha256Hash sighash = spendTx.hashTransactionForSignature(0, multisigScript, Transaction.SIGHASH_ALL,
false);
ECKey.ECDSASignature mySignature = clientKey.sign(sighash);
// Create the script that spends the multi-sig output.
Script inputScript = ScriptBuilder.createMultiSigInputScript(
ImmutableList.of(mySignature, serverSignature), Transaction.SIGHASH_ALL, false);
// Add it to the input.
input.setScriptSig(inputScript);
// We can now check the server provided signature is correct, of course...
input.verify(multisigOutput); // Throws an exception if the script doesn't run.
// It's valid! Let's take back the money.
peerGroup.broadcastTransaction(spendTx).get();
// Wallet now has the money back in it.
Editor's Notes
The following is a hypothetical scenario, where user adoption and education are quicker than what will likely occur. Just as the Segway product was overhyped, proponents of cryptoprotocols need to hedge their terms and take into account the slow user adoption rates that will likely occur with the concepts in this Powerpoint. For example, roughly 1-2 million people have used a cryptocurrency despite millions of hours of promotion/marketing/promotion on a global level. Could the same thing happen with smart contracts?
All cryptocurrencies are virtual and digital, but not all digital ‘coins’ are cryptocurrencies.
Smart Contracts by Nick Szabo: http://szabo.best.vwh.net/smart.contracts.htmlAccording to Mark Miller the first smart contracting system was AMIX, the American Information Exchange.
Theyare computer protocols – algorithms – that can self-execute, self-enforce, self-verify and self-constrain the performance of a contract. As show below, contracts on 2.0 platforms basically enforce themselves. The term smart contract is sometimes used as a bit of a misnomer, because it undersells the capabilities of a DAO. An ‘active contract’ or ‘live contract’ explains that the contract itself is the mechanism that monitors and actively controls the prior agreement per the terms. See also: WorkingWithContracts from bitcoinj
Core Development Update #5 by Gavin Andresen https://bitcoinfoundation.org/blog/?p=290
Proplets -- Devices for Controlling Property by Nick Szabo http://szabo.best.vwh.net/proplets.html
Just because you have WiFi enabled lightbulbs or even doors, that this is not smart property. It may be automated property but it is not "smart" in the sense that ownership and control can be reverted automatically to a different party.
Decentralized Autonomous Consensus Platform (coined by Adam Levine) See Mike Hearn’s presentation at the 2013 Turing conference: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
See also: http://www.generalgovernance.com
See Chinese Land-Use Rights: What Happens After 70 Years? from China Smack, China’s Real Estate Riddle from Patrick Chovanec, You May Own your Apartment, but who Owns the Land Underneath Your Feet? by Thomas Rippel, If Beijing is your landlord, what happens when the lease is up? from China Economic Review and Chinese fear homes are castles in the air by Stephen WongSee China’s Land Grab Epidemic Is Causing More Wukan-Style Protests from The Atlantic and China Tackles Land Grabs, Key Source of Rural Anger from The Wall Street JournalSee China land price fall threatens local finances from Financial Times and China’s land-seizure problem from Chicago TribuneInternal Migration in China and the Effects on Sending Regions from OECDSee Hukou system and China: Urbanization and Hukou Reform from The Diplomat
From Mike Hearn: http://code.google.com/p/bitcoinj/wiki/WorkingWithContracts
From Mike Hearn: http://code.google.com/p/bitcoinj/wiki/WorkingWithContracts
From Mike Hearn: http://code.google.com/p/bitcoinj/wiki/WorkingWithContracts